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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write+external nature is known. The description goes well beyond that by disclosing side effects per run (enqueuing a batch start), conditional webhook POSTs on classification drift, the returned watchId, owner scoping, and a hard cap of 20 active watches. It stops short of 5 because error behavior at the cap or on webhook rejection is not described.

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?

Four dense sentences with zero filler, front-loaded with the core action and cadence, followed by runtime behavior, return value, and constraints in descending order of importance. Every sentence carries information an agent would otherwise have to infer.

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 correctly states the return value ('Returns the new watchId'), and all four parameters are covered by schema descriptions. The main remaining gap is the absence of stated preconditions or failure modes for a mutation tool with external side effects, but for this complexity level it is nearly 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% and both enums (interval, format) are already documented in the schema, so the description adds little parameter-level meaning. Its mention of daily/weekly/monthly cadence and the webhook merely restates schema content, making the 3 baseline correct.

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 ('Creates a recurring brand-audit watch for a domain') plus the cadence options, so an agent knows exactly what is produced. It implies differentiation from the one-off sibling by describing each run as enqueuing a fresh 'brand_audit_batch_start', but it never explicitly contrasts itself with brand_audit_single or brand_audit_batch_start, keeping it short of a 5.

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?

Usage is implied: this is the tool for recurring monitoring rather than a single run, and the 'per-principal cap of 20 active watches' hint implies lifecycle management via delete_brand_audit_watch. However, it gives no explicit when-to-use/when-not guidance or prerequisite statements (e.g., what to do when the cap is hit).

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