An MCP Server Is a Supply-Chain Dependency With Reach Into Your Data

An MCP server is not a feature. Written by someone you have probably never met, it runs with whatever credentials you handed it and decides, in real time, what a language model reads and does next. Because the Model Context Protocol only standardizes the wire format between a model’s client and a tool, it does not audit the tool, and it does not promise the tool’s own description of itself is honest. Most explainers stop at the code sample. This one goes further: what MCP actually is, what running a server really exposes, and the hygiene rules that survive contact with real production use.

Recomputed from Snowflake’s own launch post: 9 of the 12 explicitly tagged MCP-governance capabilities ship in private preview; only 2 are GA today.¹

What is MCP, in plain terms?

The Model Context Protocol (MCP) is a JSON-RPC 2.0 wire format that lets an AI application, called a host, connect to servers that expose data and actions, called tools, resources, and prompts.² A host runs a client for each server it connects to. Before any real work happens, client and server negotiate which capabilities they support. Two transports carry that traffic.

Under stdio, the host launches the server as a subprocess and talks to it over standard input and output; under Streamable HTTP, each message is a POST to an endpoint.⁵ None of that says anything about whether the server is safe to run. It is a shipping format, not a trust guarantee.

What does an MCP server actually have access to?

An MCP server runs with the credentials you configured for it, and on the most common local transport, stdio, that is the whole story. Because the spec explicitly tells stdio implementations to skip MCP’s OAuth-based authorization framework, they retrieve credentials from the environment instead.³

So a database password, an API key, or a write-capable token sitting in an environment variable is available to every tool call that server makes, for as long as the process runs. There is no protocol concept of doling out that credential one call at a time. You scope it once, at setup. Narrowing it further is not something MCP does for you.

Why do tool descriptions count as an attack surface?

Before a model ever calls a tool, it reads that tool’s name and description as plain text, which makes the text itself a place to hide instructions. The current specification says so directly: clients must treat tool annotations as untrusted unless they come from a server the client already trusts, because a server, or anything sitting between server and client, can write whatever description it wants.⁴

OWASP’s prompt-injection entry names this pattern indirect injection: content the model reads from an external source, not typed by the user, that changes what the model does.⁶ Read back a search result, a fetched web page, or a file, and a tool’s returned content can steer the model exactly as effectively as its description did.

Does the protocol let you scope a server’s permissions finely?

Yes, in pieces. For HTTP-based servers, the spec’s authorization framework supports OAuth 2.1 scopes and incremental step-up requests,³ and Claude Code’s own implementation lets a server author flag one specific tool as requiring a human’s confirmation on every call.⁸ But authorization is optional in the spec to begin with.

Stdio servers are told to skip that framework entirely, and the per-tool approval flag is something a server author chooses to set, not something a client can force onto a server that omits it. From the practitioner’s side, Anthropic’s own Claude Code documentation reaches the same conclusion: its worked example for connecting a database server is to hand it a read-only database user in the connection string, not to lean on the protocol to hold the line.⁸ That durable boundary is still the credential, not the negotiation.

Is Snowflake’s new MCP gateway proof that this is a solved problem?

No. It is a product launch, timed to a security conference, and most of what it announced ships as private preview rather than production-ready.¹ Snowflake’s Cortex AI Gateway centralizes identity, policy, and audit logging for MCP tool calls across a company’s agents, which is a reasonable architecture on paper.

Across the 12 capabilities the post itself tags private preview, GA, or GA soon, 9 carry the private-preview label and only 2 are GA today. A launch like this signals that enterprise security reviews now expect an answer for MCP governance; it is not evidence that the answer is deployed anywhere at scale yet. My read: the checkbox exists before the shipped, load-bearing control does.

What does the research say about defending against prompt injection?

Currently, no defense fully closes the gap. Given how models actually process text, OWASP says plainly that it is unclear whether a fool-proof prevention method exists at all.⁶ The mitigations that do help are reductions, not guarantees: constrain what the model is told it may do, validate outputs before acting on them, keep untrusted content clearly segregated from instructions, and require a human to approve anything high-impact.⁶

Underneath most of the damage sits one mechanism, and OWASP’s companion entry on excessive agency names it: a tool with more functionality, more permission, or more autonomy than the task in front of it actually needed.⁷ That is a design failure you can audit for, even on the days the injection itself cannot be fully stopped.

Why is a security scanner with partial coverage more dangerous than no scanner at all?

A scanner that inspects some of an agent’s inputs and not others still produces a clean log, and a clean log reads as safety whether or not it earned that reading. This is a general property of layered controls, not a quirk of any one setup. At minimum, an absent control leaves you cautious. A partial one manufactures confidence nobody earned.

I run MCP servers alongside a scanning layer over my own agent pipelines, and that setup produced the specific, reportable version of that gap: a scanner wired to catch injected instructions on one call path can leave a second, equally live path unscanned, and the two paths look identical from the log alone. Treat “scanned” as a claim you verify path by path, not a property bundled with having installed a scanner.

What hygiene rules actually hold up for a solo practitioner running these day to day?

Five rules survive contact with real use, and none of them require an enterprise gateway. Read what a server does before installing it. Scope the credential you hand it as narrowly as the vendor allows, and separate read-only servers from write-capable ones in your own setup. Treat everything a tool returns, not only its description, as untrusted text. Re-list what is installed on a schedule, since forgotten servers keep holding the credentials they were given.

• Read before you install. A server pulled from a registry is unaudited by default. A name and a star count are not a security review.
• Scope the credential, not the client. A read-only database user, a token limited to one repository, an API key with the narrowest role the vendor offers.
• Separate read from write. Keep read-only servers and write-capable ones apart in your own head, and in configuration wherever the platform allows it, so a compromised read path cannot quietly become a write path.
• Treat every tool result as untrusted text. Not only the description: content a tool hands back to the model is never an instruction to obey.
• Re-list what is installed, on a schedule. Unused servers accumulate quietly, and each one keeps holding its credential.

How do you audit your own MCP setup right now?

Run an enumeration, not a vibe check. In Claude Code, claude mcp list shows every configured server with a live connection status next to it, and claude mcp get <name> shows exactly how each one was added, including the environment variables and connection strings it was given.⁸ Other MCP hosts expose an equivalent settings or connector view, and although the mechanism differs by platform, the audit itself does not change.

For each server, answer three questions in writing: what credential does it hold, could that credential write or delete anything, and would you recognize its tool names if you saw them fire mid-session. Any server where you cannot answer all three from memory is the one to check first. Those are the servers running on trust you extended once and then forgot you had extended.

MCP is an ordinary dependency wearing an extraordinary-sounding name: the same credentials, the same unaudited code, the same blast radius as any third-party library with write access to your data. In most explainer content, “it standardizes tool calls” reads as the whole story. What that content skips is the trust question, and it is answerable with a list, a credential audit, and about ten minutes.