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

Annotations only declare the write/open-world safety profile, so the description carries real extra weight here: it discloses that each due check consumes the selected sources' member quotas, that polling is agent-driven, and that the monitor can be stopped. The 'Use a stable requestKey' instruction signals idempotency behavior. Missing: what happens on a duplicate requestKey, quota-exhaustion failures, or any auth requirements.

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?

Three tight sentences with no filler, and the core purpose plus the quota/polling caveat are front-loaded ahead of the requestKey tip. Dense but readable; nothing is wasted, though the phrasing is terse enough to verge on cryptic in places.

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 needn't be described, and the annotations cover the write/open-world safety profile. The description supplies the operationally important context an agent needs (quota cost per check, polling responsibility, stoppability, idempotency key), though failure modes and rate-limit behavior remain unstated for a tool whose cost is explicitly recurring.

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 0%, so the description must compensate, and it only partially does: requestKey is given meaningful semantics (must be stable, i.e. idempotency key) and 'exact-contract' plus 'sources' loosely imply address and chain. intervalSeconds and the enumeration of supported chains are never addressed in prose, leaving two of four parameters unexplained anywhere.

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 (Create) plus a well-qualified resource: a 'persistent owner-scoped exact-contract monitor'. The qualifiers 'persistent' and 'exact-contract' begin to differentiate it from siblings like monitor_asset and check_asset_monitor, but no sibling is named, so the agent must still infer which tool to pick.

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?

Implies ongoing polling ('the agent controls polling and can stop it') which suggests this is for durable, repeated checks rather than a one-shot, and hints at stop_asset_monitor as the lifecycle partner. However, it never says when to prefer this over monitor_asset or check_asset_monitor, nor any prerequisites such as prior authentication or quota availability.

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