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

Beyond the readOnlyHint annotation, the description adds significant behavioral context: instructing not to fetch/follow product_url, to use product_url_canonical for automated actions, explaining the commissionable session trigger, requiring disclosure display, and specifying error return codes for cancelled and unknown watch IDs.

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 description is front-loaded with the purpose, then provides essential operational rules in a logical order, ending with error behavior. Every sentence adds necessary information, and the structure is clear and efficient despite its length.

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?

With no output schema, the description carries the burden of explaining the response. It lists the main status fields, URL handling, disclosure, and error codes. However, it does not provide the complete response structure or all possible fields, so a fully precise agent might need to infer some details.

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?

The parameter watch_id is already fully described in the schema as 'The watch_id returned by register_watch.' The tool description only mentions 'by watch_id' in the purpose, adding no additional semantic detail beyond what the schema provides. With 100% schema coverage, this meets the baseline but adds no extra value.

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 precisely that the tool returns the status of a watch by watch_id, listing the key data fields. This clearly distinguishes it from siblings like register_watch and cancel_watch, which create or mutate watches.

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 description gives clear context that this is for checking watch status, and it includes specific handling instructions for the returned URLs. However, it does not explicitly state when to use this tool versus alternatives, such as when to prefer check_watch over get_deal or search_deals.

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