Problem

tool_search still carries legacy shape and unnecessary payload fields. The request and response currently expose implementation details and echo input values that do not help agents choose tools.

Current pain points:

• includeStatic adds unnecessary complexity; public visible tools should be searched together.
• response echoes query, group, and includeStatic, which just parrots request fields.
• totalCount is currently not a true total when limiting is applied, and total counts are usually not worth the token cost.
• limit encourages agents to pick arbitrary large values. This conflicts with the compact pagination direction.
• query matching is strict conjunction over token substrings, so broad discovery queries like class create slots update package can unexpectedly return no results.

Desired direction

Make tool_search compact and discovery-oriented:

• always search the public visible catalog; remove includeStatic;
• return only useful data, primarily tools plus optional continuation;
• use the shared compact pagination approach from Make pagination compact and reusable across tools #60;
• prefer page/cursor continuation over arbitrary caller-chosen limit;
• consider ranked search semantics so multi-term queries remain useful for discovery.

Example target response:

{
  "tools": [...],
  "nextCursor": "..."
}

Exact cursor/page shape can follow the project pagination decision, but it should minimize token footprint and avoid echoing request fields.

Notes

This came from reviewing tool output while working on #60. It should be handled after the compact pagination PR lands so the catalog tool follows the same API style.