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

Goes well beyond the readOnlyHint/non-destructive annotations: it discloses the capability gate (easy_mcp_ai_view_all_history), that unauthorized entries are masked as 'not found' rather than erroring, that ip_address is admin-only, and that content_before/revision_content depend on read access to the parent post. The `unrecoverable` reason taxonomy (redacted, truncated, value_unavailable, not_stored, revision_gone, not_recorded, plus path "*" semantics) is exactly the kind of degradation behavior annotations cannot convey.

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?

Core purpose is front-loaded in the first sentence, and the dense field-availability sentences each carry real information. There is minor redundancy ('Body text is shown only when you can read the post now' restates the earlier read-permission condition), and the opening clause about post/page/media entries is convoluted, but nothing is wasted.

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, so the description carries the full burden of explaining return values, and it does so field by field (content_before, content_before_unavailable, revision_content, unrecoverable, ip_address). For a two-parameter read tool, an agent has everything needed to call it and interpret the response.

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 100% and both parameters (id, site_id) are documented with an enum for site selection. The description reinforces that id is a change-log row id but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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, resource and scope: fetch a single change-history entry by id, returning before/after payloads. This is clearly distinguishable from wp_history_list (enumeration) and wp_history_diff (comparison), and the use of an id from wp_history_list anchors it as a detail-fetch 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?

Usage is only implied: the tool takes an entry id 'as returned by wp_history_list', so an agent can infer the list-then-get workflow. There is no explicit statement of when to prefer this over wp_history_diff or wp_history_list, and no exclusion guidance, leaving the routing to inference.

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