An unresolved tool identity is silently rebound to a registered capability
A tool call whose name does not match anything in the acting session's own current tool catalog is not met with an explicit unknown tool failure. Instead a different tool, one already registered in that same session, executes in its place, and the result returned gives no signal that the identity actually dispatched differs from the identity named in the call.
Description
This weakness names a specific way a system holding more than one registered, callable capability can fail the narrower of two obligations a dispatcher has: not only routing a resolvable name to the correct capability, but also refusing to route an unresolvable one to any capability at all. A tool catalog, the set of names a session's own dispatcher currently recognizes as callable, can diverge from the full set of tools a system has registered overall, whether because a server connected after the catalog for the current session was already built, because a name was renamed, aliased or removed upstream, or because the catalog itself is stale for any other reason the acting session cannot see. When a call names a tool absent from that catalog, the only two outcomes consistent with tool identity remaining authority bearing context are an explicit unresolved or unknown tool state, or an atomic refresh that genuinely adds the missing tool before the call proceeds. A third outcome, the call reaching execution against some other, already registered tool the dispatcher happened to be holding, is not a resolution of the caller's own request; it is a different request being served under the name of the one that was actually made, and nothing about the result returned to the caller distinguishes this from the intended tool having genuinely run. This differs from a stored program inheriting a gateway's own execution authority once a second caller invokes the same tool, this dataset's AEW-023: there, the tool actually dispatched is the exact tool the caller named, and the gap lives inside that tool's own stored behavior. It differs from a declared capability failing to survive an executor's own argument grammar, AEW-025: there too the tool dispatched is the tool named, and the gap is in how a value inside a correctly identified call is interpreted, not in which tool received the call. It differs from enforcement wired to one caller rather than the shared executor, AEW-028: that weakness describes a capability some callers reach ungated and others reach gated, through one shared function; here every call reaches some dispatch decision, and the gap is that an unresolvable name is not refused, it is silently redirected. It differs from an instruction naming a mutable referent that a different controlling principal comes to occupy, AEW-029: there the name itself keeps meaning the same thing to the system while the artifact behind it changes hands externally, over time, outside the system's own control; here the name is unresolvable inside the system's own current session state at the moment of the call, and the substitution happens instantly, inside the dispatcher itself, with no external party involved at all.
The authority gap
The authority required to execute a specific tool is authority over that exact, resolved tool identity, established through the acting session's own current catalog. The authority actually exercised, once a named tool is absent from that catalog, is authority over whatever different, already registered tool the dispatcher redirects the call to, a capability the caller's own request never named and that registration under a shared session does not, by itself, authorize the caller to reach under another tool's own identity.
Failure conditions
- A system holds more than one registered, callable tool or capability across one or more connected servers, and a session's own current tool catalog, the set of names its dispatcher currently recognizes as callable, can diverge from the full set of tools registered overall.
- A call names a tool absent from the acting session's own current catalog, whether because a server connected after the catalog was built, a name changed upstream, or the catalog is stale for any other reason.
- The dispatcher's own handling of an unresolvable name is not an explicit unresolved or unknown tool state and is not an atomic refresh adding the missing tool before the call proceeds, but a redirection of the call to some other, already registered tool the dispatcher was already holding.
- The result returned to the caller carries no signal distinguishing a call that reached the tool actually named from a call that reached a different, substituted tool, so a caller relying only on the result cannot tell the two apart.
Consequences shown by the evidence
- A caller's request for one specific, deliberately selected tool is served by a different tool instead, with the caller and any downstream system relying on the result having no signal that a substitution occurred.
- A human approval or review directed at a specific named tool call does not carry forward to whichever different tool the dispatcher actually reached, so the approval and the executed action are no longer the same decision even though nothing in the visible exchange shows that.
- A slower or later connecting server's own tools become practically unreachable for the remainder of a session once a caller has learned, from repeated silent substitution, that calling them does not reliably reach them.
Detection signals
- A host or session log records a successful mcp.server.connected event, or an equivalent registration event, for a server whose tools do not appear in the tool inventory sent to the model in requests occurring afterward within the same session.
- A model's own narrated intent to call a specific tool, visible in a transcript, does not match the tool name recorded as having actually executed, with no unknown tool or equivalent failure recorded between the two.
- Restarting or creating a new session resolves a tool catalog gap that a currently running session continued to show, indicating the gap was in session level catalog state rather than in the server's own registration.
Known examples
- GitHub issue zai-org/feedback#551, opened 6 September 2026 and, per this record's own direct fetch on 7 September 2026, still open, labeled priority P2, with no maintainer reply and no linked fix. The issue reports that ZCode CLI 0.16.5, running GLM-5.3-Flash through an Anthropic compatible endpoint, logged a successful mcp.server.connected event for an MCP server named serena with toolCount 23, that six subsequent model requests over roughly four and a half minutes each carried a 127 tool inventory containing none of serena's own tools, that the agent narrated an intent to call mcp__serena__initial_instructions, and that the call recorded as having executed instead was mcp__v8-pulsar__list_sessions, a tool belonging to a different, already connected server. A second session reportedly substituted mcp__computer-use__list_apps for the same missing tool, three wrong tool executions in one hour across both, with no explicit unknown tool failure observed at any point and a fresh session resolving the catalog correctly. This record's own search of the same repository found no duplicate report, and ZCode CLI's own source is not public, so the exact layer responsible for the substitution, model output, provider adapter, tool index normalization or dispatcher fallback, is not established by this record and remains unknown pending the raw host log and model I/O files the issue itself references but does not attach.