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 - a Function App, a container, another pipeline, another set of keys. I built that version first. Then I deleted it.

The official MCP SDK 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.

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.

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.