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

Annotations already declare readOnly, idempotent, and non-destructive, so the description focuses on the details the annotations cannot convey: a hard 20-entry result cap, newest-first ordering, and that only AI-app changes are included (human edits are excluded). It does not address whether any older history is retrievable beyond the 20-entry window.

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?

A single compact sentence delivers the result set, ordering, scope, and the connection to undo_change, with no filler or repetition.

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 adequately characterizes return entries (version id) plus size and ordering limits. The one remaining gap is what happens with pages that have fewer than 20 changes or more history than the window shows.

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%, and the schema already explains that "home" is the default and subpage slugs come from list_pages. The description only restates "a page" without adding format or default behavior beyond the schema, so the baseline of 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 exactly what is returned (the last 20 changes to a page), the ordering (newest first), the scope (changes made by AI apps), and a distinguishing detail (each entry carries a version id). This makes it clearly separate from get_page and positions it relative to undo_change.

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: naming undo_change and the version id hints that this tool is the way to find a version to revert to. It never explicitly says when to call this instead of get_page or get_stats, and gives no prerequisites or exclusions.

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