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

With no annotations, the description carries full behavioral burden. It discloses that the tool records waste and returns a waste rate, and adds context that agent waste never raises an exception, making this ledger necessary. It also states 'Free.' indicating no cost. While it doesn't detail side effects (e.g., whether it appends or overwrites), the record‑only nature is implied. This is solid transparency for the criteria.

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 moderately long (three sentences) but each sentence adds value: purpose, rationale, and usage examples. It is front-loaded with the main action. There is slight repetition between 'Record work...threw away' and 'Report a discarded plan...', but it is not wasteful. Overall it earns its length.

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?

Given 5 parameters, one enum, and no output schema, the description sufficiently covers the tool's purpose, provides concrete use cases, and explains why it exists. It also mentions the return (waste rate) and cost (Free). It does not detail how the rate is computed or the exact format of the response, but for a reporting tool with such context, it is adequately complete.

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 60%, with descriptions for kind, agent, and reason, but none for tokens and cost_usd. The description adds examples that map to the kind enum ('Report a discarded plan...' etc.) and mentions 'spent money,' which loosely relates to cost_usd. However, it does not clarify the numeric parameters or their relationship, and does not compensate fully for the 40% gap. This is adequate but not excellent.

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 tool's purpose: to record wasted spend and return a waste rate. It uses a specific verb (Record), specifies the resource (agent run spent money), and explains the output (waste rate). It also distinguishes itself by noting that agent waste is invisible to normal monitoring, positioning this as the dedicated ledger. This makes it distinct from siblings like waste_report, even if not explicitly named.

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 examples of when to report ('Report a discarded plan, a wrong target, a retry, or a call that returned nothing usable') and explains why the tool exists (ledger for otherwise invisible waste). It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide. This earns a high score though not a 5 due to lack of exclusions.

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