MCP in Production
An MCP server that can reach backup vaults, recovery plans, virtual machines and databases is no longer a developer convenience. It sits between a sentence someone typed and an API call against a subscription. This seven-part series is for platform engineers, cloud architects and the security and change teams who work with them. It uses Microsoft's Azure MCP Server 3.0 release as the timely anchor: deciding what an agent is authorised to do, threat-modelling read-only access, treating tool names, descriptions and schemas as part of agent behaviour, giving database tools their own boundary, handling server upgrades as production changes, choosing between local, shared and third-party servers, and keeping a change record from prompt to verified result. The control questions apply to any cloud or enterprise tool server. It follows Sedgefield Freight, a fictional George-based road-freight operator with an Azure estate; its systems, identities and figures are illustrative. Research claims were checked on 3 November 2026.
7 articles
- Part 1Your agent can operate Azure. What exactly did you authorise?Azure MCP Server 3.0 turns an agent's tool list into a route into the cloud control plane. Part 1 of MCP in Production explains what the release adds, why tool discovery is not permission, and the four authority checkpoints a platform team should decide before anyone connects an agent to a subscription.8 min read
- Part 2Read-only is a starting architecture, not a governance programmeStarting an MCP server in read-only mode is the right first step. It is not the end of the risk. Part 2 of MCP in Production threat-models read access, from sensitive reads to data leaving through the model, and defines the evidence needed before an agent moves beyond inspection.7 min read
- Part 3Tool descriptions are part of agent behaviourAn agent chooses tools by reading names, descriptions and schemas, then parses what comes back. Change any of them and behaviour changes, even if no code did. Part 3 of MCP in Production explains how tool contracts shape selection and parsing, and how to test tool selection without pretending it is deterministic.7 min read
- Part 4The database tool is differentA tool that runs queries against a database is not like a tool that lists resources. It can be destructive, it is not idempotent, and the only boundary that really holds is the database login's permissions. Part 4 of MCP in Production sets out how to give an agent database access without handing it a loaded query editor.6 min read
- Part 5An MCP upgrade is a production changeUpgrading an MCP server can rename tools, reshape responses, move configuration and change protocol requirements. None of that shows up in a normal build, but all of it can change what an agent does. Part 5 of MCP in Production uses the Azure MCP Server 3.0 upgrade notes to build a compatibility-test matrix and a rollback plan.6 min read
- Part 6Local MCP, shared MCP or remote MCP?The same MCP server can run on a developer's laptop, as a service your platform team hosts, or as an endpoint someone else operates. Each choice changes whose identity reaches the cloud, who can see the traffic and who is on call. Part 6 of MCP in Production compares the three on identity, tenancy, network and ownership.6 min read
- Part 7From prompt to change recordWhen an agent changes a cloud resource, the evidence is scattered across a chat, a tool log, a plan, an approval and an activity log, if it exists at all. Part 7 of MCP in Production connects them into one change record, from the request a person typed to the verified result, using a complete fictional example.6 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala