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

Annotations already establish read-only, idempotent, non-destructive, and open-world behavior. The description adds valuable behavioral detail beyond the annotations by specifying the 24-hour 0-100 busyness curve, weekday breakdown, busy/quiet/peak hours, and the venue_id output, plus a concrete call example. The word 'creates' is computational rather than a state-changing operation, so there is no annotation contradiction.

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 compact and front-loaded, moving from the user-facing question to the input-to-output behavior and ending with a helpful concrete example. The opening question and the following 'creates a busyness forecast' clause are slightly redundant, but no sentence is wasted.

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 simple three-parameter, read-only tool with no output schema, the description is complete: it names all inputs, describes the output structure including the 0-100 curve and venue_id, and provides an executable example. An agent has enough context to invoke the tool and interpret the result without guessing.

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%, with each parameter already documented with examples and allowed lengths. The description adds only light context such as venue type examples and reinforces the parameters through its inline example, but it does not bear the burden of explaining semantics beyond the schema.

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 clearly states a specific verb/resource: it creates a busyness forecast for a public venue by name and address, and enumerates supported venue types. It also distinguishes itself from querying by mentioning the returned venue_id for later queries, though it does not explicitly contrast with sibling tools like besttime_live or besttime_query.

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 intended use case is clear: use this when you have a venue name and address and need a 24-hour busyness forecast. It also hints at future usage by returning a venue_id for later queries. However, it never explicitly says when not to use it or which sibling tool to use instead, so it misses the top score.

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