MCP server security in 2026: what to do before you publish

The MCP ecosystem grew from roughly 300 public servers in January 2026 to over 4,000 by April. A significant share of those servers were built by developers who followed the official quickstart, got the tool calls working, and published without a security pass. That is the normal trajectory for any rapidly growing ecosystem. The gap it creates is also normal: most MCP servers in the wild have not been audited for prompt injection, tool description poisoning, or credential exposure — the three attack patterns that matter most when a language model is the client.

This post covers the four threat categories specific to MCP servers and the 8 concrete checks you should run before your server touches a public npm registry, a Smithery listing, or a GitHub organization with other contributors. It is not a comprehensive security guide; it is the pre-publication checklist we use on every server we review.

The four threat categories that matter for MCP

Standard web security concerns (SQL injection, XSS, CSRF) still apply if your MCP server fronts a database or HTTP service. But MCP introduces four additional threat categories that standard security guidance does not address, because the threat model is different: the client is a language model, not a browser.

Why tool description poisoning is the one most developers miss

When a model client like Claude Code initializes an MCP session, it reads the server's tool list — names, descriptions, and input schemas — before the user sends any message. Those descriptions are part of the model's context for the entire session. They influence how the model interprets requests and decides which tools to call.

The attack is straightforward: if an attacker can modify a tool's description field — either by compromising the server code, injecting a malicious upstream dependency, or poisoning a tool registry listing — they can steer model behavior for anyone who installs the server. The technique was publicly documented in the Invariant Labs research from March 2026 and has since appeared in at least two disclosed npm package incidents.

The defense is equally straightforward but requires deliberate implementation. The key insight is that tool descriptions should be treated as user-visible copy, not internal developer notes. That means they belong in version-controlled static strings, not dynamic values, and they should be reviewed with the same care as any security-sensitive configuration.

What a poisoned tool description looks like

The model reads both descriptions before the conversation starts. The injected instruction is now part of its context for the session. Whether it acts on it depends on the model version and the user's system prompt, but the attack surface is real.

The 8-point pre-publication checklist

Run these checks before your server appears in any public listing or is installed by anyone outside your own machine.

The prompt injection problem in depth

Prompt injection through content is different from tool description poisoning in one key way: you cannot fully eliminate it. If your server reads external content — files, database rows, HTTP responses, git history — and returns that content to the model, you have a prompt injection surface. The content was written by someone else, and that someone else may have included instructions.

The practical mitigations are not perfect but they meaningfully reduce risk:

Structural separation

When your tool returns external content to the model, wrap it in a structural delimiter that signals "this is untrusted data, not instructions." Some teams use XML-style wrapping: <external-content>...</external-content> in the tool description, combined with a system prompt instruction that content inside those tags is never to be interpreted as a directive. This does not eliminate the risk, but it shifts the model's prior.

Return content type flagging

If your tool knows whether it is returning structured data vs. free-form text, flag it. A tool that returns a JSON object has a lower injection surface than one returning markdown. Where possible, return structured data and let the calling agent decide how to present it, rather than returning pre-formatted text that the model ingests directly as instructions.

Scope what the model can do after reading content

This is a client-side concern, not a server-side one, but it belongs in your server's documentation. A server that reads files should note in its README which other tools in a typical session could act on that content. If your file-reader server is commonly paired with a bash-execution tool, document that combination explicitly so users understand the end-to-end risk surface they are accepting.

What changes when you publish to a registry

Publishing to npm, Smithery, or any package registry changes the threat model in one important way: you are no longer the only party whose machines run your code. The checks above apply to your own development setup. Once your server is published, you are responsible for the security posture of every installation.

The practical implication is that checks 01 and 02 — static tool descriptions and pinned dependencies — need to hold across every future release, not just at initial publish. A server that ships secure at 1.0.0 and then adds a dynamic tool description in 1.2.0 due to a feature request has silently regressed. Build the static-description and pinned-dependency requirements into your release process, not just your initial checklist.

The other implication is that your changelog matters. When you fix a security issue, publish a clear entry. Your users need to know when to update; they cannot assess that from a diff of your source code on every release.

What's next

If you are building multi-agent systems where MCP servers feed data into Claude Code subagents, the interaction between MCP injection surfaces and subagent patterns compounds the risk. A prompt injection in a file system tool can redirect a subagent mid-task. The Septim Agents Pack includes a PreToolUse hook that validates MCP tool call inputs before execution and logs all MCP responses for later review — both the input validation and the response logging are the two practical controls that make multi-agent + MCP combinations auditable rather than opaque.

The broader Claude Code production audit checklist covers MCP exposure as section 5 of a 30-point review. If you are building both a custom MCP server and a Claude Code workflow that uses it, the two checklists together give you the full picture.