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

The annotations declare readOnlyHint=false with destructiveHint=false, and the description usefully explains the non-destructive side effect that makes it non-read-only: it deducts prepaid credits from a reusable key. That is genuine added context. However, it omits the cost per call, what happens when credits are exhausted, and whether the deduction occurs on failure, all of which matter for a credit-metered call.

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?

Two short sentences, front-loaded with the resource and followed by the billing side effect, with no filler. It is efficient, though the terseness borders on under-specification rather than polished brevity.

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 definition should convey what is returned (record shapes, counts, live vs. historical separation) and how a metered call fails. Instead it leaves the ambiguous required "lookup" parameter and the entire response shape unexplained, which is thin for a credit-charging tool.

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 only 50%: creditKey is documented in the schema, but the required "lookup" parameter has no description anywhere, and the description does not compensate by saying whether lookup is a domain, a URL, or a path. The description adds no parameter meaning beyond repeating the existence of the reusable key.

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?

"Live and historical redirects for a domain" names a specific resource and two scopes (live vs. historical), which is enough for an agent to know what it retrieves. It falls short of a 5 because it never distinguishes this paid variant from the plainly named sibling redirects-api, so an agent cannot tell from the definition which one to pick.

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 contains no when-to-use, when-not-to-use, or alternative-selection guidance. The only usage signal is implicit: the mention of prepaid credits hints that a key is required, but nothing says when this tool is preferable to a non-credit sibling.

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