Broad find_tools queries such as "linear issues" saturated the hard 20-match cap on every call: a large server's name token-matches every one of its tools (+8 name, +1 server), so ranking was decided by a term carrying no discriminating information and the model got 20 activations per search regardless of intent.

Three changes, mirroring what makes xum's tool_catalog_search behave well:

• Lower default with a limit argument. Keyword matches default to 10 per call; the new optional limit raises that up to the existing hard cap of 20 (non-positive values fall back to the default). Exact names are explicit activation requests and bypass the limit up to the hard cap, so naming 15 tools still activates all 15.
• Coverage-first ranking. Keyword matches sort by distinct query terms matched before raw score, so a query like "linear issues" ranks tools matching both terms above the dozens matching only the server name.
• Model guidance. queries and names now carry schema descriptions (capability keywords and what they are matched against; exact-name activation), and the tool description opens by explaining what deferral means, that matches become callable on the next step, and that a "server: terms" prefix scopes a query to one server.

An earlier revision also inferred a server scope from unprefixed query words ("linear issues" behaving like "linear: issues"). Review kept surfacing edge cases in that inference, and coverage-first ranking already resolves the original saturation complaint, so it was dropped in favor of the explicit prefix.

The hard cap stays at 20 so the persisted result keeps fitting under the generic tool-result truncation budget that protects activation-recovery JSON. Budget and reservation accounting are unchanged; the frontend renderer ignores unknown argument fields, so no site/ change is needed.