Before and after manifests
Showing the shipped fixture. Replace either side with your own capture, then compare.
Drift record
—
Paste two manifests, or load the fixture, to see a record.
FOR AGENT TEAMS AND MCP INTEGRATORS
Paste two locally captured MCP tool manifests. This page lists added or
removed tools, inputSchema changes, and description
changes — including a separate flag when a changed description newly
reads like an instruction aimed at the calling model rather than a
human reviewer. It does not contact any server; everything runs here,
and nothing is uploaded.
Need this in CI? The same comparison ships as a standard-library-only Python CLI in this tool's repository — see the README.
Showing the shipped fixture. Replace either side with your own capture, then compare.
Paste two manifests, or load the fixture, to see a record.
An agent team approves an MCP server's tools once, then keeps calling it. The useful question later is which tool descriptions and input schemas actually changed since that approval — this record answers that from two captures you already made. It does not connect to the server and does not decide whether a change is safe.
A changed description that newly contains model-directed language (phrasing like "ignore previous instructions" or "send the result to") is reported as its own instruction-bearing bucket, separate from an ordinary wording change — this is the shape of a tool-poisoning or rug-pull attempt, where a server waits until after approval to add instructions aimed at the calling model.
Each capture is JSON you control. Required: tools, a list
where every entry has a unique string name. Optional but
compared when present: description and
inputSchema. Optional top-level fields
server and captured are carried into the
report but not compared themselves.
{
"server": "inventory-mcp",
"captured": "2026-08-20T09:00:00Z",
"tools": [
{
"name": "search_inventory",
"description": "Search available inventory",
"inputSchema": { "type": "object", "properties": { "query": { "type": "string" } } }
}
]
}
Capture a server's tool manifest (its declared name, description, and input schema for every tool) at approval time, and again later. Paste the earlier capture as Before and the later one as After. The page lists which tools were added, removed, or changed, without contacting the server itself.
No. Comparison runs entirely in your browser from the two JSON manifests you paste or load from a file. There are no accounts, no server connections, and no upload.
It is when a connected MCP server changes a tool's description or schema after an agent team has already approved it, adding text meant to influence the calling model rather than the human reviewer — for example instructions to exfiltrate data or ignore prior guidance. This page flags a changed description that newly contains model-directed language as its own severity bucket, separate from an ordinary wording change.
A field like an annotation or version tag can change without the description text or input schema changing at all. Reporting it as its own category keeps the more sensitive description and schema signals from being diluted by routine metadata churn.
Alert severity is reserved for a removed tool and for a description change that newly reads like an instruction aimed at the calling model. A newly added tool, a changed input schema on an existing tool, and an ordinary description change are all listed at review severity instead — one level down, because they are still worth a look but are not on their own evidence of tampering.
A changed description is flagged instruction-bearing when the new text contains language such as "ignore," "disregard," "override," "system message," "you must," "do not tell," "send ... to," or "reveal," and the earlier description did not already contain that same wording. Requiring the wording to be new, not just present, keeps a tool whose description always mentioned one of those words from being flagged every time something unrelated about it changes.
Every tool name present in the After manifest but missing from the Before manifest is listed as added, at review severity. Every name present in Before but missing from After is listed as removed, at alert severity — the same severity as an instruction-bearing description change, because a tool quietly disappearing deserves the same scrutiny as one that quietly changed.
What is an MCP tool poisoning attack, and how would I catch one?
Also paying to run the agent doing that watching? See whether your AI coding plan is actually cheaper than the API.
Checking a server's launch config instead of diffing two manifests over time? MCP Config Risk Check audits a single mcp.json for broad access, hardcoded secrets, and missing version pins.