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

Annotations already declare the safe read-only profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add non-annotation context. It does so by noting that results come with excerpts and by clarifying the closed-world scope (Yomitasu pages and site intro pages). It does not discuss pagination, result limits, or authentication, but those are minor given the annotation coverage.

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 front-loaded: it first states what the tool does, then enumerates searchable topics, then gives usage guidance and limitations. The list of topics is informative but slightly verbose, and every sentence earns its place by clarifying scope or usage.

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 simple one-parameter search tool with 100% schema coverage, an output schema, and clear annotations, the description covers purpose, scope, usage priority, and a key limitation. The only notable gap is the lack of explicit differentiation from the sibling 'search_pages', which could cause selection ambiguity.

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?

The schema fully documents the single 'query' parameter with a description and example, so the baseline is 3 when schema coverage is 100%. The tool description adds no additional syntax, format, or constraint information about the query parameter beyond what the schema already provides.

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 and resource: it searches Yomitasu pages for matching text and returns excerpts. It also scopes the searchable content to Yomitasu's own pages (mechanism, AI app connection, pricing, FAQ, policies, etc.). However, it does not differentiate itself from the sibling 'search_pages', which an agent might reasonably confuse with this tool.

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 explicit usage guidance: 'If asked about Yomitasu, use this first.' It also states a when-not condition: registered site introduction pages can be searched, but their actual contents should be searched via that site's own MCP server. It does not mention when to prefer or avoid sibling tools like 'search_pages', so it is clear but not complete.

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