Request Search

It'd be interesting if this could somehow be leveraged on the server side to do a single large search rather than three separate ones, that might be a tricky optimization, though. I suppose the server could hypothetically have a reactive stream consuming and batching client search requests to handle in a single query, maybe 🤔

Not a criticism and I don't have concrete suggestions about it, it's just something that stood out to me when I re-read this line, since the complexity trade-off is questionable. Realistically with a "sufficiently-fast" index it shouldn't make much of a difference anyways, since this is an edge case already.

Ya, I actually originally started going the direction of a single search/query endpoint - the BIGGEST issue is you end up in a situation where implementors have to make a lot more implementation decisions about how you interleave results, and the consuming LLM would I think get more confused. So, the options are:

1. Single return with sections:

{ 
toolResults: {
   items: []
   nextCursor: tring
},
promptResults: {
...
},
resourceResults: {
...
}
}

That strikes me as too confusing for the llm to really process today, maybe that gets revisted a few years from now
2. A single result list, with items intermingled. This is somewhat doable with good vector lookups, but let's say the LLM knows it wants a tool, it has to craft an input that includes a filter, and suddenly we're back to quite a bit of client complexity.

I'm actually open to all three options here, but when I really thought through all this, it just seemed like separate endpoints was the for the llm, easiest for the implementors, and most understandable all around.

But, great feedback

nanonit: "Search can help with this"? "Search can help alleviate this"? Feels like some word is missing there.

nit: is this intentionally or unintentionally a lowercase "should"?

More importantly, maybe we should avoid calling this a tool here - a tool is already a specific concept, so calling this a search tool begs the question at this point (prior to digging through the spec) of how this is any different from a regular tool call that triggers a list update. Maybe just "a search interface"?

Also, this is only one client integration pattern and others may find better ways to leverage this, so maybe that can be made more clear with some extra comment like a "client applications are free to integrate this search interface into their tool selection workflows in any manner," even though what you have here is a good recommended integration pattern to lead with.

ya, this is tool in the LLM sense, NOT the MCP sense. So, could genericize it to function call, it's a good call out

Likely need one for resource templates, too.

I'd also add something here like "The server SHOULD validate that the query parameter has not changed between cursors, and MAY return an InvalidParams error if this condition is violated."

Coming in late here, but I see this was added in the initial commit and I was curious why it was there. If a server needs the original query for its pagination logic, then it could easily encode that into the cursor string. Servers that are pointed to database and just use the database's cursor might not even have a way to readily validate the original query without an extra storage mechanism.

So, GENERALLY in search it's a best practice to include the query in repeated requests, but it's true some of these queries could be long, I'll think about this. It's just kinda ugly to change the request besides the cursor tbh

Maybe we could use an optional maxResults parameter to leave this up to client app implementors? For some models, 10 could be too many already (though I'm not aware of any such models), while others can handle more without any issues. Or, I might just want to limit result sets even more to further reduce the odds of the model selecting an incorrect tool. On the server side, maybe I want to spend a bit more time on search relevance to send more results at once to reduce bandwidth. Either way, I don't think the maximum number of items per page should be specification-defined.

On the other hand, I imagine the reason why this wasn't made into a parameter here is because individual servers setting their own limits is difficult to negotiate prior to making a request. Maybe the max results can be added as a parameter with a requirement that servers clamp the result set to at most maxResults if it is provided, which still allows for servers to set their own, lower limits too.

If we agree to remove "tool" verbiage here as suggested at the top of the doc, this could be changed to "Expose search interface to LLM".

nit: phrasing should be consistent with the other bullet points, e.g. "Deeply index resources"

nit: phrasing should be consistent with the other bullet points, e.g. "Avoid caching search results"