Keep unusable tools out of an assistant’s choices
An assistant should discover actions it can meaningfully attempt. Wildo filters exposed operations through the resource, route, implementation and server-membership rules before advertising a tool.
The same eligibility is checked again when a caller invokes a tool by name.
Example — Retire an action without leaving a hidden route
An operation acknowledged as unimplemented disappears from discovery and cannot still be invoked by a client that remembers its old tool name.
For engineers
mcp.exposed opts an operation in. Eligibility also depends on a reachable resource scope, a default URL-bearing operation, a usable tool name, no unimplemented acknowledgement, and membership in the addressed server.
This selected implementation excerpt shows the invocation-side conditions after resolving the resource and checking the composed name:
return config.operations.find(
(operation) =>
String(operation.operationIdentifier) === operationIdentifier
&& isDefaultUrlBearingOperation(operation, String(operation.operationIdentifier))
&& this.isMcpExposed(operation)
&& !this.isAcknowledgedUnimplemented(operation)
&& this.isOnMcpServerInstance(operation, instanceRef),
);
Check discovery and invocation together
When changing an operation’s exposure or implementation acknowledgement, verify both tools/list and a direct tools/call using its previous name. Absence from the catalogue alone does not prove that invocation was withdrawn.
The adapter also checks the composed resource/operation tool name against its accepted naming grammar. A malformed name is omitted rather than making every other tool unusable to a strict client. These eligibility checks concern whether the tool can be offered; the caller’s roles are still checked when executing it.