Demystifying Model Context Protocol (MCP): AI Gets Smarter About Context
Ask an LLM to help you debug a Kubernetes incident. It does a decent job. Then, five minutes later, ask it a follow-up question — and watch it answer as if the previous conversation never happened.
That's not a bug in the model. That's the fundamental architectural problem with how most AI tools are wired up. Every prompt starts fresh. Decisions evaporate. Context has to be re-established from scratch every single time. At some point you stop thinking of the AI as a collaborator and start treating it like a very fast search engine that needs to be told the same things repeatedly.
Model Context Protocol (MCP) is the attempt to fix that. It's an open standard — originally proposed by Anthropic, now gaining adoption across the industry — that defines a common way for AI models and the tools around them to share, persist, and prioritise context. The goal is simple: make AI assistants behave less like stateless chatbots and more like reliable operators that actually remember what's going on.
Why context loss is such a concrete problem¶
Before getting into the protocol itself, it's worth being specific about what context loss actually costs you in practice.
In a platform engineering context, the problems show up fast. An agent that's helping with an incident can't carry forward what it already knows about the system unless you explicitly paste it in again. An assistant helping a developer scaffold a new service doesn't remember the naming conventions it just helped establish three conversations ago. A model that's been asked to review a PR can't easily access the context of the related JIRA ticket unless a human manually bridges the gap.
These aren't edge cases. They're the normal operating conditions for any team using AI tools at scale. And the workaround — manually pasting context into every prompt — doesn't scale. It's also error-prone. Context that lives in chat threads and gets copied manually is context that gets lost, truncated, or quietly outdated.
The real cost of context loss
The workaround most teams use — manually pasting context into every prompt — doesn't scale and introduces its own errors. Context that lives in chat threads gets lost, truncated, or quietly outdated. MCP moves context management from something humans do manually to something the tools handle automatically.
What MCP actually is¶
At its core, MCP is a client-server protocol. It defines how an AI model (the client) talks to external tools and data sources (the servers) in a standardised way.
Before MCP, every AI tool integration was bespoke. Your Slack bot talked to Slack one way. Your IDE assistant talked to your code repository another way. Your incident tool had its own custom integration. None of these could share context because they weren't speaking the same language.
MCP defines a common interface. An MCP server exposes capabilities — tools, resources, and prompts — in a standard format. An MCP client (which is your AI model or assistant) can discover and call those capabilities without needing custom integration code for each one. And crucially, context can flow between them in both directions.
The three things MCP handles:
Tool calls — the model can invoke actions on connected systems. Query a database, search a knowledge base, trigger a deployment, create a JIRA ticket. These are structured calls with typed inputs and outputs.
Resources — the model can read structured data from connected systems. A resource might be a file, a configuration object, a schema, or any persistent piece of information the model needs to do its job.
Prompts — pre-defined prompt templates that can be stored and reused across sessions. Not the full system prompt, but reusable building blocks.
Apply this: think in MCP servers, not integrations
Instead of one-off integrations where each AI tool talks to each system in its own way, build MCP servers for your key systems — Kubernetes clusters, incident tooling, internal developer platform, secret store — and any AI client that understands MCP can connect to all of them with the same interface. You build the server once; every AI tool gets it.
The three properties that matter¶
MCP is built around three principles that solve the context loss problem directly.
Context persistence — context survives beyond a single prompt. When a model looks up information via an MCP server, that information can be stored and referenced again in future interactions. The context isn't trapped in the chat window.
Context sharing — tools and models can publish and consume the same context. An incident response tool and a change management tool can both read from and write to the same context store. When the incident tool records that a rollback was performed, the change management tool can see that without a human copying it across.
Context prioritisation — not all context is equally relevant at all times. MCP allows context to be tagged and structured so the right information surfaces at the right moment. You're not flooding the model's context window with everything — you're surfacing what's relevant to the current task.
What this looks like for platform teams¶
In practice, MCP changes the architecture of how you connect AI to your toolchain.
Your Backstage instance becomes an MCP server. Your ArgoCD deployment data becomes an MCP resource. Your runbooks become MCP prompts. The AI assistant working with your on-call engineer can pull context from all of these without the engineer having to paste anything in manually.
The practical effect: assistants that actually know the current state of your system, can take actions against it, and carry that context forward across interactions. Less setup overhead at the start of every conversation. Fewer mistakes from stale context. Faster time from "what's wrong" to "here's what we did".
MCP ecosystem is already substantial
There are community-built MCP servers for GitHub, Slack, Kubernetes, Jira, Confluence, and many more. The ecosystem is growing fast — teams that start thinking in terms of MCP architecture now are going to be ahead when the tooling catches up. What systems in your stack would you expose as MCP servers?
Where MCP is right now¶
MCP is an evolving standard. Anthropic published the initial spec; it's now being adopted and extended by other model providers and tool builders. Not every AI tool supports it yet. But the direction is clear: the industry is converging on a standard for how models talk to the world.
The stateless chatbot era is ending. What comes next looks a lot more like an operator that actually knows what it's working with.
Frequently asked questions¶
Is MCP specific to Anthropic/Claude?
No. Anthropic published the initial spec, but MCP is an open standard being adopted across the industry. OpenAI, Google, and many other model providers are implementing it. Community MCP servers work with any compliant client. Think of it like HTTP — Anthropic defined the protocol, but it belongs to everyone.
What's the difference between MCP and function calling?
Function calling is how a specific model invokes a specific tool in a specific conversation. MCP is the protocol layer that standardises how tools are discovered, described, and communicated with across different models and clients. MCP servers expose tools via function-calling interfaces — the two are complementary, not competing.
Do I need a special framework to build an MCP server?
No. MCP servers are just HTTP servers (or stdio processes) that implement a defined protocol. There are SDKs for Python, TypeScript, and other languages that handle the protocol details — but the underlying pattern is straightforward. If you can build a REST API, you can build an MCP server.
How does MCP handle security?
The protocol defines the communication format; security is your responsibility to implement on top. In practice this means JWT auth or API keys for every request, per-tool permission scoping, and structured audit logging. The MCP in the Real World post covers the production security model in detail.
Is MCP production-ready?
For the core protocol: yes. For the broader ecosystem — specific community MCP servers, enterprise integrations, multi-agent orchestration patterns — maturity varies. Evaluate each server you adopt independently. The protocol itself is stable enough to build on; the surrounding tooling is still evolving rapidly.
The working code¶
If you're building MCP infrastructure for production — service account auth, per-caller tool scoping, rate limiting, audit logging, prompt injection detection — the companion repo has a complete gateway implementation you can wire into your own HTTP server.