MCP: A Standard for Action, Not Knowledge

I. MCP in Perspective: What the Celebrated Standard Delivers, and What It Doesn’t

Currently, MCP – the Model Context Protocol – is being celebrated as the universal connector for AI. The “USB-C port for LLMs.” A standard, at last, that ends the chaos of proprietary AI interfaces. And that much is true.

But a connector says nothing about what you should plug into it. This is exactly where the thinking error begins – one being made over and over in architecture discussions right now.

A. What MCP Actually Solves

Let’s start with the credit, because it is deserved. Until now, every connection between a language model and a source system was manual work – its own interface, its own logic, its own maintenance overhead. MCP standardises that. A model can talk to tools and data sources through a single, uniform protocol instead of building a custom workaround for every system. For integration work, that is real progress.

The problem is not the protocol. The problem is what people use it for.

B. The One Distinction That Decides Everything: Knowledge vs. Action

There is a dividing line that, in practice, decides cost, performance and operability – and that the hype almost always skips over: the difference between knowledge and action.

Knowledge means reading data. “Which open quotes do we have for this customer?” One query, one answer.

Action means changing something in the target system. “Set the status of this quote to ‘presented’.” A targeted write operation.

MCP is built for actions. For targeted, clearly defined operations in a system it plays to its strengths – standardised, traceable, low overhead. For pure mass data retrieval, on the other hand, it quickly becomes the most expensive option you can choose.

C. Where It Gets Expensive

Take the harmless question: “Which open quotes do we have for customer X?”

In a pure MCP approach, the system sends the language model off to search. The model calls the data source, gets back raw data, filters it, reasons about it, perhaps asks again. And this is precisely where three effects arise that are reliably underestimated in projects:

First, the context-window explosion. Everything the data source returns lands in the model’s working memory. With several connected systems, the volume of data processed per interaction grows rapidly – and the model becomes noticeably slower.

Second, the latency from multiple steps. If the AI needs three stages – search, request details, act – that means three full processing cycles in sequence. For real-time use at the workplace, often too slow.

Third, and economically the most dangerous: cost scales with the number of users. What a classic, deterministic filter handles for a fraction of a cent, you here have the model work out anew at every reasoning step – and you pay for every word processed. With ten pilot users it goes unnoticed. With a thousand in rollout, it does not.

D. The Underestimated Gap: Governance

There is one point that almost entirely disappears in the hype and is becoming a knockout criterion precisely in industry: permissions.

MCP brings no rights management of its own. If the model has access to a system through a connection – how does the system know whether the human in front of the screen is even allowed to see this data? In a world of finely graded roles, sales territories and confidentiality levels, that is not an academic question. Whoever fails to solve it cleanly has either a security gap or enormous additional effort – usually both.

E. The Clean Cut in Practice

The solution is unspectacular, and that is precisely its strength. You use MCP where it was built to be used – and for reading, the pattern that was made for it.

For the knowledge side, meaning all read access, the established means is a RAG system (Retrieval-Augmented Generation). The principle: instead of letting the model blindly search a data source, the relevant data is found in advance via semantic search, filtered, and handed over as compact, dosed context. An upstream cache answers identical questions instantly, with no model call at all. The model receives not the raw inventory but exactly what it needs to answer – cheap, fast, with traceable relevance. Solving precisely this task via MCP would mean using the tool against its strength.

For the action side, the write access, MCP then comes into play – and rightly so here. But encapsulated, with a permissions layer in front of it. When the model wants to trigger an action, the user token is passed along. The action runs in the user’s name. If that user has no write rights in the target system, the backend blocks it – before the model even begins to “think.” The governance problem thus sits where it belongs.

The same question about open quotes is answered, in this model, cheaply and quickly from the read path. Only when the user actually wants to change something does MCP enter the picture – controlled, one-off, targeted.

F. Conclusion

MCP is an excellent integration standard. It ends the interface chaos and is the right path for action-based agent scenarios. But it is not the operating system for a company’s data – and should not be made into one.

The hype suggests routing everything through this one, conveniently universal connector. Whoever follows that builds in token explosion, latency and a governance gap. Whoever instead understands MCP as what it is – a strong standard for targeted actions, not the answer to every data question – gets exactly the value the protocol really delivers.

A standard is not an architecture concept. The difference is one you pay later – or not at all.