Tool drift after approval

Last 7 days

2026-11-06T11:43:22Z to 2026-11-13T11:43:22Z. Recomputed every 10 minutes. JSON: GET /v1/tool-drift.

Servers with a recorded tool set

24,967

Servers that changed their tools

5,284 (8,674 changes)

Changes that kept every tool name and redefined tools

6,046 (70% of changes, 4,264 servers). Approval by tool name does not see these.

Changes that added tools / removed tools

2,504 / 693

Tools that gained authority under the same name

188 (lost readOnlyHint, or became destructiveHint or openWorldHint)

Servers that redefined the same tools at two or more reads

377. A client that asks again on every change would ask again on each of these reads.

Changes under the same serverInfo name and version

6,656 of 7,848 (version changed in 1,192), counted since 2026-11-07T21:36:43Z

Servers whose tool text matches prompt-injection heuristics now

220

initialize instructions

4,212 of 18,304 servers that send instructions changed the text (tracked since 2026-11-07T22:06:59Z). No notification covers this change.

Why it matters

• Re-approval. A changed definition is a different tool for the model, whatever its name, list_changed notification, version or signature says. A host that pins names, or waits for list_changed, misses redefinitions.
• Versions. If servers change tools under the same serverInfo.version, a client cannot tell a release from a silent swap by the version.
• Split view. A server, or anything holding its keys, can serve different definitions to different clients. Each client sees a valid, consistent set and has nothing to compare it with. Certificate Transparency solved the same problem for TLS certificates with public append-only logs. This history is such a log for tools/list.

Check the tool set you got

Send the tools array your client received: POST https://alalanet.com/v1/tool-digest {"url": "…", "tools": […]}, or call the MCP tool verify_tools on https://alalanet.com/mcp. The answer is one of:

• matches_current;
• served_before, with first and last seen, a diff from the current set and a link to the signed log entry of the change;
• never_served. If your set differs from the last read, tools/list is read again before the answer, so never_served means the server is serving alalanet something else at that moment.

Free, no account. History per server: GET /v1/services/{id}/tools.

Method

Every remote MCP server listed in the public registries that answers without auth has its tools/list read about once a day. A change is a new tool-set digest (name, title, annotations.title, description, inputSchema, outputSchema and annotation hints per tool, schemas re-encoded with sorted keys), signed into the public log (kind 4305) with both digests and the tools added, removed or changed. redefined_only: no tool added or removed, at least one existing tool changed. gained_authority: a tool kept its name and lost readOnlyHint or gained destructiveHint or openWorldHint. server_version compares the serverInfo name and version at the last read of the old set with the first read of the new one, only for changes whose old set was read after counted_since; same_version means the server changed its tools without changing serverInfo. instructions: servers whose initialize instructions text changed within the window. Figures are recomputed every 10 minutes; every change links to its signed entry in the feed.

Every change: /v1/feed?type=tools_changed, each entry signed and appended to the public transparency log (C2SP tlog). Every digest held, first reads included, once a day: /v1/tool-digests (a file whose sha256 is signed, kind 4313).

Discussed as the MCP Security Interest Group agenda item “Runtime drift: list_changed semantics after approval” (charter).