Expose the search format on the MCP tool - #679
Merged
Merged
Conversation
Server-side landed in #678; this is the half agents can actually reach. knowledge_search takes format: results (default), stubs, or bodies. These are response SHAPES of one search, not different searches - the server dispatches stubs to the same progressive_index/3 and bodies to the same get_context/3 that knowledge_progressive_index and knowledge_context call. Nothing is retired. Both sibling tools stay registered and behave exactly as before. The schema says so in words and a test asserts it, so a later reader does not mistake this for a deprecation. The description states both refusals rather than leaving an agent to discover them: stubs and bodies REQUIRE a query, and an unknown value is a 400 rather than a quiet downgrade to results. An agent expecting a silent downgrade would read the error as an empty corpus. ON THE TEST, which is deliberately not written like its neighbours. The suites here re-implement handler bodies by design, since index.js has top-level await and exports nothing. That strategy structurally cannot catch the one failure that matters for a pass-through parameter: the schema advertising a field the request builder drops. A re-implementation forwards it correctly and passes while the real code does not. So this asserts against the index.js source, and mutation-verified it catches exactly that - deleting the params.set line with the schema left intact turns it red, as does removing a shape from the enum. That is the third instance today of the same shape - a value computed or declared in one layer and silently lost in the next, with a test green because it checked a thing existed rather than what it contained (#669 read the wrong keys off a result map, #672 never rendered keys onto one). Worth naming as a pattern rather than three coincidences. Version 2.74.0 with a CHANGELOG entry. Publishing to npm is a separate step and is NOT done here: until it is published and sessions restart, agents keep the 2.73.0 schema - the same staleness that cost the first day of search telemetry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Server-side landed in #678; this is the half agents can actually reach.
What
knowledge_searchtakesformat:results(default),stubs, orbodies— responseshapes of one search, not different searches. The server dispatches
stubsto the sameprogressive_index/3andbodiesto the sameget_context/3thatknowledge_progressive_indexandknowledge_contextcall.Nothing is retired. Both sibling tools stay registered and behave exactly as before. The
schema says so in words and a test asserts it, so a later reader doesn't mistake this for a
deprecation.
The description states both refusals rather than leaving an agent to discover them:
stubsand
bodiesrequire a query, and an unknown value is a 400 rather than a quietdowngrade to
results. An agent expecting a silent downgrade would read the error as anempty corpus.
The test is deliberately not written like its neighbours
The suites here re-implement handler bodies by design —
index.jshas top-level await andexports nothing. That's reasonable, but it structurally cannot catch the one failure that
matters for a pass-through parameter: the schema advertising a field the request builder
drops. A re-implementation forwards it correctly and passes while the real code doesn't.
So this asserts against the
index.jssource, and I mutation-verified it catches exactlythat:
params.set("format", …), leave the schema intactA pattern, not three coincidences
This is the third instance today of one value computed or declared in one layer and
silently lost in the next, each with a green test because it checked that a thing existed
rather than what it contained:
:resultsoff a map shaped%{stubs:, meta:}, so every successfulprogressive_indexrecordedzero_resultsprovenanceand recorded it;render_meta/1's whitelist neveremitted it, so no agent could branch on it
Publishing
Version 2.74.0 with a CHANGELOG entry. Publishing to npm is a separate step and is not done
here. Until it's published and sessions restart, agents keep the 2.73.0 schema — the same
staleness that cost the first day of search telemetry this morning.
mix precommitgreen (7,514). MCP suite 369 passing.Reviewed inline (this session's system prompt forbids dispatching review agents; per CLAUDE.md
the gate is satisfied by the best available reviewer with that stated).