mystorax_axiom_tool_search

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of behavioral disclosure. It notes it does NOT dump the full catalog (a useful negative constraint) and labels itself a 'meta-proxy.' However, it doesn't describe what it returns (list of tool names? descriptions?), pagination, or how it behaves when the query matches nothing. The description adds some value but leaves behavior ambiguous.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no filler. The second sentence adds a useful negative clarification. Concise and front-loaded, though slightly terse given that it's a meta-proxy tool worth a bit more explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-param search tool with no output schema, the description is arguably adequate but thin. It doesn't describe result format, what 'search' returns (matching tool IDs? full metadata?), or sample usage. Given it's a meta-proxy whose results feed into later calls, more return-shape guidance would help. Adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the single 'query' parameter is already documented as a 'substring match on tool name.' The description adds no additional parameter meaning beyond confirming the search scope ('allowlisted Axiom tools'). Baseline 3 is appropriate since the schema fully covers the one parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states it 'search[es] allowlisted Axiom MCP tools' and clarifies it's a 'meta-proxy,' distinguishing it from actual Axiom tools. The purpose is clear, and 'meta-proxy' plus 'allowlisted' differentiates it from siblings like mystorax_capability_lookup and mystorax_axiom_tool_call. However, it doesn't explicitly state what the tool is NOT for (e.g., not calling tools directly), though the 'meta-proxy' label hints at this.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for discovering/searching among Axiom tools without dumping the full catalog, which gives context for when to use it. It doesn't explicitly contrast against sibling tools or state when NOT to use it, but the 'does not dump the full bio catalog' clause hints at a scoping alternative. This is reasonable but could name alternatives explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.