The current SDK docs make an important boundary explicit: servers should list tools normally and filtering is the host's job. That matches a validation experiment I am running with SchemaRouter, a typed capability/field retrieval layer.
I would like to contribute only a client-side example/benchmark, not a protocol or server change:
- fetch a deliberately large
tools/list catalog with the normal Python SDK client;
- build/update a typed local capability index from those tool schemas;
- for each query retrieve a bounded relevant subset for host/model exposure;
- keep MCP sessions, notifications, tool calls, and server semantics unchanged;
- when
ToolsListChanged arrives, refetch and refresh the index rather than assuming the delta.
The comparison would report required-tool recall, exposed schema/context size, unsupported-query rejection, and refresh behavior after tool-list changes.
Would this be appropriate as a client example/story in this repository, or should host-side tool selection examples live outside the SDK? I would wait for maintainer guidance before opening code.
The current SDK docs make an important boundary explicit: servers should list tools normally and filtering is the host's job. That matches a validation experiment I am running with SchemaRouter, a typed capability/field retrieval layer.
I would like to contribute only a client-side example/benchmark, not a protocol or server change:
tools/listcatalog with the normal Python SDK client;ToolsListChangedarrives, refetch and refresh the index rather than assuming the delta.The comparison would report required-tool recall, exposed schema/context size, unsupported-query rejection, and refresh behavior after tool-list changes.
Would this be appropriate as a client example/story in this repository, or should host-side tool selection examples live outside the SDK? I would wait for maintainer guidance before opening code.