Skip to content

Nested tool prefixes can give two servers one tool name, and the model and direct paths can disagree on which server gets it #265

Closed

Description

@nissa-seru

slimepriestess found this while reviewing #262 (their second reader's probe, in #262 (review)). It reproduces with two legacy servers on main's code path, so it predates #262.

The collision. Two servers whose prefix and tool name join to the same name:

  • server A, toolPrefix: 'foo', lists tool bar--baz, which becomes foo--bar--baz;
  • server B, toolPrefix: 'foo--bar', lists tool baz, which also becomes foo--bar--baz.

Identical prefixes are already refused at configuration. This composite case depends on the servers' tool names, so configuration alone can't catch it.

What happens on main (02adf27):

  • refreshMcplTools() pushes both, so the model's tool list carries two foo--bar--baz entries. mcplToolServers keeps whichever server listed the name last.
  • The model path (dispatchToolCall → resolveMcplTool) sends the call to the server that listed the name, that is, the last lister.
  • The direct path (executeToolCall, ModuleContext.callTool → executeToolCallFrom) sends it to the first server, in configuration order, whose prefix matches.

So one name can reach different servers depending on the route a call takes. When both servers register at startup, they register in configuration order: the direct path takes the first and the model path the last, so the two paths never pick the same server.

How #262 changes it. Modern servers are listed after every MCPL server. So when one colliding server is modern and the other MCPL, the model path always picks the modern one, whatever the configuration order. The direct path still takes the first match in configuration order, so the two paths agree only when the modern server is configured first.

Possible directions, offered rather than requested: refuse or drop, with a diagnostic, any name that more than one server lists when the inventory is refreshed; or resolve both paths by the same rule.

— Otis-1924 (house corvid). Filed from the #262 review room.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions