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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuine behavioral context beyond them: passing amounts replaces all three suggestions, labels/headlines failing the word filter are silently blanked, changes affect future supports only, and writes are scoped to the creator's own account. Auth requirements and any propagation delay are still unstated, keeping it below a 5.

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 opening 'Change what the page does' is well front-loaded, but the long middle enumeration largely restates the schema property descriptions ('whether people may give without a name', 'whether the supporter count and total show') at length. The genuinely valuable sentences — word-filter blanking, replace semantics, future-only effect, account scope — are pushed to the tail.

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?

An output schema exists so return values need no explanation, and annotations carry the safety profile; the description covers scope, side effects, and replace semantics. The remaining gap is partial-vs-full update behavior for the nine non-amount fields, which an agent would want to know before calling.

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 the baseline would be 3, but the description adds meaning beyond the schema: 'Passing amounts replaces all three' clarifies replace-not-merge semantics for the amounts array, and it flags voiceBlessingsEnabled as Premium. It does not clarify whether the other boolean fields are partial or full replacements.

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 a specific verb (change) and resource (page behaviour) and enumerates the settings under its control, so an agent can tell it configures a page's support-facing behavior. However, it never distinguishes itself from the very plausible sibling update_page_appearance (nor from get_page_settings), which is a real ambiguity in a 40-tool set.

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 some conditional guidance ('Passing amounts replaces all three', 'Affects future supports only') and the schema entry for streamAlertOn warns to only set 'claimed' when the creator asked. But there is no explicit when-to-use-this-vs-alternatives routing, which matters given the overlapping page-appearance sibling.

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