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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose key behaviors: the registry scope, the remotecallability requirement, the install-free nature of results, and the deliberate exclusion of installable packages. However, it doesn't mention non-destructiveness, rate limits, whether authentication is needed to perform the search itself, or what subset of server metadata is returned. The 'search' wording implies read-only, but that's implicit, not explicit.

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?

The description is three sentences with no waste. It leads with the core action and scale, immediately follows with the available filters, and closes with a concete exclusion and conceptual framing. Every sentence contributes operational context.

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?

The tool has 5 parameters, a high-schema-coverage, no output schema, and no annotations. The description provides solid domain context including scope, filtering, and the intended question it answers. The main gaps are the absence of any mention of the 'limit' parameter and no statement about the result format or default limits. For a search tool with a self-explanatory schema, it's nearly complete but leaves minor operational detail uncovered.

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 description coverage is 80% with four of five parameters already documented in the schema. The description adds a useful overview phrase, 'Filter by transport, host, or whether it needs credentials', which maps to transport, host, and auth, but it doesn't add detail for query or limit. The schema's parameter descriptions are already clear, so the description adds marginal value beyond them, making baseline 3 appropriate.

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 a specific verb ('Search'), resource ('14,704 remotely-callable MCP serves fom the official MCP registry'), and scope ('every one has a URL, so it can be added without installing anything'). It also semantically distinguishes itself from sibling search tools like search_products and search_x402_endpoints by focusing specifically on MCP servers. The title reinforces the purpose with 'Find an MCP server you can connect to right now'.

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 gives clear context on when to use this tool: when you want a server that is remotely callable and install-free, and it explicitly states the exclusion: 'servers distributed only as installable packages are deliberately excluded'. It frames the tool as answering 'what can I call now' not 'what exists'. However, it doesn't explicitly name a specific alternative tool (e.g., how_to_register or another registry lookup), so some inference is left to the agent.

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