René's URL Explorer Experiment

Title: [RFC] Search by patwhite · Pull Request #322 · modelcontextprotocol/modelcontextprotocol · GitHub

Open Graph Title: [RFC] Search by patwhite · Pull Request #322 · modelcontextprotocol/modelcontextprotocol

X Title: [RFC] Search by patwhite · Pull Request #322 · modelcontextprotocol/modelcontextprotocol

Description: EDITED May 12, 2025 Motivation and Context This proposal, along with #334, is an effort to make the MCP protocol slightly more agnostic towards whether MCP servers should be small, single use domain constrained servers, or larger, multi-purpose servers. At a high level, the various list methods suffer from the issue that a) they may be unbounded in terms of length, leading to clients making decisions about how many tools to list, and b) even shorter tool lists (in the range of 100) can produce token counts in the 50-100k token range. That increases cost as well as potentially decreases accuracy of the llm in selecting a tool (when presented with a large list). This is a proposal for an OPTIONAL capability for larger servers to expose search endpoints on tools, resources, resource templates, prompts, and potentially other capabilities coming down the pike. It proposes a recommended flow for clients to prefer search over listing tools, and to present LLM's with an initial tool set that starts with search and escalates to tool calls. There are native ways to support search using progressive tool disclosure. This is an effort to standardize general efforts around search and create a situation where any generic, well implemented client can connect to any generic, well implemented server and achieve 100% success executing a search. Please see notes below for other options and why this is being proposed as a good solutions. How Has This Been Tested? Presently built into ScaledMCP in experimental mode. Breaking Changes This is an opt-in capability, and is thus fully backwards compatible. Types of changes Bug fix (non-breaking change which fixes an issue) New feature (non-breaking change which adds functionality) Breaking change (fix or feature that would cause existing functionality to change) Documentation update Checklist I have read the MCP Documentation My code follows the repository's style guidelines New and existing tests pass locally I have added appropriate error handling I have added or updated documentation as needed Additional context The other method of implementing search is to expose a tool "search_tools", and upon completion of a call to that tool, expand the tool list and send a tools_changed notification to the client. There are several issues with this, first and foremost that it requires a client / prompt that primes the model for a multi-turn process. This proposal also includes an update to prompt, however this has a single implementation rather than an open ended, bespoke solution. So, given the goal of a well built client being able to negotiate a search with 100% success with a server, a specialized tool call seemed more likely to succeed over time than a dance. This proposal COULD be matured to define a search dance, however there are a number of complex server side issues with progressive tool disclosure (for instance, requiring server's to be stateful, which means server less implementations are much harder to build). So, this is a good compromise.

Open Graph Description: EDITED May 12, 2025 Motivation and Context This proposal, along with #334, is an effort to make the MCP protocol slightly more agnostic towards whether MCP servers should be small, single use domai...

X Description: EDITED May 12, 2025 Motivation and Context This proposal, along with #334, is an effort to make the MCP protocol slightly more agnostic towards whether MCP servers should be small, single use domai...

Opengraph URL: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/322

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width