In many organizations, APIs are already considered strategic assets. But often only for those who truly understand them. The Model Context Protocol – or MCP for short – might change that. Quietly, but fundamentally.
My first encounter with MCP wasn’t a spec – it was a demo. During Softwarearchitektur im Stream, Ralf D. Müller demonstrated how Claude – Anthropic’s language model – could independently use tools via a custom-built browser tool. No copy-pasting, no roundabout commands. Just: “Do this,” and Claude figured out the rest.
What fascinated me most: the task came from a human, but the how was decided by the AI. The focus was on the what, not the how. If you apply that principle to APIs, something fundamental shifts. Interfaces no longer need to be manually operated – they simply need to be made available in a way that a machine can understand and use.
That’s precisely the idea behind the Model Context Protocol, or MCP. A protocol that allows language models to grasp APIs – their functions, data structures, and workflows – in a way that makes them usable. Not in some distant future, but today.
What is MCP – and why does it matter?
The Model Context Protocol (MCP) isn’t a new API standard in the traditional sense. It doesn’t replace interfaces, formats, or transport mechanisms. Instead, it augments existing APIs with something that’s often missing: structured context for machines, especially for language models.
Specifically, MCP defines how a system can expose information about its capabilities – in a format that’s understandable to generative AI. These so-called Capabilities describe not just what a service can do, but also how typical requests look, what parameters are required, and what kind of responses can be expected, not as documentation for humans, but as structured guidance for models.
There’s no single use case in focus. A Capability might create a database entry, send a message, or retrieve a report – the key is that an AI system can infer how to use it.
The real difference from traditional API documentation lies not in the what (“What operations exist?”), but in the why (“What can I accomplish with this?”): MCP aims to let machines understand and operate APIs, not humans. Interfaces become tools that can be controlled by language models – depending on context, intent, and goals.
This has far-reaching consequences. Because if AI systems don’t just write text but also interact with real services, it shifts the relationship between user, application, and interface. The question is no longer “Which API do I need to call, and how?”, but: “What task am I trying to accomplish – and what’s available to help me do it?”
From API to outcome: Why accessibility makes the difference
From a business perspective, MCP doesn’t initially appear revolutionary. Interfaces remain what they are: technical access points to functions, data, and processes. But the way they’re used is changing – and that can have strategic impact.
A clear benefit is simplified integration. When an AI system can independently figure out how to interact with a service, much of the manual effort disappears: no more hunting for code examples, recreating auth flows by hand, or trial-and-error in API testing tools. Instead, a goal is defined (“Upload current sales figures”), and the AI figures out the path using the available capabilities.
This lowers barriers – not just for developers, but also for teams with limited API experience. Internal platforms could gain new self-service functions. Even product-adjacent roles might be able to work with systems that previously required technical dependencies.
MCP also improves accessibility for AI-powered tools: language models like Claude or ChatGPT, embedded in assistants or agents, can use MCP to work productively with APIs – without requiring any changes to the interfaces themselves. The interface stays the same; the added context makes all the difference.
And lastly, MCP shifts how we think about APIs themselves. If interfaces must be contextualized rather than simply exposed, new questions emerge:
- How do I describe a function so it’s discoverable and usable?
- How do I enable access without compromising control or security?
- Which interfaces do I want to make visible – and to whom?
What makes MCP particularly compelling: It doesn’t require new specialist tools. It works directly within existing applications. In the desktop apps of ChatGPT or Claude, users can simply state a task – like “Send me the current pipeline from the CRM” – and the model uses the registered capabilities in the background. No new interface, no extra UI – just a model that understands the tools at its disposal.
For many companies, this is a new form of accessibility: APIs not only become easier to integrate, but also easier to reach. And in the long run, that may prove more impactful than any new API technology.
MCP in the field: Who’s already on board – and what’s emerging
The Model Context Protocol was introduced by Anthropic in November 2024 – as a pragmatic solution to a concrete problem: How can a language model reliably understand which external tools and interfaces it’s allowed to use – and how?
Just a few months later, OpenAI also announced support for MCP. That made one thing clear: this protocol isn’t tied to a single AI provider. On the contrary – it’s rapidly evolving into a vendor-agnostic standard for AI-driven interface access.
Microsoft is also actively involved. In Copilot Studio, MCP is used to provide actions and knowledge sources automatically – for example, in the development of internal AI applications or agents. The Azure AI Agent Service supports MCP as well. And with the open-source project Playwright-MCP, Microsoft has even released its own MCP server that allows language models to navigate the web autonomously.
The ecosystem around MCP is growing. Platforms like mcpt.com or mcp.run are building early catalogs of context servers. Here, existing capabilities can be searched, tested, and linked to your own services. The idea is reminiscent of early API marketplaces – but with a crucial difference: today’s primary users are no longer humans, but models.
The open-source community is active as well. Several MCP server implementations are already available on GitHub – in different languages and with various goals. Entry barriers are low, and interest is high.
Of course, this is not yet a fully mature ecosystem. But the speed at which the idea is gaining traction is striking. And it suggests that MCP isn’t just a compelling concept – it’s here to stay.
Between ambition and reality: What’s still to be addressed
As promising as MCP is, it would be naive to look only at the upside and ignore the open questions. As with any emerging technology, uncertainties remain. Some are technical, others revolve around processes, roles, and accountability.
Technical maturity
MCP is still young. The specification is evolving, and early implementations are just now appearing. That means anyone jumping in today is stepping into a rapidly changing environment – with all the risks and opportunities that come with it. What works today might change tomorrow. What’s missing today could become tomorrow’s standard.
Standardization and interoperability
MCP is open – but not (yet) a formal standard. There’s no standards body, no governance model, no defined roadmap. The fact that major players like Anthropic, OpenAI, and Microsoft are adopting it is a positive sign. But whether it will become a stable, interoperable standard remains to be seen.
Security and governance
When language models can access APIs, the question inevitably arises: Who decides what’s allowed – and based on what? MCP provides technical mechanisms for access control – for example, through capability registration and visibility settings. But that’s not enough. Companies will need to define governance models for AI access – and consider how to prevent misuse or unintended consequences.
Responsibility and traceability
A language model that interacts with APIs autonomously is not deterministic. It interprets. That can be incredibly helpful – or lead to unexpected behavior. So who’s responsible in such cases? Who can explain what happened – and why? These questions aren’t new, but MCP makes them practically relevant.
Organizational impact
Finally, there’s the question of where such interfaces will be anchored: within dev teams? In AI departments? On the platform team? And who decides which capabilities are offered – or which are too “open”? MCP isn’t just a technical decision – it affects teams, roles, and processes.
What to do with MCP? Start by paying attention
MCP isn’t a tool you just install. Nor is it a plug-and-play solution ready for universal deployment. But it is a spark – one that rethinks the interface between humans, AI, and systems. And anyone thinking about API strategy should at least take a closer look.
What does that mean in practice?
Follow developments actively – not passively
MCP is evolving fast. New integrations, tools, and specs emerge almost weekly. It pays to track these developments – on GitHub, in marketplaces, and through updates from major vendors. Those who follow now will better understand what’s possible tomorrow.
Run small experiments
MCP can be tested fairly easily – for example, with a basic internal context server for selected functions. This builds visibility inside the organization and helps clarify opportunities and limitations. Especially valuable: include perspectives from product, platform, and AI teams together.
Think of accessibility as a strategic goal
MCP’s biggest impact may not lie in the tech itself, but in how it changes access to APIs. Describing interfaces so that language models understand them also opens them up to new user groups – internal or external. This can be a powerful lever for platform strategies and developer experience.
Clarify requirements – technical and organizational
Sooner or later, questions will arise: Who owns the capabilities? Who decides what gets exposed – and how? MCP doesn’t require an overhaul of your infrastructure, but it does require new thinking about roles, visibility, and access. And the sooner that happens, the better.
More than a standard – less than a hype
The Model Context Protocol isn’t a magic bullet – nor is it a fleeting trend. It’s a serious attempt to make APIs more accessible – not by simplifying them, but by explaining them better. For machines.
What emerges from this is more than a technical detail. It changes how we think about APIs: from integration points to describable tools in service of the user. And it opens up new spaces – for new roles, new uses, new products.
Whether MCP will be a de facto standard in a year or just one of many ideas, no one can say. But it’s a good time to get involved. Not because you have to – but because you can.
