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

Annotations only flag it as a non-readonly, non-idempotent, open-world operation; the description goes well beyond that by disclosing the snapshot-on-creation behavior, the periodic polling model, and the once-only delivery of prazo_impugnacao and prazo_proposta notices. This is genuinely useful behavioral context for a stateful watch tool.

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?

Front-loads the purpose and token requirement, then layers behavior and notice timing in two further sentences with no filler. Slightly dense but every clause carries information an agent needs to call it correctly.

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 stateful watch-creation tool with no output schema, the description covers what it creates, how often it runs, and what notices fire. The main omission is how the watch is later referenced (e.g. via list_watch_events), but functionally the agent has enough to invoke it.

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 canal, destino and compra_id are already documented in the schema, including the enum values and the fact that destino is ignored for pull/email. The description adds no additional parameter meaning, which is the expected baseline when the schema does the work.

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 ('watches') plus resource ('a procurement') and enumerates exactly which changes it captures (correction, new document, suspension, postponed deadline and value, deadline notices). An agent understands the job immediately, though it does not explicitly differentiate itself from siblings like create_alert or create_alerts_by_cnpj.

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?

Gives the token prerequisite ('requires the token edm_…') and the operational note that checks are periodic with the last-check date available in the watch. However, it never says when to prefer this over create_alert or how it relates to list_watch_events, leaving the choice between watch tools to inference.

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