If you read software release notes, you have started seeing three letters everywhere. MCP. It shows up in AI product announcements, developer tool updates and enterprise platform launches, usually without anyone stopping to say what it is.
The Model Context Protocol is an open standard that defines how AI models connect to external tools, data and services. It was created at Anthropic, adopted within months by OpenAI, Google DeepMind and Microsoft, and is now governed under the Linux Foundation.
The reason it spread so quickly is not that it is clever. It is that it replaced something genuinely miserable.
Table of contents
- The problem MCP solved
- What MCP actually is
- The USB-C analogy, and where it breaks
- How MCP differs from a normal API
- Who is behind it now
- What the maintainers say is still unfinished
- The security question
- Does this matter if you are not a developer?
- FAQs
The problem MCP solved
Before MCP, connecting an AI model to an external service meant writing custom code for that specific pairing.
If you wanted your AI assistant to read your calendar, someone wrote a calendar integration. To also read your files, a separate file integration. To do the same for a different AI model, you largely started over, because each model handled tool connections its own way.
The arithmetic is the problem. Every new model multiplied against every new service, each combination needing bespoke work and separate maintenance. Anyone who lived through the era before USB — a different cable and driver for every peripheral — recognises the shape of it.
MCP replaces that with one specification. Build an MCP server for your service once, and any MCP-compatible AI application can use it. Build an AI application that speaks MCP, and it can reach every MCP server that exists.
What MCP actually is
Three roles, and the vocabulary is worth having because it appears in every announcement you will read.
The MCP server exposes a capability. It wraps a service — a database, a file system, a project tracker, a search index — and describes, in a standard format, what it can do and what information it needs.
The MCP client sits inside an AI application and knows how to talk to servers.
The host is the application the person actually uses — a chat interface, a coding tool, an internal assistant.
The user asks for something. The AI works out that an external capability is needed. The client calls the relevant server. The server does the work and returns a result. The AI uses that result in its answer.
What the standard defines is the conversation between those parts: how a server advertises capabilities, how requests and responses are structured, how errors are reported. It does not define what your tool does or how it is built.
The USB-C analogy, and where it breaks
The comparison used everywhere, including in the project’s own material, is that MCP is the USB-C port for AI — a universal connector that lets any AI application plug into any data source without custom wiring.
It is a good analogy and worth knowing where it stops being accurate, because the gap is where most misunderstanding lives.
Where it holds: one standard replacing many bespoke connections; write once, connect to many; the connector defines the interface, not the device.
Where it breaks: USB-C moves data between devices that do not interpret it. MCP connects a language model — a system that reads everything it receives as potentially meaningful, including instructions. A USB cable cannot be talked into doing something it should not. This distinction is not academic; it is the root of the security question later in this article.
Also worth noting: USB-C is a finished, stable specification. MCP is a young standard under active development, with its maintainers openly working through unsolved scaling problems.
How MCP differs from a normal API
Most services already have an API. A reasonable question is why AI needs a different one.
| Traditional API | MCP | |
|---|---|---|
| Designed for | Software written by a developer | An AI model deciding at runtime |
| How capabilities are discovered | A human reads documentation | The server describes them in a standard format the model can read |
| Who decides what to call | The programmer, in advance | The model, during the conversation |
| Adapting to a new service | Write new integration code | Connect to its MCP server |
| What is standardised | Nothing across services | The shape of the interaction |
The essential difference is who is doing the deciding. A traditional API assumes a developer studied the documentation and wrote code that calls specific endpoints in a specific order. MCP assumes the caller is a model working out what it needs as it goes, which means capabilities have to be self-describing rather than documented for humans.
MCP does not replace APIs. Most MCP servers are wrappers around existing APIs, translating them into a form a model can navigate.
Who is behind it now
This is the part that has changed most recently, and it is a genuine credibility signal.
MCP began at Anthropic. It could have stayed a single company’s specification. Instead it was adopted by OpenAI, Google DeepMind and Microsoft — competitors agreeing on a shared standard, which is rarer than it sounds — and governance has since moved to the Linux Foundation, with MCP now operating as a Series of LF Projects, LLC.
The practical machinery matters more than the badge. Development runs through Working Groups rather than a small maintainer team, changes are proposed through a documented Spec Enhancement Proposal process, and the project is building a formal contributor ladder so there is a defined path from community participant to maintainer.
For anyone evaluating whether to depend on this, that structure is the relevant question. A specification controlled by one vendor is a strategic risk. A specification under neutral foundation governance with a public change process is a much easier dependency to justify.
What the maintainers say is still unfinished
Most coverage of MCP is written by people enthusiastic about it. The most useful critical source is the project itself, whose 2026 roadmap, published on 9 March 2026, is refreshingly direct about what does not work yet.
Scaling is genuinely awkward. Streamable HTTP — the transport that lets MCP servers run as remote services rather than local processes — unlocked production deployment and surfaced consistent gaps. In the maintainers’ own words, “stateful sessions fight with load balancers, horizontal scaling requires workarounds, and there’s no standard way for a registry or crawler to learn what a server does without connecting to it.”
Long-running tasks are still being worked out. The Tasks primitive shipped as an experimental feature, and production use has surfaced lifecycle gaps around retry behaviour when something fails transiently and how long results should be retained.
Enterprise features are the least developed. Audit trails, single sign-on integration, gateway behaviour and configuration portability are all named as problem areas. The roadmap describes enterprise readiness as “the least defined of the four priorities,” and notes that a dedicated Enterprise Working Group did not yet exist at the time of writing.
Governance itself is a bottleneck. Every proposal currently requires full core maintainer review regardless of domain, which the maintainers acknowledge slows down groups that already have the relevant expertise.
TechyKnow’s read: none of this suggests MCP is a bad bet — a project this candid about its gaps is usually a healthier one than a project that is not. But anyone told MCP is a finished, enterprise-ready standard is being oversold. It is a fast-moving young specification that has been adopted faster than it has been hardened, which is a normal and slightly uncomfortable place for infrastructure to be.
The security question
The point where the USB-C analogy fails is the point where security gets interesting.
Connecting an AI model to your tools means granting a system that follows instructions the ability to act on your data. If any content that model reads can contain instructions — and in practice it can — then every connection is also a potential path in. Documented findings in this category already include work against MCP integrations specifically.
This is not an argument against MCP. It is an argument for treating MCP connections as access grants rather than conveniences: connect only what a given assistant genuinely needs, prefer read-only where possible, and keep a record of what is connected to what. The project’s own roadmap lists deeper security and authorisation work among the areas awaiting community-led development, which is a fair signal of where the standard currently sits.
Does this matter if you are not a developer?
Three honest answers depending on who you are.
If you use AI tools at work: indirectly, yes. MCP is why the assistant you use can suddenly see your project tracker or your documents. When a vendor announces MCP support, they are telling you what that product can now reach. That is worth reading as a permissions statement rather than a feature.
If you make software buying decisions: yes, and the useful question is specific. “Does this support MCP?” tells you whether a tool will connect to the rest of your AI stack without bespoke integration work, which is a real cost difference. It is also a reasonable proxy for whether a vendor is building for interoperability or for lock-in.
If you are just curious: learn the term and move on. You will not interact with MCP directly. You will interact with things built on it, and knowing what it is makes a lot of otherwise opaque product announcements legible.
The broader pattern is one TechyKnow has followed through low-code and no-code development: standards and abstractions that remove integration work always spread fast, and the governance question — who controls the standard — matters more than the technology once adoption is established. It is also the connective tissue underneath the agentic AI shift, since an agent that cannot reach any tools is just a chat window.
The practical next step: next time a tool you use announces MCP support, read it as a list of what that tool can now reach, and check whether you are comfortable with that list. The standard is the plumbing. The permissions are the decision.
FAQs
What is the Model Context Protocol?
MCP is an open standard defining how AI models connect to external tools, data sources and services. Instead of writing custom integration code for every combination of model and service, developers build one MCP server per service, and any MCP-compatible AI application can use it. It was created at Anthropic and is now governed under the Linux Foundation.
What does MCP stand for in AI?
Model Context Protocol. The name describes its function: a protocol for supplying a model with context and capabilities from outside itself.
What is an MCP server?
An MCP server wraps a service — a database, file system, project tracker or search index — and describes in a standard format what it can do and what information it needs. AI applications that speak MCP can then use it without any service-specific code.
How is MCP different from an API?
A traditional API assumes a developer read the documentation and wrote code calling specific endpoints. MCP assumes the caller is an AI model deciding at runtime what it needs, so capabilities must be self-describing rather than documented for humans. MCP does not replace APIs — most MCP servers wrap existing ones.
Who created MCP and who controls it now?
It was created at Anthropic and adopted within months by OpenAI, Google DeepMind and Microsoft. Governance has since moved to the Linux Foundation, where MCP operates as a Series of LF Projects, LLC with formal Working Groups and a public Spec Enhancement Proposal process.
Is MCP secure?
MCP connections should be treated as access grants rather than conveniences. Connecting a model to your tools gives an instruction-following system the ability to act on your data, and prompt-injection findings have been reported against MCP integrations. The project’s own roadmap lists deeper security and authorisation work among areas still awaiting development.
What are the limitations of MCP?
The project’s 2026 roadmap names four: transport and scalability problems where stateful sessions conflict with load balancers, unfinished lifecycle handling for long-running tasks, enterprise features such as audit trails and single sign-on described as the least defined priority, and a governance bottleneck where every proposal needs full core maintainer review.
Do I need to know about MCP if I am not a developer?
Only in one practical sense. When a product announces MCP support, it is telling you what that product can now connect to. Reading those announcements as permissions statements rather than feature news is the useful skill for a non-developer.
