bunny_get_origin_errors

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and mutability. The description adds value beyond this by listing the exact error codes that will appear in the logs and stating the tool 'shows exactly why origin requests failed'. This provides concrete behavioral insight into the output content without contradicting annotations.

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 three sentences: the primary purpose, a list of returned error codes, and a use-case note. It is front-loaded with the main action, includes essential details, and has no superfluous content. Every sentence earns its place.

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 only two fully documented parameters and no output schema, the description is nearly complete. It outlines the nature of the data (error logs with specific error codes) and the primary use case (debugging 502/504). It does not describe the response format or potential pagination, but for a read-only, idempotent call with simple inputs, this is a minor gap.

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 both parameters already documented (date format and pull_zone_id). The description repeats this scope ('for a pull zone on a specific date') but does not add new semantic information about the parameters. At baseline 3 for full coverage, the description's contribution is minimal but not misleading.

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 the verb 'Retrieve', the resource 'origin error logs', and the scope ('for a pull zone on a specific date'). It also enumerates the specific error codes returned, which differentiates it from generic pull zone or statistics tools. This makes the tool's purpose unambiguous and distinguishable from siblings.

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 provides explicit usage context by stating 'Essential for debugging 502/504 errors', which tells the agent when to use this tool. It does not explicitly contrast with alternatives or give when-not-to-use scenarios, but the specified use case is strong enough to guide selection.

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