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

Annotations already cover safety (readOnly, non-destructive, closed-world), and the description adds genuinely new behavioral context: this is a deprecated alias retained for backward compatibility, and its response shape diverges from fetch. The one gap is that it never says how the format differs, which matters somewhat since no output schema exists.

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 short sentences, each carrying distinct information: identity/deprecation, behavior and difference, and the recommended alternative. Minor weakness is that the deprecation framing precedes the statement of what the tool actually does.

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 one-parameter, annotated, deprecated read tool, the description supplies everything needed to make the correct decision (deprecated; use fetch instead). The only missing piece is the concrete shape of the returned body, which the absent output schema leaves undocumented.

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?

Single parameter with 100% schema description coverage, so the schema fully documents 'url' including that Japanese paths are acceptable. The description adds nothing about the parameter, which is the expected baseline given complete schema coverage.

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 the concrete behavior ('ページの本文を返します') and immediately contrasts it with the sibling fetch ('fetch と同じように…が、返す形が違います'). The legacy framing ('以前の名前の機能') is a bit roundabout as an opening, but the agent still learns exactly what the tool returns and how it differs from the alternative.

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?

It gives an explicit when-not ('新しく使うときは fetch を使ってください') and names the exact alternative, plus explains the only legitimate use case ('すでにつないでいる人のために残しています'). No inference is required to route away from this tool.

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