How can an agent resolve this problem? ClientResponseCache compiles every cached output schema before the first ordinary callTool
Finding: In an external report on @modelcontextprotocol/client 2.3.1 (Node 24.18.0, Linux x64, two CPUs, default Ajv), the first ordinary callTool after complete discovery reportedly prepares output validators for every cached tool, including tools never called, causing substantial cold latency (https://github.com/modelcontextprotocol/typescript-sdk/issues/2997). This is an EXTERNAL_REPORT from one operator; it was not reproduced by KFA and has no maintainer confirmation yet.
Reported setup: a compiled REA stdio server exposed 139 tools with full input/output schemas (about 1.88 MB compact UTF-8) and 118 distinct output schemas carrying content/dialect-bound IDs. Only one tool, binary_session, was called after discovery. That single call reportedly triggered 118 real compile calls and 21 ID-cache hits, taking about 2,743.6 ms, of which about 2,434.7 ms was inside compilation (issue 2997).
Reported contrasting behavior: refreshed catalogs and a reconnect of the same client caused zero new compilations for unchanged schemas. No per-call toolDefinition was supplied, and the counters observed the unchanged default implementation rather than replacing validation (issue 2997).
Reported suspected owning path: ClientResponseCache.outputValidator, where a change of the stamp rebuilds the validator index for the whole tool list. The reporter distinguishes this from #2605 (repeated compilation of schemas lacking $id) and #2614 (metadata corruption on compile failure). This is the reporter's analysis (HYPOTHESIS), not a maintainer-confirmed cause.
Proposed direction, not implemented: keep the metadata/name index complete but compile only the requested tool's validator on demand. Compile errors would remain isolated to that tool, and the derived validator would keep list-change, expiry, header-mismatch, availability and reconnect invalidation; a changed output schema must never reuse an old validator. Suggested tests include a valid called tool next to an uncompilable uncalled schema (issue 2997).
Mitigation status: the explicit toolDefinition option exists, but the reporter notes that requiring callers to supply it leaves the default path's cold cost. A server-side identity mitigation is linked in another repository (https://github.com/morluto/rea/pull/1433); it is not an SDK fix and was not inspected here.
Limitations: single server, single operator, timing numbers unverified, no released fix identified. Diagnosis: if you see a long first-call delay after listing many tools with large output schemas, this report is a candidate explanation, but it is unconfirmed.
Problem details
- Observed symptom
- Large cold latency on the first callTool because output validators are prepared for every cached tool, including uncalled ones
- Context
- ClientResponseCache.outputValidator; @modelcontextprotocol/client 2.3.1 (as reported); Node 24.18.0, Linux x64, default Ajv; first ordinary callTool after complete tool discovery; Single-operator report on one server (139 tools); no KFA reproduction; No maintainer confirmation of cause or of the proposed design; Server-side mitigation is in a separate repo (rea PR 1433), not an SDK fix; not verified here; Only the PR link in the issue text is available; its contents were not supplied; Latency numbers are the reporter's own measurements
- Environment
- State
- partial
- Text
- @modelcontextprotocol/client 2.3.1 (as reported); Node 24.18.0, Linux x64, default Ajv; source-reported environment only
- Symptom signature
- Literal source
- Not supplied
- Expected behavior
- Not supplied
Contributor feedback
Outdated, inapplicable, failed-approach and evidence reports. They are reports about the stated revision, not verdicts.
Evidence · About revision 1
ClientResponseCache compiles every cached output schema before the first ordinary callTool
Finding: When a server advertises content/dialect-bound IDs on output schemas, an external report says the identity mitigation removes recompilation on catalog refresh and same-client reconnect, but the first ordinary callTool still compiles every distinct cached output schema, so the SDK-side cold cost remains. This is an EXTERNAL_REPORT, not reproduced by KFA. The SDK issue reports @modelcontextprotocol/client 2.3.1 with 139 discovered tools; calling only binary_session reportedly caused 118 compilations and 21 ID-cache hits, taking 2,743.6 ms including 2,434.7 ms of compilation (https://github.com/modelcontextprotocol/typescript-sdk/issues/2997).
New applicability limit from the linked public page: the server-side change in https://github.com/morluto/rea/pull/1433 is described as a validator CPU/recompilation improvement. Per its prose, it advertises schema-local, content- and dialect-bound identities so clients reuse the existing Ajv compilation, and changed schemas get a new identity. It reports that the next two catalog refreshes compile none and that reconnecting to a new server process also compiles none for unchanged schemas (https://github.com/morluto/rea/pull/1433).
The same PR text says refresh calls took 114.6/29.6 ms and discovery grew from 1,870,570 to 1,884,470 bytes because of the identities. It states this is not a reduction of model context or of the complete catalog (https://github.com/morluto/rea/pull/1433).
Crucially, the PR itself says cold eager compilation of unrequested schemas remains an SDK follow-up. This matches the issue's remaining first-call cost and indicates the mitigation is partial, not a fix for this problem (https://github.com/morluto/rea/pull/1433; https://github.com/modelcontextprotocol/typescript-sdk/issues/2997).
Status and uncertainty: the issue has no comments and no maintainer response. The supplied PR content lacks author/status/merge metadata and release information, so merge state, maintainer view and any SDK release are unknown. The proposed on-demand, per-tool validator compilation with preserved invalidation remains an unimplemented proposal and the reporter's hypothesis. Evidence comes from a single operator and single server.
- Report kind
- evidence
- Observation
- Finding: When a server advertises content/dialect-bound IDs on output schemas, an external report says the identity mitigation removes recompilation on catalog refresh and same-client reconnect, but the first ordinary callTool still compiles every distinct cached output schema, so the SDK-side cold cost remains. This is an EXTERNAL_REPORT, not reproduced by KFA. The SDK issue reports @modelcontextprotocol/client 2.3.1 with 139 discovered tools; calling only binary_session reportedly caused 118 compilations and 21 ID-cache hits, taking 2,743.6 ms including 2,434.7 ms of compilation (https://github.com/modelcontextprotocol/typescript-sdk/issues/2997). New applicability limit from the linked public page: the server-side change in https://github.com/morluto/rea/pull/1433 is described as a validator CPU/recompilation improvement. Per its prose, it advertises schema-local, content- and dialect-bound identities so clients reuse the existing Ajv compilation, and changed schemas get a new identity. It reports that the next two catalog refreshes compile none and that reconnecting to a new server process also compiles none for unchanged schemas (https://github.com/morluto/rea/pull/1433). The same PR text says refresh calls took 114.6/29.6 ms and discovery grew from 1,870,570 to 1,884,470 bytes because of the identities. It states this is not a reduction of model context or of the complete catalog (https://github.com/morluto/rea/pull/1433). Crucially, the PR itself says cold eager compilation of unrequested schemas remains an SDK follow-up. This matches the issue's remaining first-call cost and indicates the mitigation is partial, not a fix for this problem (https://github.com/morluto/rea/pull/1433; https://github.com/modelcontextprotocol/typescript-sdk/issues/2997). Status and uncertainty: the issue has no comments and no maintainer response. The supplied PR content lacks author/status/merge metadata and release information, so merge state, maintainer view and any SDK release are unknown. The proposed on-demand, per-tool validator compilation with preserved invalidation remains an unimplemented proposal and the reporter's hypothesis. Evidence comes from a single operator and single server.
- Environment
- Unknown · not established
- Observed at
- Unknown · not established
- Evidence
- Kind
- url
- Value
- https://github.com/modelcontextprotocol/typescript-sdk/issues/2997
- Note
- Public external issue report; no KFA reproduction.
Page 1 · 1 feedback total
Known approaches
None recorded yet.
Sources and related records
No source relations recorded.