Capability Attestation and Tool Poisoning: Trusting What a Server Claims

You have a lockfile for your npm dependencies and nothing equivalent for the tool definitions an MCP server sends you on every single connection.

The claim nobody verifies

When a client connects to an MCP server, the server declares what it does. It sends a list of tools, each with a name, a description and a schema. The client accepts that declaration and presents it to the model.

There is no mechanism in the protocol for verifying that the declaration is accurate. Security analysis of the specification identifies this as one of three protocol-level weaknesses, and the phrase used for the missing piece is capability attestation — the absent ability to check that a server's stated capabilities match its actual behaviour.

A server declaring a read-only lookup may write. A server declaring it touches one resource may touch several. The declaration is a claim, and the protocol treats claims as facts.

Tool poisoning: the declaration can change

Worse than an inaccurate declaration is one that changes after you approved it. Tool poisoning — documented in the threat-modelling literature — describes a server that presents benign tool definitions during initial review and different ones later.

The asymmetry is the problem. Review happens once, at install, when the server is on best behaviour. The definitions are fetched fresh on every connection thereafter, and nobody looks at them again.

This is not exotic. It is the ordinary supply-chain pattern — the same shape as a package that behaves for six versions and ships something else in the seventh — applied to a channel with no integrity checking and no lockfile.

Pinning definitions yourself

Since the protocol does not provide integrity checking, the practical mitigation is to build a crude version. Record a hash of each server's tool definitions when you approve it, and check on subsequent connections.

import hashlib, json, pathlib, sys

PINS = pathlib.Path("mcp-tool-pins.json")

def fingerprint(tools):
    # stable hash over name + description + schema of every tool
    norm = sorted(
        (t["name"], t.get("description", ""),
         json.dumps(t.get("inputSchema", {}), sort_keys=True))
        for t in tools
    )
    return hashlib.sha256(
        json.dumps(norm, sort_keys=True).encode()
    ).hexdigest()[:16]

def check(server_name, tools):
    pins = json.loads(PINS.read_text()) if PINS.exists() else {}
    current = fingerprint(tools)
    known = pins.get(server_name)

    if known is None:
        print(f"NEW server {server_name}: {current}")
        print("Review the tool descriptions, then re-run with --accept")
        return False
    if known != current:
        print(f"CHANGED {server_name}: pinned {known}, now {current}")
        print("Tool definitions changed since approval. Review before use.")
        return False
    return True

Simple, and it converts a silent change into a visible one. That is the whole objective: you cannot prevent a server from changing its definitions, but you can refuse to let it happen without anyone noticing.

Reviewing a server before you trust it

Since attestation is unavailable, review substitutes for it. Six questions, in rough order of how much they tell you.

The fifth is the fastest signal and takes thirty seconds. Dump the tool list and read the descriptions as a person. A description is meant to tell a model what the tool does. Anything that instructs it to do something else first, or references files and systems unrelated to the tool's purpose, is worth stopping on.

Run the server where it can do least

Reviewing a server tells you what it appeared to do at review time. Since you cannot rely on that holding, the durable control is limiting what it can reach.

• Filesystem — a server that formats JSON needs no filesystem access at all. Run it with none, rather than with your home directory.
• Network — a server that queries one API needs egress to one host. Default-deny outbound is the single most effective containment for data exfiltration.
• Credentials — scope tokens to exactly what the server's stated function requires. A read-only server gets a read-only token.
• Process isolation — a container is not a strong boundary against a determined attacker and is a very effective one against a compromised utility server. Use it.

The registry problem

With more than 18,000 servers listed on public directories by early 2026, most teams find servers by search rather than by referral. That is a meaningful change in how the trust decision gets made, and not for the better.

A package on a mainstream language registry carries some ambient signal: download counts accumulated over years, dependents you can inspect, a maintainer with history, security scanning by the registry itself. MCP directories are younger and thinner. A server listed there may have been published last week by an account created the week before.

Two habits help, and neither is sophisticated. Prefer servers published by the organisation whose service they wrap — an official server for a SaaS product is a different proposition from a third-party wrapper of the same API, because the vendor has a reputation at stake and you already have a relationship with them. And prefer servers you can read. Most MCP servers are small. Skimming a few hundred lines before granting a process access to your filesystem is a reasonable hour.

The realistic posture

Treat every MCP server as untrusted code running with the access you grant it, because that is what it is. The lightweight install experience — a few lines in a config file — badly understates the trust decision, and the mismatch between how easy installation feels and how consequential it is accounts for a good deal of the exposure in the wild.

Practically: keep the connected set small, pin the definitions, scope the credentials, isolate the process, and re-review anything that changes. None of that is novel security thinking. It is ordinary supply-chain discipline applied to a dependency type most teams have not yet recognised as one.