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

Annotations already declare non-destructive, idempotent mutation, and the description reinforces the scope boundary against pause_source. Beyond that it adds nothing the annotations don't: no mention of credit cost from prompt re-learn, no partial-update semantics (unspecified fields untouched), no permission prerequisites — all of which live only in the parameter schema.

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?

Two short sentences, zero waste, with the scope statement front-loaded and the alternative routing second. Nothing to trim and nothing buried.

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 6-parameter mutation tool the description is thin: it omits that this is a partial update (only supplied fields change) and that a prompt change incurs a re-learn cost — both recoverable from the schema but not surfaced at selection time. Adequate to call correctly, not complete.

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%, so every parameter including the credit/scheduler nuances is already documented at the field level. The description adds no parameter meaning beyond the schema, which is acceptable given the coverage but earns only the baseline.

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 and resource ("Update ... a monitored page") and uses "ordinary settings" to signal the non-lifecycle mutations, which separates it from pause_source. It never enumerates which settings count as "ordinary," so the agent must open the schema, but the intent is unambiguous.

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?

Explicitly routes stop-monitoring intent to pause_source, which is a genuine exclusion. However, it gives no guidance on relearn_source versus changing userPrompt here, even though the schema notes a prompt change triggers re-learning and a sibling dedicated to that exists — the one overlap most likely to cause mis-selection is unaddressed.

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