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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful context—that with `site` and no token you see the public view (a wiki article, a product without its price)—but says nothing about authentication failures, permissions, or what happens when a token and site conflict. It also contradicts itself slightly: it implies `site`-only reads, yet the schema marks `path` required.

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, front-loaded with the core contract (shape matches write_site) and then the precondition. Slightly mannered phrasing ('a sold product without its price') costs a little clarity, but nothing is 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?

No output schema exists, and the description compensates by tying the return shape to write_site, which is exactly what an agent needs to act on the result. Remaining gaps—auth-failure behavior and the read_page vs read_wiki_page split—are moderate but not fatal for a simple read.

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 all three parameters are already documented, including `path` = "" for home and the site/token interaction. The description reinforces the no-token public-read case, which is helpful, but adds little semantic detail beyond the schema (no format for path, no token precedence rules). Baseline 3 applies when the schema does the heavy lifting.

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 it returns 'one page whole' in the same shape write_site accepts, with the explicit motivation of editing and sending back. The verb is implied by the name/title rather than the body, and it never distinguishes itself from the sibling read_wiki_page, which an agent could easily confuse with it.

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?

Gives a concrete precondition: 'Read every page you mean to change first: write_site replaces a page whole,' naming the alternative and the consequence of skipping this step. Leaves the read_page vs read_wiki_page choice unaddressed, so usage is clear for the write path but not for the wiki path.

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