Your MCP server probably doesn't need its own deployment
The reflex when adding an MCP server to an existing product is to stand up a new service. Often the better answer is a route.
The reflex when adding an MCP server to an existing product is to stand up a new service - a Function App, a container, another pipeline, another set of keys. I built that version first. Then I deleted it.
The official C# MCP SDK - past 1.0 and stable now - hosts a server inside an existing ASP.NET Core application: a few service registrations and a mapped route, and the site itself speaks MCP. Stateless mode makes the transport boring in the best way - one POST per tool call, no sessions, no long-lived streams - which suits load balancers and App Service's request-timeout model exactly. That isn't just my preference anymore: the SDK's own docs now recommend stateless mode as the default for HTTP servers, because it scales horizontally without session affinity and sidesteps clients that mishandle session headers.
For a small platform the wins compound. One deployment: the MCP server ships whenever the site ships. One auth story: the same API keys that protect the REST surface protect the MCP endpoint, so revoking a key kills both. And the tools call application services directly instead of looping back over HTTP to the very site hosting them.
The ecosystem has since made the separate-deployment path genuinely easy - Azure Functions now offers first-class hosting for MCP servers, including built-in auth that implements the MCP OAuth spec. That's the right tool the day agent traffic needs isolation, its own scaling curve, or its own blast radius. It doesn't change the default; it just means the exit exists when you earn it.
Even the auth story held up under pressure. When a hosted client later needed OAuth instead of header keys, that became two more routes in the same application - an authorize and a token endpoint in front of the same key store - not a second deployment.
A separate host earns its keep when agent traffic needs isolation or independent scaling. Until that day, it's an extra deployment buying you nothing - and if the day comes, tools written against shared services move without a rewrite.