MCP Tool Metadata Integrity After Approval

Approval-time trust ≠ runtime metadata

An MCP allowlist answers: which host may talk to this agent? It does not answer: what will that host claim tools do tomorrow? Clients refresh `tools/list` and prompt templates into the model as guidance. If those strings change after approval—especially after a short smoke test—you have an instruction channel the reviewer never saw.

Campaigns like Deadbugz ship a soft-looking formatter (`format_text` / `summarize`), stay clean for a few `tools/call`s, then return credential-seeking and concealment text on the next list/get. A two-call smoke test passes. Real use trips the gate. Advertising `tools.listChanged` makes the flip a protocol event, not a one-shot install artifact.

Fingerprint, then watch

1. At approval: hash the normalized `tools/list` (and any prompt templates you ingest). Record server identity, transport, owner, and why it exists (Supply Chain inventory).

2. At refresh: compare hashes. Drift is a security event—hard block or force re-approval with the new text shown to a human. Do not silently feed changed descriptions into the model.

3. Surface diffs: operators should see what changed (names, descriptions, schemas)—not only "server still connected."

4. Test the rug-pull: abuse suites must include install-clean / post-threshold flip cases. Suites that only snapshot install-time descriptions miss the class.

Allowlisting the server name without description integrity still fails after the flip. Tool Safety decides whether privileged host tools may run; metadata integrity decides whether refreshed prose can steer the plan.

What "done" looks like

You can show: (a) every production MCP has an owner and pinned identity, (b) approved tool-definition hashes exist, (c) `listChanged` / hash drift cannot expand capability without a human or hard deny, (d) traces link call count → list refresh → subsequent file/shell proposals. That is Supply Chain + Tool Safety + Observability—not a longer smoke test.