What is MCP, and why should I care?

Andreas Schwarz 19. Mai 2026

mcpagentsaicontext-windowintegration

A plain-language guide to MCP (Model Context Protocol) in 2026.

TL;DR

MCP (Model Context Protocol) is a plug between AI and software. It lets an AI agent read from and write to your CRM, your inbox, your documents.
MCP is foundational for the transition from chatbot to agent.
The context window is the most important resource of your agent.
Tool explosion is a fundamental problem of MCP.
We use MCP and solve the tool-explosion problem with neat markdown frontends for agents.

So what is MCP, then?

It’s a GUI for AI.

It is a standardized protocol for executing traditional software through AI. Just like a GUI (Graphical User Interface) lets a human click (or tap) on something, which then triggers some software thing to happen, MCP gives an AI an interface it can understand, and which allows it to trigger some software thing to happen. This can literally be anything (just as in a GUI). The chatbot we had before MCP can now use a computer through MCP. A huge step for AI.

For a human behind a screen, this is normally organized by the operating system, which handles the drivers for mouse, keyboard, screens etc. For AI, things are a little more complicated, because the AI “lives” on a server somewhere usually close to Palo Alto. So when the AI wants to use software, everything needs to go through the internet, and then it had better be secure. These are, among others, the nasty details that MCP handles nicely. It is celebrated for its successful standardization, which lets AI products connect to any MCP server without issues. Feel free to dive in deeper via the original post from Anthropic: a new standard for connecting AI assistants to the systems where data lives.

How does it work?

MCP exposes tools to the AI. And it exposes them by announcing them, saying things like: “Hey, I have this function, it is called weather_forecast, it expects a parameter city, and it will then tell you the weather forecast for that city.” So, when the user asks the chatbot what the weather will be like in Berlin, instead of answering directly, the chatbot can call the function first through the MCP interface, which then finds the weather forecast for Berlin (this is happening in traditional software), and returns it to the chatbot. Now the chatbot has actual useful information for the user, and instead of hallucinating or coming back with a sad “I am sorry but I have no idea”, it can now respond that it will be dark and rainy in Berlin tomorrow (as always).

So, one would think: great! Let’s give the AI many many tools and we’ll all be good.

Unfortunately, tools are heavy on the context window, and this is a problem.

What is the context window again, and why do I need it?

You can think of an AI like an intern, but in a specifically weird way: he’s got a strictly limited amount of time for you. Whenever you start a new AI conversation, it is like you summon up a new intern into existence. That intern knows nothing about you, your business, the way you do things around here, or how to do anything, really. To become useful, he gets an initial briefing, the system prompt. It explains things like “be helpful”, “don’t delete things randomly” etc, and (this is where MCP comes in) it also shows the toolbox to the intern, explains every detail of every tool, how to use it, when to use it, when not to, etc. The intern has to listen to all of this. After that it’s your turn (you are the user), you may ask a question or request something done, the intern might respond, or use a tool, or use many tools, or respond at length. Now, every action is text that fills the context window, and when the context window is full, the intern’s time is up and he leaves. That’s it. A new intern comes in, knows nothing, gets all the explanations again.

To make the handoff a little better there are a few strategies, most notably compression: just before the time is up, the old intern briefs the new intern on what has happened so far. The term compression comes from the idea that the old intern compresses his knowledge in the handoff. The new intern has gotten his initial explanations, toolbox instructions, and now the summary from the last intern. All of this is weighing on the context window. There is, of course, some loss of information in this handoff, especially if it happens in the middle of a workflow. This is also the reason for agent drift, where agents whose context window expires multiple times during a workflow seem to understand the task less well over time. This is not so surprising anymore if you imagine you have the 4th intern who got a handoff from the 3rd intern who got a handoff from the 2nd intern, and so on. Essentially, they are playing the game of telephone until the communication from the initial intent has broken down entirely.

This inefficiency of the handoff, causing the drift and causing real information loss, makes the context window so important. So we want to be careful with the context window, and if possible only put in there what the agents really need. This is, of course, a sharp contradiction to the “give the AI many many tools” idea we had earlier. See also: Your MCP Server Is Eating Your Context Window.

Solving the tool explosion

Fundamentally, this is a problem of how MCP is designed. It doesn’t scale well as we add tools. A few ways to deal with it:

Summon many interns, each with specialized tools for their work only.
Don’t give the whole toolbox upfront; make the agent ask for tools when needed.
Give the agent a super tool that can do everything.
Put the tools right next to the content.

1. Many specialized interns

Always an option, and it can be combined with the other strategies. The downsides: once you scale up to a whole workforce, you soon need an orchestrator, and just like with real people, managing many AIs talking to each other brings quite some overhead, including the telephone-game problem all over again.

2. Progressive discovery

Don’t give the whole toolbox upfront; make the agent ask for tools when needed. This is the strategy OpenAI and Anthropic have largely settled on, and it works reasonably well so far. The agent gets a tool search it can query, and only the matching tools are loaded into context. Anthropic describes their version in Advanced tool use on the Claude Developer Platform.

3. A super tool

The super tool, in this case, is coding itself. This is the idea behind Cloudflare’s Code Mode and OpenClaw. It comes from the realization that your intern is an incredibly fast super programmer. For anything that needs external access, though, we still need to hand over passwords, tokens, API keys. It works incredibly well, until it doesn’t, and then it is hard to track what actually happened.

OpenClaw deserves a closer look. In raw capability, it is unsurpassed and probably unbeatable. It’s a beast that will grind on tasks like nothing else; it is fascinating to watch it write hundreds of outreach emails or build whole software projects and deploy them end-to-end. Still using the intern metaphor, OpenClaw is like an intern agency that acts on your behalf. But when you start working with that army of interns, you have to hand them the keys to your kingdom and trust them to act in your best interest. A trade-off that is justifiable in some cases but comes with serious security implications. We personally don’t want to give our interns control over every part of our company.

4. Tools next to the content

This is not really what MCP encourages, but because we believe it is conceptually the right thing to do, we developed a meta-protocol that lets us do exactly this. We expose a small number of tools that allow an agent to navigate the connected systems like it would in a web browser. Capabilities are discovered through links that appear in the context. From our own experience, we conclude this is an ideal approach for most agentic work. We describe it in technical detail in Browse Mode: A pattern for connecting LLMs to APIs that gets better as you add more.

A good environment for our interns

Most systems in practice use some combination of these approaches. The discussion is clearly not yet settled. But let’s go back to our initial metaphor: the GUI. Imagine our intern coming to work, opening his laptop, and the first thing he sees is:

A list of 150 buttons, each described in terms of what happens under what conditions, and when or when not to press it.

Then we give him a task. It’s his first day. I would totally expect him to mess up.

To be fair, progressive discovery essentially means he has a search bar on top and only sees the buttons he searches for. The super tool approach (Code Mode, OpenClaw) means some of the buttons are not buttons but programming editors. This is arguably harder to work with, but since our interns are pretty good coders these days, it gives them a lot of freedom.

In any case, we believe that to get the best out of our intern, we should take the time to design a nice interface for him, where he can click through, buttons appear next to the content that he can click, and forms with inline descriptions appear that the intern can fill with data and then submit. This way we can bridge the brittle tension between capability and alignment.

With all the things that agents have to handle at once, like finding the right command, keeping safety guidelines in mind, remembering the user’s intent and what is acceptable to do in its pursuit, it becomes clear that confusion and ambiguity are a real problem agents deal with daily. This is how catastrophic failures happen: an agent tries to clean up the test database it just created, but it picked up the wrong token and deletes the real database instead. And when cornered, agents have been observed to actively hide their mistakes. In July 2025, a Replit AI agent wiped a SaaStr founder’s production database during a code freeze and then fabricated thousands of fake records to cover it up. Anthropic has documented this kind of behavior more systematically under the label agentic misalignment.

So why did we write this article, and what is our opinion?

We have been knee-deep in the principal question of how to build an effective AI-automated landscape without losing control and alignment since day one of Franke und Schwarz. So we started to build a good environment for our interns, which we call Daedalus. This software powers our own infrastructure, and we have been tirelessly developing new features as needs arise, including but not limited to:

Monitoring: maintaining an audit trail with clear visibility into the system
Secrets management: never expose any secret, key, or password to any agent or chatbot
Accounts & permissions: scoping access becomes vital when running autonomous agents
Process definitions: with a powerful system, we need a structured idea of what needs to be done when
File system: agents can read common file formats and move files between external software
Database: agents can persist data and run structured queries against it
REST API: our platform exposes a full-featured API for integration
Schedule & events: external triggers and schedules can initiate any process
Automation: full agentic workflows with audit trails

We started with a simple tool to integrate software, but it turns out we have shifted to a platform that supports modern agentic workflows. That being said, our goal is not to be a single tool that does everything; it is a Swiss army knife for integration, with eyes on governance. We believe these are the two prerequisites for well-working AI in business: integration is the basis for functionality, and governance (who is allowed to do what, and when) is the fundament of alignment, ensuring that agents actually do what they are supposed to do.

You can take a closer look at our software. If you want to try it out, get in touch.