ToolSearch: the `+term` prefix matches descriptions too, so it does not "require the term in the name"

Summary

ToolSearch's documented query forms include:

"+slack send" — require "slack" in the name, rank by remaining terms

Observed behaviour: the +-prefixed term is matched against tool
descriptions as well, so the results include tools that do not contain the
term in their name. The + prefix therefore does not constrain the result set
the way the contract states, and there is currently no way to force a
name-scoped search.

Observed on Claude Code 2.1.238.

Reproduction

Pick a term that appears in tool descriptions but in no tool name. In a
session with the browser and computer-use MCP servers deferred, sequentially
works:

ToolSearch { "query": "+sequentially", "max_results": 3 }

Returns:

• mcp__claude-in-chrome__browser_batch
• mcp__computer-use__computer_batch

Neither name contains sequentially; both descriptions do ("Actions execute
SEQUENTIALLY…"). Per the documented contract, a required-name term matching no
tool name should yield no matches.

A second example where a genuine name match exists alongside a description-only
match:

ToolSearch { "query": "+navigate", "max_results": 3 }

Returns mcp__claude-in-chrome__navigate (name match, expected) and
mcp__claude-in-chrome__browser_batch (no navigate in the name; its
description mentions navigate).

Ruling out the obvious alternatives

• Not "matches everything". ToolSearch { "query": "+qzxjwvbn" } returns

No matching deferred tools found, so the query does discriminate.

• Not same-server clustering. The two +sequentially results come from two

different MCP servers (claude-in-chrome and computer-use), so they are not
siblings pulled in together.

I can't tell from outside whether the name filter is absent entirely or is
applied and then backfilled up to max_results; either way the observable
contract is broken, since a caller cannot use + to exclude description-only
matches.

Why it matters

+ is the only documented way to scope a search to tool names. With many
deferred tools, a common word in a description (navigate, search, batch,
file) pulls in unrelated tools, and the caller has no way to say "I mean the
tool actually called this". The select: form is exact-name but requires
knowing the full name already — which for MCP tools means the fully-namespaced
mcp__<server>__<tool>, so it can't be used for discovery.

Suggested fix

Either constrain +term to name matches as documented, or — if description
matching is intended — update the description of the query forms, since
"require X in the name" is currently a promise the implementation doesn't keep.