The Catalog Never Had It. A Different Server's Tool Ran.

Two claims sit next to each other in GitHub issue zai-org/feedback#551, and the interesting part is that they are not the same claim, even though a session log that only checked the first would look identical to one where the second had also silently failed. The first claim is that an MCP server connected. The second is that the session the agent was actually running in could see that server's tools. The issue reports a case where the first was true and the second, for roughly four and a half minutes and across six model requests, was not, and where a subsequent call meant for the missing server executed as a tool belonging to a different server instead, with nothing in the session surfacing an error.

What the issue itself reports

The report, filed 6 September 2026 against ZCode CLI, a coding agent product built by Z.ai on its GLM model family, describes an environment of ZCode CLI 0.16.5 on Windows 11, using the builtin zai-coding-plan provider against GLM-5.3-Flash through an Anthropic compatible endpoint, with several MCP servers configured including serena, v8-pulsar, rlm, computer-use, node_repl and image_search. For one session, identified in the report as sess_bdacc918, the reporter's own account states that a host log entry recorded mcp.server.connected for serena with toolCount 23, and that six subsequent requests sent to the model over roughly four and a half minutes each carried a tool inventory of 127 entries containing zero tools prefixed mcp__serena__. The reporter's own account states that the agent, at one point in that window, narrated an intent to call mcp__serena__initial_instructions, and that the call the session's own record shows as having executed instead was mcp__v8-pulsar__list_sessions, a tool belonging to a different server the same session had already connected. A second session is reported to show the identical shape, substituting mcp__computer-use__list_apps for the same missing serena tool, and the reporter's own total across both sessions is three wrong tool executions inside one hour. The report states plainly that no explicit unknown tool or similar failure was observed at any point, and that starting an entirely new session produces a tool catalog containing serena's own 23 tools, with the originally intended tool then working normally.

What Moona Intelligence independently checked

This record fetched the issue directly and confirmed it is open, carries the label priority P2, was opened by a reporter identified as Serg2000Mr, and as of this record's own verification carries no maintainer reply and no linked pull request, commit or release. A search of the same repository's issues for related terms, tool catalog, wrong tool and MCP, returned no duplicate report of the same mechanism; the nearest neighbors by topic are separate reports about MCP reconnection after a Windows crash, plugin environment variable interpolation, and a settings display bug, none describing a tool catalog omission or a cross server substitution. This record also confirmed, from Z.ai's own public GitHub organization, that ZCode CLI's own source is not published there, so the specific claim at the center of the report, that a call to one tool executed as a different one, could not be independently reproduced against the actual product in this session. What follows is accordingly bounded to what the reporter's own account establishes and what a general mechanism of this shape would require to be true, not to a confirmed root cause inside ZCode CLI itself.

Connected is not the same fact as available

Read narrowly, the report's own sequence separates two facts that a system reporting only the first can make indistinguishable from a system where the second also holds. A host level connection event, mcp.server.connected with a toolCount, is a fact about the server and the transport: a process started, or a remote endpoint answered, and enumerated some number of tools to whatever component logs that event. Whether the session actively running at that moment, the one whose next model request is already being assembled, has that server's tools inside the specific tool inventory it sends is a separate fact, about a catalog generation the session is currently using, and the report's own timeline, a successful connection log followed by six requests over several minutes carrying none of the newly connected server's tools, is exactly the shape a system would produce if the connection event and the session's own live catalog were populated by two different processes that do not synchronize atomically. Neither this record nor the issue itself establishes that this is what ZCode CLI actually does internally; it is the general shape the reported timeline is consistent with, stated as a shape rather than a confirmed mechanism.

The second half of the report describes a different and, on its own, more consequential gap. A tool name absent from the catalog the model was shown is not, on the reporter's own account, met with an explicit failure when the model calls it anyway; the report states a different, already registered tool executed in its place, in three instances across two sessions, always a read only enumeration call in the examples the issue itself names. Whatever component actually produced that outcome, whichever of a model's own token choice, a provider adapter, a tool name normalization step or a dispatcher's own fallback the issue's unavailable raw logs might have shown, the outcome the report describes is one where an unresolved name reached execution as a different, valid tool rather than reaching an explicit and visible unknown tool state. A system that fails open this way is harder to notice than one that fails loudly: nothing in the report describes an error a user would see, only, on the reporter's own account, a call that appears to have succeeded under the wrong name.

Where this sits in the pattern

This record's own comparison against Moona Intelligence's existing corpus found no prior entry addressing this specific mechanism, an unresolved tool name reaching execution as a different, already registered tool, though several existing records sit nearby without being the same shape. IBM ContextForge's own stored jq filter showed a tool's declared boundary failing once a second caller invoked it, but the tool invoked there was the one the caller actually named; the gap was inside that tool's own stored behavior, not in which tool the dispatcher reached. git-mcp-server's own argument injection showed a declared effect class failing to survive the executor's own grammar, again for the tool the caller actually named. A GitHub MCP backend left registered for a narrowly delegated identity and reachable by the primary agent that delegated it is the closest existing shape, a registration meant for one purpose becoming routable for another, but that gap crosses two principals sharing one gateway's own registration set, not a name resolution step substituting one tool for another after the intended one could not be found. None of these records, nor any other in this corpus, states that a missing or unresolved tool name reaching execution as a different tool is itself an evidenced, examined mechanism, which is the specific and narrower claim this report, on the reporter's own account alone so far, would add if independently confirmed.

What this record does not establish

This record does not establish which layer of ZCode CLI's own pipeline, model output, provider adapter, tool index normalization, alias mapping or dispatcher, actually produced the substitution the issue describes, because the raw host log and model I/O files the issue itself names were not attached to the public report and were not independently obtained. It does not establish that any maintainer has acknowledged, confirmed or begun to fix the report, that the mechanism reproduces with a provider or model other than the one the report names, that it reproduces in any product other than ZCode CLI, or that any mutating or destructive tool has ever been substituted this way; every wrong tool execution the report itself names is a read only listing call. It does not establish that a successful tool result in either of the reporter's own examples corresponds to the intended tool having run, since the report's own account is that a different tool executed and apparently returned a usable result under the wrong name. It does not establish that this represents a security vulnerability distinct from a correctness defect, and it does not claim exploitation by any party, since the substitution the report describes appears in its own account to be an artifact of the tool resolution pipeline itself rather than an input any party supplied. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the general shape the report is consistent with.