Dear Model, Don't Tell the User: What MCP Servers Whisper Into Your Agent's System Prompt

In my AI-first overview, I argued that before a team touches an AI tool, you settle what data can go where, decide which tools are approved and who decides when someone wants to add one, and test every tool before asking anyone to adopt it. I stand by all of that.

But those rules quietly assume you can see what you are approving. With MCP connectors, often you cannot.

This is a follow-up about the part of the stack that is easy to wave through: the servers your AI tools connect to. I use MCP servers with Claude, and I am not telling you to stop, I am asking you to treat every connector as a decision with consequences, and to start from caution rather than convenience.

Why MCP is worth the trouble

The Model Context Protocol is how an agent gets hands. It lets a model read your tickets, query your docs, search your repositories, and act in the systems where your work lives. That is a big part of why agents are useful beyond a chat box, and why the ecosystem has grown so quickly.

Nothing below is an argument against that. It is an argument that every one of those connections is also a party you are letting talk to your model, and I would guess that most of us have never read what the MCP servers are telling our agents to do.

The channel almost nobody reviews

When a client connects to an MCP server, the server answers an initialize request. That response can include an optional string called instructions. The schema's own comment describes it as guidance for the model, a hint, and says the text MAY be added to the system prompt.

Read that as a reviewer, not as someone who wants the feature to work. A remote party you connected moments ago supplies free text, and your client is invited to place it in the position a model is built to weight most heavily. The comment sets no length limit and does not require the client to show you the text. Fetchgate, whose audit I get to below, says it knows of no client UI that displays it. Concerned yet?

instructions is also only one door. Digital Applied's reading of the spec lists several routes by which server-written text reaches a model: the instructions field, tool descriptions, tool annotations, tool results, resource content, and prompt content. Its judgment is that tool results are the largest practical surface, because a fetched web page, a search result, or an issue body all arrive that way. So "I read the instructions field" is not the same as "I know what this server can put in front of my model."

There is also a cost. Whatever a server puts in context is carried on every turn of every conversation, whether or not you use that server that day. You pay for it in tokens, in latency, and in the model's finite attention. Fetchgate's longest instructions string runs 68,669 characters, which it puts at roughly 17,000 tokens before a single tool is called, and one tool description alone is over 52,000 characters. Datapace, citing The New Stack, prices each connected tool at roughly 550 to 1,400 tokens once its name, description, and schema are counted, and a server can expose dozens. Most servers are far smaller than those outliers, but you can't know what you connected to without measuring.

What the audits found, and what they cannot see

Two audits from late August 2026 give us a first look at this channel.

Fetchgate probed all 15,329 remote URLs in the official MCP registry, read-only, and read every tool description and instructions string that came back. Of the 8,235 servers that answered, 5,462 (66%) return an instructions string. Most are short, but 16 run past 20,000 characters, and the longest is 68,669 characters. Digital Applied took a different approach and read the documentation of 19 widely deployed servers. Only one documented a persistent instruction mechanism, none documented the spec's instructions field, and the three servers whose job is to fetch outside text (Fetch, Firecrawl, and Brave Search) contained no warning that returned content could contain instructions.

It is important to keep in mind, Fetchgate covers one registry, probed over one night. Fewer than half the URLs answered, servers behind authentication went unseen, and local and private servers weren't covered at all. The checks are pattern matches, and servers can change the day after a scan. Digital Applied's census looked at documentation only, so "undocumented" doesn't mean "absent." Fetchgate didn't find the classic exfiltration payload in what it could see, but that tells you about its sample and not about the thousands of other servers that are available but were not on the list they checked. The mechanism that carries all this ordinary text could carry anything and nothing checks it. 

So the takeaway isn't what the audits found. It's that almost nobody has read what their connected MCP servers say.

The case that shows the class is real

The vulnerability class isn't just theoretical. In August 2026, NVD published CVE-2026-75130, a prompt-injection flaw in Context7, a widely installed documentation server. Per the advisory as Digital Applied reports it, a "Custom AI Instructions" feature let unsanitized content reach connected coding agents during a routine documentation request. The impact included credentials read from environment files and destructive file deletion. 

Look at where the damage happened. Digital Applied points out that the Context7 server itself exposes two read-only tools and can't run code, write files, or make network requests on its own. The harm came from the agent on the other end, which can do all of those things, acting on text it assumed was trustworthy. The MCP server is the courier; your agent is the blast radius.

You cannot judge a server by its intent

Here is what Fetchgate did find. It's normal, and that's the problem.

Forty seven hosts include text telling the model what not to tell you. A memory tool instructs the model to capture things without asking and not to mention it, because it is "ambient." A payment tool tells the model not to say that a payment failed. Others tell the model not to name competitors, not to relay reference material, not to explain why an action was blocked.

Fetchgate's own read is balanced, and I agree with it. Some of this is harmless polish, like not leaking internal IDs. Some of it is a product decision you would want to know about before enabling the server. A couple of lines are the exact instruction a tool-poisoning paper would use as its example, sitting in a production server. Although Fetchgate did not see exfiltration in the limited example set it quoted, all of it is text you never see, addressed to your model, about what to conceal from you.

There is more of the same shape. Fetchgate counts 480 hosts using model-directed language such as "you must" or "always call." It counts 406 hosts shipping a tool that claims to run before every other tool. Precedence claims matter because they are how a tool from one server gets to run first and shape the inputs to a tool from another. 

So here is my point. "Appears benign" is an observation about today's text from the outside. It is not a standard you can operate on, because you cannot see all of the text, you cannot tell which lines are polish and which are policy, and you cannot know what the next release will say. The standard that works is the one from my earlier article: have I read it, and will I know if it changes?

A connector is also a capability grant

Every connector brings two things: text and capability. It is worth being clear-eyed about the second.

Tool annotations are a good example. They are the hints a server uses to describe itself, such as whether a tool is read-only or destructive. Fetchgate found 72% of tools carry them and 78,551 declare themselves read-only. But the spec's own comment says these are hints, not guarantees, and that clients should not base tool-use decisions on annotations from untrusted servers. A read-only label is the MCP server's claim about itself, delivered by the same channel that carries everything else. It is not a permission system.

Combining servers raises the stakes. Stripe's documentation, for instance, advises requiring human confirmation of tool calls and being careful when using its server alongside others. Each new connector adds access, text, and one more party whose behavior you are trusting, and they can interact with one another.

A cautious default

This is the part to turn into policy. If you lead a team, make it the team's rule. If you are setting up your own AI development system, the same questions apply, with you as the approver. The pattern is the one from my earlier article, applied to connectors: start from no, test before adopting, stage the rollout.

1. Start from no. A connector has to earn its place. What does it do that you can't do another way, and who runs it? Remove what you stop using.
2. Name who decides. On a team, one person or group approves new servers and keeps the approved list. Alone, that's you, and writing it down is still worth the minute.
3. Read before you enable. Capture the server's initialize response and tool list and read the instructions and every description. Fetchgate's free scanner will do this for a remote server, but treat it as a first pass, not a verdict, since it is pattern matching. For local servers, read the code and config.
4. Snapshot and diff. Keep that captured text in version control and diff it when the server updates, the way you would diff a lockfile. A dependency that quietly rewrote itself should alert someone. 
5. Set a budget. Count the tokens in a server's captured instructions and tool descriptions, set a ceiling, and flag anything over. Treat growth between versions as a reason to re-review. A vendor's verbosity should be their problem before it is your bill.
6. Search for directive language. Look for phrases like "do not tell the user," "do not mention," "before any other tool," and "you must." Treat a hit as a question to answer, not a conviction.
7. Shrink what the agent can reach. Since the agent's permissions define the damage, keep them narrow: require approval for shell and network actions, keep production secrets out of plaintext files the agent can read, and don't rely on a server's own read-only claim. Enforce it on your side.
8. Roll out in stages. One connector at a time, on low-risk work first, while the stakes are small enough to see what breaks.
9. Prefer clients that show you the text. I cannot tell you which ones do, and from what the audits say, many do not. Ask your client's vendor, and weigh the answer.
10. Re-review on a schedule and on change. A reviewed server is only reviewed as of the day you looked.

Where this leaves us

My earlier article ended on the idea that every step of an AI rollout is also a people question: how to talk honestly about change, how to make room to experiment, how to coach someone through it. This is the technical twin of that. Someone on your team decides what gets plugged in, and they need to know what they are approving.

MCP is a good idea, and I expect to keep using it. I just no longer treat "it's a popular server" or "it looked fine" as a reason to skip reading it. Be cautious, be a little pessimistic, and go read what your agent is being told.

Sources

• Transitioning to an AI-First Engineering Organization: A Practical Overview, Ben Lobaugh
• We Probed Every Remote Server in the Official MCP Registry, Fetchgate, Aug 28, 2026 (primary data, CC BY 4.0)
• MCP servers write into your system prompt. Nobody logs it., Maxime Dalessandro, Datapace (a vendor that sells a governed context layer and pitches it at the end of the post; used here for the dependency-hygiene recommendations)
• We Audited What MCP Servers Put in Your Agent's Context, Digital Applied, Aug 22, 2026
• An MCP Server Bug Scores 9.0. No Fix Is Documented, Digital Applied, Aug 18, 2026
• CVE-2026-75130, NVD
• MCP schema, 2025-06-18