Developing MCP servers: inside MCP Werk

Weather, water levels, traffic and other public information come from different providers. Their APIs have their own parameters, response formats and usage rules. An AI assistant needs a described interface to call specific functions.

I brought these interfaces together in my own product, MCP Werk. Users choose a data source and receive the configuration for their MCP-capable assistant.

Each data source has its own provider implementation, including tool descriptions and API calls. Shared infrastructure handles hosting, error handling and limits on outgoing requests.

The backend uses ASP.NET Core and the MCP SDK. A React interface helps users discover data sources and tools. Demo access allows experimentation; registered users have authenticated access.

A successful call is only part of operating the service. Access needs to be associated with a user or demo mode. Requests need limits, and data-source failures need understandable responses.

There are therefore limits both on access to MCP Werk and on requests to external data providers. Providers can be configured and disabled individually.

Tests cover provider functions and rate limiting, among other areas. Additional data sources can be integrated into the existing structure.

MCP Werk is publicly available and connects multiple real data sources to MCP-capable assistants. The web interface, individual integrations and infrastructure form the product together.

I handle concept, development and operations. The underlying data belongs to the respective providers; their availability and terms remain relevant when accessed through MCP.

For an existing business API, the starting point is usually smaller: choose a specific use case, build a few suitable MCP tools and check permissions and failure cases.