Model Context Protocol (MCP)

What the Model Context Protocol is, and why it became infrastructure

The Model Context Protocol (MCP) is an open standard that defines how AI applications connect to external tools, data sources and services. Before MCP, every team that wanted a language model to query a database, read a ticket system or call an internal API wrote a bespoke integration for each combination of model and system. MCP replaces that N-times-M integration problem with a single contract: a server exposes capabilities in a standard format, and any compliant client can discover and use them. Anthropic released the protocol as an open specification in late 2024, and within a year it had been adopted across the major AI platforms, including Microsoft's Azure and Copilot ecosystems, OpenAI's products and a long tail of developer tools.

For Swedish and European engineering leaders, the practical significance is that MCP has become the default answer to a question every AI project eventually asks: how do our agents reach our systems? Whether you are building copilots on Azure AI Foundry, wiring coding agents into your development workflow, or exposing line-of-business data to an internal assistant, the integration layer you are designing is increasingly an MCP layer. That makes the protocol worth understanding at an architectural level, not just as a plug-in format.

How the protocol works

MCP follows a client-server model over JSON-RPC. A server advertises three kinds of capability: tools the model can invoke, resources it can read, and prompts that package reusable interaction patterns. A client, typically embedded in an AI application or agent runtime, connects to one or more servers, negotiates capabilities and mediates between the model and the outside world. Servers can run locally over standard input/output for desktop and developer scenarios, or remotely over HTTP for shared enterprise deployments.

The specification has evolved quickly, and the direction of travel matters more than any single revision. Early remote transports leaned on long-lived, stateful connections, which fit demos well but fought against how modern cloud platforms actually scale. Later revisions moved decisively toward stateless operation, so that a fleet of interchangeable server replicas behind a load balancer can serve requests without session affinity. If you run workloads on Azure Container Apps, AKS or similar platforms, this shift is what makes MCP servers deployable like any other stateless microservice, with ordinary autoscaling, health probes and rolling upgrades.

The decisions an enterprise team actually faces

Build, adopt or wrap

The first decision is rarely whether to use MCP; it is which servers to run. Vendors now ship official servers for common systems, and platforms such as Azure expose managed MCP endpoints for their own services. Your own systems are a different matter. For internal APIs, the usual pattern is a thin MCP server that wraps existing services, enforcing your authorization model and exposing a deliberately small tool surface. Fewer, well-described tools tend to outperform an exhaustive mirror of your API, because the model has to choose between them at every step.

Authentication and authorization

Auth is where most MCP deployments go wrong. The specification defines an OAuth-based authorization model for remote servers, and the hard questions are about identity: does the server act with the end user's permissions, with a service identity, or with an agent-specific identity that can be governed and revoked on its own terms? In Microsoft-centric environments, Entra ID and its agent identity work give you a way to answer that question consistently. Whatever your stack, the principle is the same: the model should never hold credentials, and every tool invocation should be attributable to a governable identity with least-privilege scopes.

Spec versions and migration

Because the protocol is still evolving, version management is a real operational concern. Clients and servers negotiate protocol versions, but a fleet of servers built against an older revision will eventually need a planned migration, particularly across the transport and statefulness changes. The sensible posture is to track the specification's roadmap, pin versions explicitly in your deployments, and budget migration work the way you would for any platform dependency, rather than discovering a breaking change when a client library updates.

Operations and governance

Once agents call tools in production, you need to see what they did. That means tracing tool calls end to end, logging inputs and outputs with attention to personal data under GDPR, and monitoring for prompt-injection attempts that arrive through tool results rather than user input. For EU organisations, the governance questions extend to data residency for the servers themselves and to documenting the tool surface as part of your broader AI compliance work.

How to approach it

Start with one internal system and one well-scoped use case. Build or wrap a single MCP server, put real authentication in front of it from day one, and deploy it on the same platform and pipelines as your other services. Measure how the model actually uses the tools, prune what confuses it, and only then expand the catalogue. The articles below go deeper on each of these fronts, from migration planning for newer spec revisions to hardening and hosting patterns on Azure, and they reflect what this work looks like in real enterprise environments rather than in demo repositories.