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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real behavior: long lists come back truncated with counts, rows are returned whole as datasets, and history depth varies by plan (7 days on Free/Plus vs. all days on Pro/Studio). The quota note that "A game's page counts toward the day's games' history" is a genuinely useful consumption warning that nothing in the structured fields conveys.

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?

The key differentiator is front-loaded, which is good, but the middle is a sprawling comma-separated enumeration of page types that is hard to scan and largely redundant with the catalogue mechanism the tool itself provides. The retention/quota sentences earn their place; the page list does not.

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 single-optional-parameter generic pass-through with no output schema, the description covers the two calling modes, the truncation behavior, and plan-dependent history depth — enough for an agent to call it correctly. It stops short of describing the shape of the returned data, though "as the site serves it" and "rows whole as datasets" partly compensate.

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 single `path` parameter is already documented with concrete examples in the schema, so the description adds little. It restates the catalogue-when-omitted behavior that the schema description also states, without adding format rules beyond what is already given.

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 opening clause states the resource precisely ("One of RoTerminal's pages' data, as the site serves it") and explicitly positions it as the catch-all for "anything the other tools don't cover," which differentiates it from the many specific siblings. The long enumeration of page types reinforces scope but reads as a data dump rather than a crisp purpose statement.

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?

The fallback rule ("for anything the other tools don't cover") and the "Without path: the catalogue" clause together give a clear decision rule: omit path to discover, supply path to fetch. It does not address specific siblings like page_cards, game, or series, so an agent still has to infer when those win over this generic tool.

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