Open to tools/search and resources/search

[patwhite]

Is the dev team here open to a spec update that adds a simple search endpoint to the tool and resource endpoints? Potentially prompts, too. The idea would be to enable agentic searching for proper tools when there may actually be thousands of tools.

I know part of the design here was very focused servers, but I think we need to enable a generic MCP tool discovery mechanism when you have larger servers. Wanted to gauge temperature or see if this had been considered. This might also require some sort of namespacing concept, curious if folks have thought about that and/or would be open to it (ie list all tools for a namespace).

High level, I guess the question is, at a sufficiently large enterprise, have you considered how an aggregator would work that allows ai driven discovery of enterprise capabilities across teams without manually adding multiple MCP servers?

Thanks!

[mgomes]

+1 here. We're currently building an MCP server that will have 200+ tools. We're planning on a creating a custom tool to perform a RAG-type search to help narrow the set of tools to something that fits in a context window and still performs well.

Having tools/search as part of the spec would make it compatible with all clients.

[allenporter]

It seems like this can be accomplished using the existing spec, using tools that provide this functionality.

[patwhite]

@allenporter since this is just an RPC protocol, technically anything could be implemented with tools, including resources and prompts. The way I’m thinking about the default methods (capabilities) here is, what should calling ai’s KNOW could be available. Searching tools is a great example of something that AI’s should know is a core, normalized capability, so folks can optimize that into their workflows. Basically, because of the smarts in LLM’s, “discovery” as a core use case is really important one, and I think should be normalized.

[patwhite]

@jspahrsummers are you one of the maintainers that would accept / reject something like this? I don’t want to spend time on a pr if it’s not interesting for the maintainers

[justinwilaby]

+1 Here as well.

On a side-note, I'm in contact with Pinecone who is also looking at a solution for this and we're meeting to network and trade notes. It seems reasonable to expand the spec for this purpose given the interest. This paper expands on the virtues of what @mgomes mentioned above and is the route we may take.

[allenporter]

The way I’m thinking about the default methods (capabilities) here is, what should calling ai’s KNOW could be available. Searching tools is a great example of something that AI’s should know is a core, normalized capability, so folks can optimize that into their workflows. Basically, because of the smarts in LLM’s, “discovery” as a core use case is really important one, and I think should be normalized.

I don't agree with the specifics of the proposal to add search to tools and resources, and it implies that the list call can't return all the tools supported by a server. (To be clear, i'm not dismissing the idea of standardizing on discovering new capabilities ) Standardizing a scenario where a single server has some unbounded number of tools that need to be searched is the way to model this problem (e.g. tool discovery WITHIN a server). There are also a few previous discussions that are tangential or related:
#69
#94
https://github.com/orgs/modelcontextprotocol/discussions/84

[patwhite]

@justinwilaby I’d be very interested in being involved in a discussion around that and how MCP severs in general can scale to large volumes of tools, any chance I could get involved?

[justinwilaby]

@patwhite - I think that might be possible!. Send me a connection request and I'll see what I can do! https://linkedin.com/in/uiengineer

[jspahrsummers]

Having a way to search anything that supports listing definitely seems useful (if for no other reason than to avoid many repeated pagination requests).

We have a facility for "completion" in the spec already. It seems like this covers the case for resources—perhaps we just need to extend it to support tools as well?

[McSpidey]

I’m thinking about these sorts of problems and opportunities too and have been building a prototype extension for MCP to test them but ultimately just want them in core MCP so they’re MIT licensed. Have written up a lot of the ideas here for making a concierge agent with protocols to expose and network coordinate the MCP endpoints https://mcpintegrate.com/

[patwhite]

@jspahrsummers I think completion is slightly different - the way we're looking at this is at an enterprise, it will not be uncommon for a company to have 10's of thousands of APIs that they're looking to MCP enable. The flow we're focused on here is agentic discovery of tools, whereas completion (as I understand it) is a bit more focused on a user-centric interactions, but maybe I'm misunderstanding the intention of the utility.

So, I think there's pretty good consensus here to pursue something, @justinwilaby and I have connected and are going to start working on a PR, if anyone else is interested in being involved please feel free to reach out here!

[zmoshansky]

@patwhite While a basic search would definitely be useful, the logical absurdum seems like it would be a multi-stage loop.

1. Search for appropriate resources/tools
2. Use result as additional context
3. Loop 1...2

Would you consider how looping or sequential execution may play out as part of search?

It may be worth looking to aspects of crewAI/Langgraph/autogen for inspiration here. Some of the aforementioned systems utilize a concept of a manager to coordinate tool calling/sequential actions. Or as defined in this SequentialThinking MCP Server https://github.com/modelcontextprotocol/servers/blob/main/src/sequentialthinking/index.ts

[patwhite]

@zmoshansky completely agree, I actually think that's why the search feature is so important over a simple list feature, that AI's can get and refine their queries.

I'd say, this feature in general is really for enabling enterprises with agentic flows, and that's obviously dead center for CrewAI - you have a manager agent that has a problem, sends that to a worker agent whose job is to find an MCP server or an internal api that can handle the use case, it returns some options back, they iterate, attempt a few calls, then complete the task.

[LucaButBoring]

Out of curiosity, how would this be used at a high level? Would every MCP server be responsible for doing searches over its own tools itself, with the client host process aggregating the results? If I'm using one MCP server with thousands of tools, that'd be helpful, but if I'm using thousands of MCP servers with a small number of tools each, that's a massive number of dependency calls the host process would need to make. Search implementations also aren't all created equal, so that would cause problems if any one of them has a slow one.

At a glance, this feels like something that would be better-suited to the host process, which can just call the list actions once (with change listeners etc.) and do indexing and searches itself.

[patwhite]

@LucaButBoring I think that ends up being a bit of an implementation question - if this is exposed as a capability, smaller servers might not expose this at all, if there are millions of tool, or it could expose a very simple search.

The main reason for including this in the spec is to give LLMs known access to this capability for larger use cases. That is to say, this is NOT really designed for folks running MCP servers locally, this is designed for large scale MCP servers in organization where tool discovery would be non trivial, and listing everything every time a client connects (whihc is the way that, for instance, the OpenAI agent is designed) is not realistic. So, a lot is definitely left up to the authors of a MCP server how they want to enable this, but it's designed for consumption by LLMs of large scale toolsets.

[patwhite]

I'll add, I think that's where @allenporter and your (@LucaButBoring) view of this diverges from from myself and @justinwilaby - this is not really for local MCP servers, I'm not sure search would ever be implemented on a local MCP server (though you COULD imagine someone building a really cool local MCP proxy that allows you to easily turn on and off upstream services and provides search). The use case here is for a hosted mcp server that is fronting / proxying to thousands of upstream tools. So, whether you do an indexed search or a fan our search ends up being an implementation question. But, the high level here is there will absolutely be situations where there are 10k to 100k tools accessible through a single MCP server which breaks a simple "list" call model.

[LucaButBoring]

The introduction of a new dependency call into the query path is still a significant change to consider, but emphasizing that this is an optional capability intended for the largest servers does lay my biggest concern to rest.

To clarify, I wasn't focusing on local MCP servers - I actually didn't anticipate many issues there since they're not going to be operating under the same kind of load. This is primarily a concern of remote servers, especially multi-client ones that might need to serve hundreds or thousands of searches at once. Search latency could still be a problem even with a small number of servers in that context, but I think #246 would help with being able to diagnose that when it occurs.

[mgomes]

this is not really for local MCP servers, I'm not sure search would ever be implemented on a local MCP server

@patwhite what about in the case of resources/search? What if for example you exposed your local home directory to an LLM but wanted to provide it with a way to search?

[patwhite]

@LucaButBoring ya, very good call out, this is 100% an optional capability.

@mgomes great point man, I hadn't even been thinking about that. So, I take it back haha, this is good for local and remote.

One question for everyone - @justinwilaby and I were discussing the actual proposal here, I think there are two options:

Option 1 - Feature Level Searching

Capability Definition:

{
  "capabilities": {
    "prompts": {
      "search": true,
    },
    "tools": {
       "search": true
    },
    "resource": {
       "search": true
    }
  }
}

Methods:
tools/search
resources/search
prompts/search

Params

• Query: string

Return would look like the list item for the respective item

Option 2 - Top Level Search Utility

Capability Definition:

{
  "capabilities": {
    "search": {
      "tools": true,
      "prompts": true,
      "resources": true,
    },
  }
}

search/query
Params

• Type (optional): string[] (enum: tool, prompt, resource) -> Are there considerations about future proofing
• Query: string

When deciding between the two options, I think it's actually important to consider which the LLM will find easier or more useful. If an llm is just poking around an MCP server, it might just want a single search rather than firing 3 off. I'm not sure how much the intelligence of the LLM should be considered here tbh

[samsp-msft]

In environments with hundreds of servers and thousands of tools, such as a corporate intranet, feeding the complete tool lists into an LLM would exceed token limits and could cause confusion.

A RAG scenario for MCP server/tool/prompt search might be more effective. The LLM should be able to search for MCPs/tools using keywords, including input/output types, to return a smaller list of relevant MCPs. The LLM can then select from the curated results, based on what is the best fit based on the context it has.

It's unclear whether this should involve a distributed fan-out to each MCP server or if there should be a new role for MCP servers dedicated to tool searches. Training LLMs to understand this concept would enable them to perform searches rather than relying solely on provided tool lists. Instead of configuring a list of MCP servers, you would provide a shorter list of MCP search servers to be called first.

[LucaButBoring]

I think that highlights another question to be answered around how search queries might be supported at a process/implementation level in light of the fact that the LLM wouldn't know what tools are available prior to doing a search. Today, LLMs are fed the tool list in the same prompt as the user query (see LibreChat's implementation as an example), but incorporating search requires a different and potentially much more complex flow. It'd be great to get some client maintainers to weigh in on how they imagine this would be implemented on the client end.

Whether this is proposed as a regular capability or a special search server designation, I think you'd need to split queries into two broad steps: task extraction and tool execution.

• Task extraction would be a new step responsible for identifying one or more key tasks that one or more search servers need to provide tool lists for. The final tool list would be a concatenation of the search results from each server, along with full tool lists from servers that don't support search capabilities (depending on exactly how search servers will work). This step introduces new complexity around attempting to generate predicted tasks that will actually map to the list of tasks on the server, since that list is no longer in the context.
• Tool execution would just be the standard tool usage step we see today, nothing new here.

I think this diagram should be mostly accurate as to how that'd work:

sequenceDiagram
    participant Agent as User/Agent
    participant Host as Host Process
    participant LLM
    participant MCPServer as MCP Server

    Agent->>Host: 1. Input

    loop Goal-seeking
        Host->>LLM: 2. Preprocess input to extract key tasks
        LLM->>Host: 3. Return key tasks
        Host->>MCPServer: 4. Search for each key task
        MCPServer->>Host: 5. Return tool search results
        Host->>Host: 6. Concatenate shortlist of relevant tools
        Host->>LLM: 7a. Query model with shortlist of tools and full query from (1)
        LLM->>Host: 7b. Execute tools, process results (potentially generating a new input)
    end
    Host->>Agent: 8. Return final response

Loading

[patwhite]

@jspahrsummers @justinwilaby @LucaButBoring @mgomes @samsp-msft First Draft of the spec updates here: #322

Would love feedback, I ended up going with a search per feature area model (so, tools/search) rather than a single search/query endpoint (mostly to simplify client interactions, it's not clear what the best way to interleave tools, resource, and prompt results would be, so that leaves you with 3 return lists, and then pagination becomes a nightmare. This is more verbose, but I think clearer.