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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds meaningful non-annotation context: it is a legacy/deprecated surface whose return shape differs from 'search'. It does not describe the return format concretely, but deprecation status is valuable behavioral context.

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?

Three compact sentences, front-loaded with the legacy status and ending with the redirect to 'search'. No filler, though the parenthetical repetition of the site name is slightly redundant.

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 deprecated redirect-style tool with a small two-parameter schema and no output schema, the essential information (what it does, why it still exists, and which sibling to use instead) is present. The only gap is the undocumented 'limit' parameter.

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 50% (query documented, limit undocumented) and the description contributes nothing about either parameter. It does not compensate for the undocumented 'limit' parameter or clarify query syntax beyond the schema's example, so it falls below the baseline-3 case.

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?

States a specific verb and resource ('サイトの中を探す' / searches within the site) and clarifies it is the former-named version of a search feature, explicitly contrasting its return format with the sibling 'search'. Clear enough to distinguish, though the name alone ('search_pages') plus heavy reliance on the legacy framing means a fresh agent still has to infer the exact capability difference.

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?

Explicitly routes the agent: it is kept only for users already connected, and for new usage the agent should use 'search' instead. This is a clear when-to-use-this vs when-to-use-the-alternative statement naming the sibling by name.

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