Your .NET APIs have a new kind of customer: MCP, A2A and what to do about it

For very many years I have written C# services that other software calls. Until recently, "other software" meant another service written by a human who read my docs. That is changing. The caller is increasingly an AI agent, and it doesn't read your Swagger page. It reads a tool description and decides, at runtime, whether to call you.

That is what the Model Context Protocol (MCP) is for, and as of this summer .NET has a serious, stable way to do it.

The one-paragraph version

MCP is an open standard for connecting AI applications to tools and data. Think of it as the standard socket on a telephone exchange: build one server and any compliant client (an IDE assistant, a chat app, your own agent) can plug in. A2A, the Agent2Agent protocol, solves a different problem: agents talking to other agents, including across organisations. The Linux Foundation, which hosts both, describes them as complementary: MCP for how an agent reaches its tools and data, A2A for how agents coordinate with each other.

What changed in .NET this summer

The official MCP C# SDK reached v2.0 on 28 July 2026, implementing the 2026-07-28 revision of the spec. The things that matter to anyone running real services:

• Stateless HTTP by default. The initialize handshake and Mcp-Session-Id header are gone from the protocol, so any instance can serve any request. If you have ever fought sticky sessions behind a load balancer, you will see why this matters. Sessions are still available as an opt-in.
• Routable headers. Method, tool name and selected parameters are mirrored into HTTP headers, so gateways and proxies can route and police MCP traffic without parsing bodies.
• Multi round-trip requests. A tool can ask the client for more input (InputRequiredException) and be called again, with no server-side session. The older server-initiated sampling, roots and elicitation APIs are deprecated or throw in stateless mode.
• Backward compatible. Existing v1 code keeps compiling and v2 talks to older peers. The exception is the experimental Tasks API, which moved to its own package and is not wire-compatible with v1.
• Targets net8.0, net9.0, net10.0 and netstandard2.0.

A minimal server is now this small (adapted from the SDK write-ups):

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddMcpServer()
    .WithHttpTransport()        // stateless by default in v2
    .WithToolsFromAssembly();

var app = builder.Build();
app.MapMcp();
app.Run();

[McpServerToolType]
public static class OrderTools
{
    [McpServerTool(Name = "get_order_status")]
    [Description("Gets the current status of an order in a region.")]
    public static string GetOrderStatus(
        [Description("The region that owns the order.")] string region,
        [Description("The identifier of the order.")] string orderId)
        => $"Order {orderId} is being processed in {region}.";
}

The Description attributes are not decoration. They are the interface. The model chooses your tool from that text.

The part that should worry you

Wrapping an endpoint in an attribute is the easy bit. The hard bit is that a tool description is not a security boundary. The model decides whether to call your tool; your server must decide whether the caller is allowed to. The practical rules I'd put in a code review:

1. Authorise per resource, on every call. "May call MCP" is not a permission. Check the caller's right to this order, this customer.
2. Treat anything the client sends back as untrusted, including continuation state from multi round-trip requests. Validate principal, action, expiry and single use. A user clicking "yes" does not replace a permission check.
3. Validate inputs as if a hostile caller wrote them, because prompt injection means one effectively might have.
4. Don't put personal data in headers or logs. Promoted parameters can end up in traces. Use coarse routing keys.
5. Stateless does not mean your business logic is stateless. Idempotency, concurrency and durable storage are still your job. And the SDK's in-memory task store is for development only.

Note also that end-to-end authentication and authorisation is where the SDK team says its focus is going in the 2.x line, so expect that area to keep moving. Pin your versions.

Why this is a systems-integration story, not a toy

Most UK mid-market firms I talk to have the same estate: a core line-of-business system, a handful of bolt-ons, and a decade of point-to-point integrations nobody fully understands. The firms that will get value from AI agents are not the ones with the cleverest prompts. They are the ones whose systems already expose clean, well-described, well-authorised capabilities. An agent is only as useful as what it is allowed to reach.

That cuts both ways. If your domain is a mess of undocumented stored procedures and shared databases, an agent will either be useless or dangerous. If you have already done the unglamorous work of layering your services and defining clear contracts, MCP is a thin wrapper and a quick win. It is the same lesson as the Terraform one from last week: you cannot safely modernise what you cannot safely change.

The UK public-data world is a good example of the direction of travel. Community-built MCP servers for the Companies House API already exist, so an agent can search company records, officers and filings through one standard interface rather than bespoke glue. That is public data and a modest example, but it shows the pattern: standard sockets arrive first from the community, and your internal systems are next.

What I'd do on Monday

• Pick one read-only, low-risk capability (order status, stock lookup, a report) and expose it as an MCP tool. No writes yet.
• Put it behind your existing identity provider and log every call.
• Write the descriptions as if briefing a new starter.
• Review it with security before anyone connects an agent, not after.
• Watch A2A, but don't adopt it for internal calls. It earns its place when agents cross organisational boundaries. Version 1.0 landed in April 2026 with more than 150 supporting organisations, including Microsoft, AWS, Google and SAP.

If you'd like a second pair of eyes on which of your services are ready to be exposed to agents, and which need fixing first, that is exactly what my one-day architecture review covers.