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

With no annotations provided, the description carries the full behavioral burden. It discloses that the report is not generated on the spot, that a human builds it, that it typically arrives within 24 hours, that it may spend quota or return a Stripe link depending on plan, and that an X-Mako-Key header is required. This is rich, non-obvious behavioral context.

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 a tightly packed set of four sentences, each contributing a distinct piece of information: scope, plan behavior, async delivery, and follow-up/auth. It is front-loaded with the core purpose and contains no filler.

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 tool with no annotations and no output schema, the description covers the essential execution context: side effects, timing, plan variations, follow-up tools, and authentication. It could mention the immediate response shape or order identifier, but overall the operational picture is well supplied.

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 63%, and the description adds almost no parameter-level meaning. It repeats 'competitor' but doesn't explain the opaque goal enum values, market format, or title/notes semantics, leaving the uncovered parameter gaps unaddressed.

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 opens with a specific verb and resource: 'Order a competitor Meta ads report for one competitor.' This clearly identifies the tool's function and its single-competitor scope, differentiating it from the generic sibling create_order.

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 strong contextual usage guidance: plan-dependent behavior (spends allowance vs. Stripe checkout), the async nature, and the follow-up workflow 'Poll get_status, then list_deliverables.' It does not explicitly contrast this tool with create_order, but the conditions for use are otherwise clear.

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