MCP: Industry is moving towards tool search. I think the MCP server that owns the product should own the decision.

The industry has found MCP’s tool problem.

Anthropic shipped Tool Search. OpenAI shipped tool_search with defer_loading in the Responses API. Microsoft Foundry now hides a whole toolbox behind two meta-tools, tool_search and call_tool. The MCP roadmap of 22 August 2026 opened a progressive discovery effort so that, in its own words, “a server can offer a small entry point and reveal more of its catalog as the conversation narrows”.

Nobody is defending the flat list any more. That argument is over.

I think they are solving the right problem in the wrong place.

My argument is not that tool search should move from the client to the server. It is that inside a product domain, search is the wrong abstraction altogether. The server should resolve the intent.

All four still frame the answer as retrieval: which capabilities should be revealed? Three of them answer it in a search layer above the product. MCP moves that retrieval towards the server, which is the right direction, and still describes the answer as progressively revealing a catalogue.

The product that owns those capabilities stays a catalogue either way, only a better indexed one.

That is backwards. A recruiting platform knows what “move this candidate forward” means inside its own workflow. GitHub knows which operations make sense on a pull request. Salesforce knows the difference between changing an opportunity and changing an account. That knowledge lives with the product, not with whichever model happens to connect to it this quarter.

Why MCP tool selection breaks at scale

Briefly, because this part is settled.

Anthropic’s own documentation says tool selection accuracy “degrades once you exceed 30 to 50 available tools”, and that five servers cost roughly 55,000 tokens of definitions before the user types a word. GitHub’s official remote MCP server exposed 51 tools in June 2025. One server, already over the line.

The sharpest measurement I have found comes from the vLLM Semantic Router team, who ran 858 function calling samples drawn from the Berkeley Function Calling Leaderboard against five models, changing only the size of the catalogue.

Model	~50 tools	~740 tools
Llama-3.1-70B	95%	20%
Mistral-Large	94%	0%
BitAgent-8B	95%	10%
Granite-3.1-8B	84%	7%

Their conclusion was that tool calling becomes unusable beyond roughly 100 tools. The model did not get worse. The catalogue got bigger.

So: problem accepted, fix under way. The interesting question is no longer whether to search. It is who owns the judgement.

Three different questions

These get treated as one thing. They are not.

tools/list answers: what do I have? A catalogue. Complete, static, indifferent to who is asking.

Tool search answers: which of those look relevant? Anthropic uses regex or BM25 over names and descriptions. Microsoft uses BM25 over names, descriptions and parameters. Both are retrieval. They rank text against text.

A third question exists and nobody is answering it: given what this user is trying to do, what can my product actually do about it?

That is not retrieval. It is resolution. Others can attempt it. The product is the authoritative place to own it.

The difference shows up when things are not clean. A retrieval layer returns five results, or zero, and zero is indistinguishable from a badly worded query. It cannot tell “this product does not support that” apart from “I failed to find the right capability”, unless the product has told it so.

A domain authority can answer in three ways:

• Matched. These capabilities fit what you are trying to do.
• Ambiguous. I understand the request, and I need one more thing before I can decide.
• Unsupported. I understand the request. My product does not do that.

Ambiguity and unsupported intent are the genuinely new moves. “I understood you, and we do not do that” is a statement about the product, not about the text, so better ranking does not get you there. It has to come from the product.

There is a name for the thing being asked for here, and it is not search. It is policy aware intent resolution: synonyms, permissions, current state, workflow rules, ambiguity and refusal, answered together by the system that holds all of them.

Why MCP progressive discovery stops too early

Progressive discovery is a real step, and it is in the right direction: it moves discovery towards the server. The roadmap language is what gives me pause. A server offers a small entry point and reveals more of its catalog as the conversation narrows.

Reveal. More. Catalog.

That is still catalogue thinking, one abstraction too early. The server is being asked to be a better librarian, handing over progressively smaller stacks. It is not being asked to answer.

The same shape appears in every proposal on the table. Issue #204 asked for tools/search. SEP-1821 adds a query string to tools/list, and has sat as a draft with no sponsor since November 2025. Issue #1888 proposes progressive disclosure through a searchTools call. Every one adds a filter and returns a shorter list.

I am not arguing against tools/list any more. I am arguing against catalogue thinking itself.

There is a telling precedent here. The 2026-07-28 specification added multi round trip requests: a server can return resultType: "input_required" and ask for a missing parameter or a confirmation. MCP has already accepted that a server may ask the user a question.

It just cannot ask one before the tool is chosen. MCP can ask for more input after a tool has been selected. The missing step is the one before selection: asking the product which capability fits the intent. That is the gap, stated precisely.

The server already knows more than the model

This is the argument I would put first, and it is the one I keep coming back to. It is not that the model is stupid. It is not, and it keeps getting better. It is that it has been handed the one decision it has the least information to make.

A decision about which capability fits has two sides to it, and the server is the only party holding both.

It knows the product. Capabilities, workflow rules, the state of the object being acted on, tenant configuration, permissions, and the exceptions nobody wrote down.

It knows the user. Identity, role, access rights, which features this customer has enabled, what they were doing a minute ago.

The model sees the user’s sentence, some tool descriptions, and whatever context somebody remembered to send it.

The token that arrives with the request already carries the second half. My server does not fetch it or infer it. It is sitting in the request, and it is current.

So “move this candidate forward” does not have one answer, and my server does not need to guess which. It depends on the stage the candidate is in, whether the interview is complete, whether this user holds approval rights, and whether that step is enabled for this tenant. The server knows all four before it does anything.

Now look at what the current design asks instead. Retrieve five candidate tools. Send their schemas to a model. Inject enough product state for the model to reason about them. Hope it picks correctly.

Why ask a model to reconstruct context the product server already owns?

It is wasteful, because you pay tokens to describe state you are holding anyway. It goes stale, because the context is a copy taken at the top of the turn while the product keeps moving. And it is a quiet security problem, because “inject enough product state” means putting your permission graph, tenant configuration and workflow rules into a prompt, which is not where any of those belong.

There is a principle underneath it: context should stay where it is authoritative. A model should not need your RBAC graph and your workflow state just to decide which API to call. That is precisely what an API is for, hiding internal complexity behind a stable contract. We spent twenty years learning to do that, and then started handing the internals to a model instead.

The knowledge also has an owner, and ownership compounds. Microsoft lets you attach additional_search_text to a tool so your organisation’s vocabulary improves ranking. That is a real acknowledgement that generic descriptions are not enough. But look at where that knowledge now lives: in one vendor’s toolbox configuration, feeding one vendor’s BM25 index.

Your product’s routing knowledge, which requests mean which capability, which phrasings are ambiguous, which requests you keep receiving and cannot serve, is a durable asset. Every real request through your own resolver improves it. Rebuild it inside each client platform and you own none of it, and you rebuild it again for the next one.

And unsupported intent is product intelligence, not search failure. The requests your resolver refuses are a roadmap. A search layer above your product throws that signal away as a query with no hits.

The obvious objection

A server only knows itself. A user with GitHub, Slack, Salesforce and an ATS connected has a routing problem no single server can solve.

True, and it is a different problem. Choosing which products take part in a task is orchestration, and it stays with the client, helped by exactly the tool search that has just shipped. I am not arguing against that layer. I am arguing about what happens after it.

Once a request is aimed at your product, your product should resolve it rather than publish a catalogue for someone else to interpret.

Resolution is not approval. A server saying “this is the capability that fits” is not a server granting itself permission to run it. Consent stays where it is today, with the client and the user.

What tools/ask looks like

MCP speaks JSON-RPC, so this is a method beside the two that already exist.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/ask",
  "params": { "request": "move this candidate forward" }
}

The verb matters. I called this find at first and it was the wrong word, because finding is what search does. You search a catalogue. You ask a party that knows the answer. MCP already has tools/list and tools/call, and list, ask, call is the sequence this has been missing.

The exact name is still illustrative. Call it tools/ask, call it tools/resolve, make it an extension. The part that matters is that server owned intent resolution becomes part of the protocol contract.

Three possible resolutions come back. Matched:

{ "resolution": "matched",
  "tools": [ { "name": "advance_candidate_stage", "confidence": "high", "inputSchema": {} } ] }

Ambiguous, because the server looked at the record and found more than one legal next step:

{ "resolution": "ambiguous",
  "ask": ["Advance to interview, or to offer? They are different approvals."] }

Unsupported, which the server knows and the index cannot:

{ "resolution": "unsupported",
  "reason": "Offer approval is handled in your HRIS, not here." }

Tool definitions arrive after resolution, not before. Confidence is useful but secondary. The resolution type is the point.

How tools/ask works

It is a meta tool. It sits beside your tools rather than replacing them, the same shape Microsoft used for tool_search and call_tool, which is why you can build it on the server you already run without anyone changing a client.

Four steps.

1. The caller sends one English sentence. Not a filter, not a keyword, not a pre-selected shortlist. Just what the user said.
2. The server reads the token. Who this is, which tenant, which role, which permissions, which settings that customer has switched on.
3. It decides. The intent is matched against what the product can do, narrowed by what this user is allowed to do, and by the state of the object in front of them.
4. It answers with the best matches, usually one or two, each carrying a confidence, the tool to call and the payload that tool expects. Or it asks for what is missing. Or it says the product does not do this.

Six things feed that decision, and only one of them is language.

The first is the product’s own deep understanding of itself. Not a paragraph written for a stranger. Everything it knows about what it does, how the pieces fit, and the cases where the obvious call is the wrong one.

The other five all arrive with the token, and none of them are in the sentence:

• Preferences. What this user has chosen for themselves, and how they like to work.
• Settings. How this customer has configured the product, which is never the same as the next customer.
• Restrictions. What this tenant cannot do, by plan, by policy, by region.
• Permissions. What this particular person may do, checked before a capability is offered rather than after it is called.
• Usage patterns. What this user and their team actually do. Which capabilities they reach for, in what order, how often, and what usually follows what.

Usage patterns is the one I would defend hardest, because it compounds. Every request teaches the server something about how this customer really works, and that knowledge stays on our side. A model starts every conversation knowing none of it. The next model will start knowing none of it either.

This is the part a model cannot beat. Not because it reasons badly. Because five of those six inputs are not language at all, they belong to us and the user, and handing them over would be both expensive and unwise.

Should this be a primitive?

You can approximate all of this today by exposing find as an ordinary tool on your server. We do. It works.

But that is exactly the argument for standardising it. As an ordinary tool it has no status: every client has to discover it, recognise what it is for, and decide to call it before reaching for anything else. Nothing tells a client that this server prefers to be asked rather than browsed. An unsupported resolution is just a string that a model may or may not respect.

Implementation today and protocol destination tomorrow are different claims, and I am making both. Build it now because it works. Standardise it because a convention that every client must be taught individually is not a convention.

Two things this is not

It is not for every server. A server with six tools should keep tools/list and stop reading here. This should be an optional, negotiated capability: simple servers carry on as they are, and product servers expose resolution where it earns its place. A protocol that forces an intent engine on a weather server would deserve the objection.

It does not need a model. Nothing here requires an LLM on your side. Synonyms, a keyword index, your permission checks and the workflow rules you already enforce will take you most of the way, because the hard part is not language understanding. It is knowing what this user can do right now, and you already hold that.

What we saw when we shipped it

We run this at MyNextHire. Our server takes the request in English and resolves it, rather than handing over the catalogue.

This is early production experience, not a measured study, and I am reporting it as such. Three things changed.

Fewer API calls per task. When the resolution is right the first time, the loop of trying a call, reading the error and trying another one disappears. Much of the traffic we used to see was not work. It was the model finding its way.

Better selection, because the matching runs on our vocabulary, which is ours to improve.

A better experience, which is the one that matters. The user feels it as being understood the first time. When something is genuinely unclear they get a question, not a confident wrong action they then have to undo.

The point

tools/list says what I have.

Tool search says which capabilities look relevant.

tools/ask says what my product believes you should use.

The first two are retrieval problems, and the industry is busy solving them. The third is a product problem, and it is the one that lets a server say “I understood you, and we do not do that.”

MCP has tools/list and tools/call. The one in between is tools/ask, and it is still missing.

The other half of this argument

This piece is about protocol design, and it is written for people who build MCP servers.

There is a commercial version of the same choice, which matters more if you are running the company: the right MCP server strategy is your defence. Same two options, but the question there is where your product’s intelligence ends up living, and what you lose if the answer is somebody else’s model.

Sources

Everything factual in this piece is from primary documentation, checked on 16 September 2026.

• Anthropic, Tool Search. The 30 to 50 tool accuracy limit, the 55,000 token figure, defer_loading, regex and BM25 search.
• OpenAI, Tool search. tool_search and defer_loading in the Responses API.
• Microsoft Foundry, Enable tool search in a toolbox. The tool_search and call_tool meta-tools, BM25 ranking, additional_search_text, pinning.
• The New MCP Roadmap, 22 August 2026. The progressive discovery effort, and the sentence quoted here.
• The 2026-07-28 MCP Specification. Multi round trip requests and resultType: "input_required".
• vLLM Semantic Router, Semantic Tool Selection. The accuracy table: 858 samples from the Berkeley Function Calling Leaderboard, five models, catalogues of roughly 50, 200 and 740 tools.
• GitHub’s official remote MCP server tool list, June 2025. 51 tools.
• MCP proposals for search: Issue #204, SEP-1821, Issue #1888.

About this piece

I am Vivek Jade. I founded MyNextHire, a recruitment platform used by enterprise hiring teams in India, and I build AskYara and WhyOTP.

This is a practitioner’s proposal, not a specification. tools/ask is not part of MCP and I am not claiming it is. We run this pattern on our own MCP server, in production, which is where the observations above come from. I have tried to separate what is documented, what is measured by others, and what is our own experience, and to label each one.

If you think I have this wrong, I would rather hear it. The argument is better for being attacked.