Exposing Existing ASP.NET Core APIs to AI Agents with a Secure MCP Server
A practical guide to adding a Model Context Protocol server to an existing ASP.NET Core app using the official ModelContextProtocol C# SDK. It covers wrapping existing services as read-only tools, locking the endpoint down with JWT authentication and per-tool authorization, and verifying the surface with an MCP client. Useful for teams that want AI agents to use their current APIs without a rewrite.
Key points
- The article uses ModelContextProtocol.AspNetCore 2.2.0, whose HTTP transport is stateless by default in v2.
- Tools are declared with [McpServerToolType] classes and [McpServerTool] methods, and WithToolsFromAssembly registers them in bulk.
- Start with read-only tools; add write tools only with [Authorize] roles and a human approval step.
- Calling AddAuthorizationFilters() makes the SDK hide unauthorized tools from tools/list and reject direct calls.
- Map the endpoint with MapMcp("/mcp") and protect it with RequireAuthorization, optionally using a scope-based policy.
- Log every tool invocation and watch call volume and latency, since agents can make many calls.
Many .NET teams already run ASP.NET Core APIs that hold their business logic and data access. The challenge now is letting AI agents use those same capabilities without a rewrite and without unrestricted access. The Model Context Protocol (MCP) gives agents a standard way to discover and call tools, and this article shows how to build that layer with the official ModelContextProtocol C# SDK.
The suggested approach is a thin MCP surface that starts with read-only tools wrapping existing services. Tools are marked with attributes, the endpoint is mapped in the same host, and JWT authentication plus per-tool authorization limits what each caller can see and run. The author notes that unauthorized tools are hidden from the tool list and blocked when called directly. A test client check closes the walkthrough. Read the original for the full code and production guidance.
Real-world use
- A support team wants an internal AI agent to look up order status and open orders from its existing order API.
- An enterprise app exposes role-specific read-only MCP tools built on services it already trusts.
- A sensitive action such as order cancellation is gated behind an Admin role and audited with the caller's identity.
Why it matters
You can give agents controlled access to existing ASP.NET Core services without a rewrite, and your existing validation and authorization rules still apply at the MCP layer.