MCP replaced building every tool for every app with building each one once. The good and the bad both follow from that.
Highlights
- Before MCP, five AI apps and five tools meant twenty five separate integrations. Now it means ten.
- Anthropic published MCP in November 2024 and gave it to the Linux Foundation in December 2025, so it belongs to everyone now.
- It spread fast. By May 2026 the official registry listed close to ten thousand servers.
- A server offers three things, not one: tools the model can call, resources it can read, and prompts you pick yourself.
- The model never runs anything. It asks, and your code decides. Every security control lives on your side.
- Tool descriptions reach the model as context, so a bad one can carry hidden instructions. Read them before you connect.
- The
2026-07-28spec is the biggest update since launch, with a simpler core and tighter auth.
Here is the problem MCP was built to fix.
Say you have five AI apps and five tools you want them all to use. Before MCP, that meant writing twenty five separate integrations. Five apps, five tools, one connector for every pair. Add a sixth tool and you write five more.
With a shared protocol, it becomes ten. Each app speaks the protocol once. Each tool speaks it once. Twenty five becomes five plus five.
That is the whole idea, and it explains everything that followed. It explains why adoption was so fast. It also explains why the security questions turned up late, after everyone had already plugged things in. This post covers what the protocol is, what a server offers, how a conversation flows, the security model in real detail, and three worked examples where the right answer differs.
What MCP is
The Model Context Protocol is an open standard for connecting AI apps to tools and data. Build a tool once and any compatible app can use it.
It is plumbing, not intelligence. It does not make models smarter. It makes their connections reusable.
Did you know
MCP borrowed its design from something older. Code editors had the same problem years ago. Every editor needed its own plugin for every language, so adding a language meant work in every single editor. The Language Server Protocol fixed it. Write one language server, and any editor can use it. That is why your editor supports languages its authors never touched. MCP is the same idea, pointed at AI apps and tools, which is why the architecture feels familiar if you have ever read the LSP spec.
Where it stands in 2026
Worth knowing, because it tells you whether this is a bet or a safe default.
Anthropic published MCP in November 2024. OpenAI adopted it in March 2025. Google DeepMind followed in April. Microsoft and GitHub in May. That is fast for a standard that started at one company.
Then in December 2025, Anthropic handed it to the Agentic AI Foundation under the Linux Foundation. Platinum members include AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. It stopped being one vendor's protocol.
By May 2026 the registry listed 9,652 servers. GitHub carried nearly sixteen thousand repos tagged as MCP servers. Monthly SDK downloads passed ninety seven million.
The 2026-07-28 spec is the biggest revision since launch. It brings a simpler stateless core that runs on ordinary HTTP, a framework for extensions, better alignment with OAuth, and a formal deprecation policy.
That last one matters more than it sounds. A deprecation policy is how a protocol changes without breaking what you built.
What a server actually offers
Most explanations mention tools and stop there. There are three things, and the difference is about who decides.
Tools are functions the model can call. Create a ticket. Fetch a build log. The model picks when.
Resources are data your app can read, addressed by URI. A file, a record, a config. Your app decides what to load, not the model.
Prompts are templates a person picks from a menu. The human decides.
List a server's tools and you know what it can do to you. List its resources and you know what it can see. People check the first and skip the second.
How a conversation flows
Six steps. Step three is the one that matters.
Your client connects and asks what the server offers. It gets back a list of tools with names, descriptions, and input schemas. Those descriptions go into the model's context.
You ask a question. The model decides a tool would help and asks for it by name.
Your client gets that request and decides whether to allow it. The model has not run anything. It sent a message saying it would like something run.
Your client calls the server. The server runs it and returns a result. That goes back into the model's context. The model either answers or asks for another tool.
Step three is your entire security model. A tool you never wrote cannot be called, no matter what the model asks for.
import asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client
READ_ONLY = {"get_pipeline_status", "get_build_log", "list_recent_failures"}
async def main() -> None:
params = StdioServerParameters(command="python", args=["-m", "ci_mcp_server"])
async with stdio_client(params) as (read, write):
async with ClientSession(read, write) as session:
await session.initialize()
for tool in (await session.list_tools()).tools:
mark = "allow" if tool.name in READ_ONLY else "BLOCK"
print(f"[{mark}] {tool.name}")
print(f" {tool.description}")
result = await session.call_tool(
"get_pipeline_status", {"pipeline": "checkout-api"})
print(result.content[0].text[:400])
asyncio.run(main())Three things there are worth copying.
The allow list lives in code, not in a prompt. An unexpected tool cannot be called, whatever the server advertises.
Printing every description before calling anything is the habit this whole post argues for. You are looking for a description that says more than it should.
And initialize is the handshake. It is how a client and server built against different spec versions agree on what they both support.
Watch out
The most common misunderstanding is thinking MCP lets the model act. It does not. The model asks. Your client decides. So every security control lives in your client, and none of it lives in your prompt. Writing careful instructions telling the model which tools to avoid is not a control, because the model is the thing being influenced. Put your allow list, your approval gate, and your credential limits in code. Treat the prompt as documentation, and treat code as enforcement.
Learn MCP hands on
This gets much easier once you have built a server and watched a client discover it. The MCP For Beginners course on KodeKloud covers the introduction, core concepts, and daily use, including building servers over HTTP or stdio in Python or Node.
The security part, which is the real story
MCP created new ways to be attacked, and the ecosystem's security caught up slower than its popularity. Here are the specific mechanisms.
Tool poisoning. Tool descriptions are sent to the model as context. So they are instructions, whatever we call them. A bad server can hide text in a description that steers the model before you have typed anything. You see a tool name in a menu. The model sees the whole description.
Prompt injection through data. A tool returns content with instructions buried in it. A build log, a ticket, a web page. The model may follow them.
Confused deputy. A server holds broad credentials and acts for a model that was influenced by untrusted input. The server is authorised. The request is wrong in intent, not in form. Nothing in the protocol tells them apart.
Supply chain. Roughly ten thousand public servers exist. Most are one person's side project. Connecting one runs their code with whatever access you gave it.
In the wild
Security research through 2026 keeps landing on the same structural point. MCP puts an AI model in the middle, making decisions, and that model can be talked round by its own input. Normal security assumes something different. You validate input at the door, and after that the program behaves predictably. An MCP client hands untrusted content to a component that content can influence, then acts on what comes back. That is why the controls that work are structural, meaning allow lists, scoped credentials, and approval gates. Not instructions.
Three examples, worked through
Same protocol, three connections, three different right answers. Each turns on a different question.
Connecting a CI system
You want to ask about build failures without opening a dashboard.
The question it turns on. What can this server change?
Work through it. List the tools and sort them into two piles. Reading a log, listing failures, getting a status: all read only. Triggering a build, cancelling a job, promoting an artifact: all writes.
The first pile can go live this afternoon. The worst a confused model can do is give you a wrong answer. The second pile waits behind an approval gate, as a separate decision.
The thing to check. Which credentials the server holds. A CI token with admin scope, handed over so the server can read logs, is the confused deputy problem waiting to happen. Issue a read only token. Then check what the server actually asks for, not what its docs claim it needs.
Exposing cost and inventory data
Your team fields constant questions about what is running and what it costs.
The question it turns on. Where does this data end up?
Work through it. Cost data is read only by nature, so the biggest risk category disappears immediately. What replaces it is a data question, not a protocol one.
An MCP connection means that data flows into a model's context. So it flows wherever the app sends context. Find out where that goes, whether it is retained, and whether your classification allows it. This takes an afternoon and is far easier before you connect than after.
The design that works. Narrow tools, not one general query tool.
Narrow tools are more work to write. They are also the ones you can reason about. A tool that takes a month and returns totals has a knowable worst case. A tool that takes any input inherits every power its credentials hold.
Enabling MCP across many teams
People are already connecting servers on their own. You are asked to make that safe, not to stop it.
The question it turns on. How do you make the safe path the easy path?
Work through it. Stopping this is not an option, because the value is real and it is already happening. What works is an internal registry with a review gate. The shape is familiar from container images: a curated set people pull from, with pinned versions.
What the gate checks. Is the server first party or vetted? What credentials does it want, and can they be narrowed? What do its tools really do, including the full descriptions? Are write tools kept separate from read only ones, so they can be approved on their own?
Build this first. Audit logging of every tool call, with arguments.
logger.info("mcp_tool_call", extra={
"server": server_name,
"tool": call.function.name,
"arguments": json.loads(call.function.arguments),
"caller": user_id,
"allowed": call.function.name in policy.allowed_tools,
})Nobody builds this until they need it. When something goes wrong, it is the difference between an investigation and a shrug. Note that allowed gets logged even when true, because knowing what was permitted matters as much afterwards as knowing what was blocked.
In the wild
Look at what all three had in common. The protocol was never the hard part. Connecting a server takes minutes. The work is deciding what it may touch, what its credentials allow, and whether anyone would know afterwards. Teams that treat MCP as an integration project finish the integration by lunchtime, then spend a quarter on the questions above. That is the right order to find them. It is a better order to expect them.
Practise building both sides
You understand this properly once you have built a server as well as connected to one, because the security model only becomes real when you see what a server can advertise. The Introduction to OpenAI course on KodeKloud covers the model and tool calling layer underneath MCP, and the KodeKloud playgrounds give you somewhere to run a server and client together.
Try this on your own tooling
Give it an afternoon. The first part is just looking.
Pick one MCP server you have connected, or one you have been meaning to. List its tools with full descriptions, not just names. Read every description all the way through.
You are looking for two things. Does any tool do more than its name suggests? Does any description contain something that reads like an instruction? That takes ten minutes and almost nobody does it.
Next, find out which credentials that server holds and what they allow. Ask yourself a simple question. Could a confused or compromised server do anything you would not let a new colleague do with the same access?
Now build the smallest client you can, with an allow list in code, and connect it to one server with read only tools. Call one tool and read the raw result, not the model's summary of it. Seeing what actually comes back is what makes the injection risk real instead of theoretical.
Finally, write down which of your connected servers can write, delete, or spend money. That list is your real risk register. Most teams have never made it.
What you should be able to answer now
Why does MCP exist? If the answer is not "twenty five integrations became ten," the rest of the topic will keep feeling like vocabulary.
Where does security live? In your client, in code. Anyone who says "in the prompt" has it backwards, because the model is the thing being influenced.
What can each connected server write to? Most teams cannot say. It takes twenty minutes to find out and it is the most useful list in this whole topic.
Have you read the tool descriptions of servers you trust? Descriptions are instructions to the model in all but name. Reading them is a security review, not documentation browsing.
The maths at the top of this post explains the good and the bad in one breath. A protocol that makes it trivial to connect anything to anything also makes it trivial to connect something you never checked. The teams doing this well are not the cautious ones. They are the ones who read the descriptions, scoped the credentials, and kept the allow list in code where it does something.
Ready to Build With MCP Properly?
MCP makes most sense when you build both sides, since a server's powers and a client's controls only fit together once you have seen both. The MCP For Beginners course on KodeKloud covers core concepts and building servers over HTTP or stdio in Python or Node. The Introduction to OpenAI course covers the tool calling layer underneath. And the KodeKloud playgrounds give you somewhere safe to run both together. Start by reading one server's tool descriptions.
FAQs
Q1: What is MCP in simple terms?
It is an open standard for connecting AI apps to tools and data, so a tool built once works with any compatible app. The problem it solved is a maths problem. Five AI apps and five tools used to mean twenty five separate integrations, each maintained on its own and each breaking on its own schedule. A shared protocol turns that into ten, because each app speaks the protocol once and each tool speaks it once. The design borrowed from the Language Server Protocol, which fixed the same shape of problem for code editors. Before that, every editor needed its own plugin for every language. Worth being clear that MCP is plumbing rather than intelligence. It does not make models more capable. It makes their connections reusable. That distinction explains both why adoption moved so fast and why the interesting problems are about trust rather than about models.
Q2: What does an MCP server actually offer?
Three things, and the difference is who decides. Tools are functions the model can call during a conversation, like creating a ticket or fetching a log, and they carry the most risk because they act. Resources are data your app can read, addressed by URI, such as a file or a record, and your app decides what to load rather than the model, which makes them safer for supplying context. Prompts are templates a person picks from a menu, so a human decides. Most explanations mention only tools, which leaves people confused when they read a real server. In practice, listing a server's tools tells you what it can do to your systems, and listing its resources tells you what it can see. Teams routinely check the first and skip the second, which is a shame, because that is where data exposure lives rather than where damage lives.
Q3: Is MCP secure, and what should I worry about?
The protocol is reasonable. The ecosystem's security lagged its popularity badly. So the honest answer is that it is as safe as the controls in your client. Five risks matter. Tool poisoning, where instructions hide inside a tool's own description and reach the model before you type anything, which is why reading descriptions matters. Prompt injection, where a build log or ticket carries text aimed at the model rather than at a person. Confused deputy, where a server with broad credentials acts for a model that was steered by untrusted input. Supply chain risk, since most of the ten thousand public servers are side projects. And too much access, meaning write tools switched on by default. The structural point underneath all of it is that a model sits in the middle making decisions and can be talked round by its own input, which normal security models were never built for. The controls that work are structural: allow lists in code, narrow credentials, approval gates for writes, and audit logs.
Q4: What do I need before building or connecting a server?
Ordinary software skills, plus one idea that changes how you design everything. That idea is this: the model never runs anything. It sends a structured request naming a tool and its arguments, and code you wrote decides whether to honour it. So every security control lives in your client and none of it lives in your prompt. A tool you never implemented cannot be called, whatever a server advertises or a model asks for. On the practical side, you need a language with an SDK, which today means Python, TypeScript, and several others. You need to be comfortable with JSON schemas, since that is how tool inputs are described. And you need to know the two transports: stdio for local processes, streamable HTTP for remote servers. Beyond that, the useful habits are reading full tool descriptions before trusting a server and scoping credentials tightly. The MCP For Beginners course on KodeKloud covers building servers with either transport.
Q5: How is MCP different from normal function calling?
Function calling is the model's ability to ask for a tool. MCP is the standard for how that tool gets described, discovered, and reached across different apps. Without a protocol, every app builds the plumbing its own way, so a tool must be rebuilt for each one and the work multiplies. MCP standardises the transport, the handshake where a client asks what a server offers, the schema format for inputs, and the shape of results. One server then works with any compatible client. It also adds things function calling never had, specifically resources for app controlled data access and prompts for user picked templates, so it covers more than actions. The real difference is ecosystem rather than capability. Function calling lets a model use a tool you built. MCP lets a model use tools other people built. That is a much bigger change, and it is why the trust questions became urgent so quickly.
Q6: Should we adopt MCP now, and how do we start safely?
Treat it as a default rather than a bet. OpenAI, Google, Microsoft, and AWS have all built it into their agent stacks, and Anthropic gave the protocol to the Agentic AI Foundation under the Linux Foundation in December 2025, which made it genuinely multi vendor. Start read only. That is the single most useful piece of advice here. Connect servers whose tools only read, meaning fetch a log, list resources, get a status. Then the worst a confused model can do is give a wrong answer rather than take an action you never approved. Add write tools afterwards, behind an approval gate, as a separate decision made with evidence about how the read only version behaved. Alongside that, scope credentials per server rather than reusing an admin token, read the full tool descriptions of anything you connect, and build audit logging of tool calls before you need it. For teams enabling this broadly, an internal registry with a review gate beats a policy document, because it makes the safe path the easy one.
Discussion