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

Discloses behavior the annotations do not: roughly one minute of latency, an async job that produces a result you read separately, a paid-plan requirement, and consumption of a shared daily cap with Debriefing. The idempotency semantics (a retry with the same key returns the first answer, starts no second job, and burns no second allowance) are spelled out precisely; this is key-scoped replay protection, which is compatible with idempotentHint=false meaning the call is not idempotent without a key.

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-loaded with the action and the cost-in-time, and every sentence carries a distinct constraint. The telegraphic fragment style ('The competitor needs finished research. Needs a paid plan...') is dense but slightly clipped.

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?

A paid output schema exists, so return values need not be explained, and the description correctly redirects to get_battlecard for results. Prerequisites, cost, latency, and retry behavior are all covered — nothing an agent needs before calling is missing.

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 both parameters are already documented in the schema, including the idempotency_key retry semantics. The description adds only a mild reinforcement ('Send an idempotency_key') and the competitor-quality prerequisite; baseline 3 applies.

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 ('writes or rewrites the battlecard for one core competitor') and pins the scope to a single competitor. It is clearly distinguished from the read-side siblings by telling the agent to 'read it afterwards with get_battlecard'.

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 explicit when-to-use ('now, instead of at the next cycle'), the follow-up action (get_battlecard), and concrete prerequisites (finished research, paid plan). The alternative path is named rather than left to inference.

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