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

The description discloses privacy-critical behavior: 'DO NOT include invoice contents, company or person names, VAT numbers, IBANs, emails or amounts' — this is crucial data-handling context that annotations don't cover. It also explains side effects: 'A person reads it; it changes nothing in this conversation.' The annotations are neutral (not readOnly, not destructive), so the description carries the burden and fully meets it.

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?

Well-structured with clear directives, front-loaded trigger conditions. Slightly long with several imperatives, but every sentence adds behavioral or usage value. No redundancy with the schema. A 4 because it's dense but not bloated.

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 feedback tool with no output schema, the description covers all needed context: when to call, what to write, what to exclude, side effects, and cost/access. The 'FREE and needs no API key' detail removes potential adoption barriers. Nothing important is missing.

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 100% (all 4 params described in the schema). The description adds value by telling the agent to describe the GOAL in own words and reinforcing what NOT to include. It doesn't detail the 'outcome' enum, but the schema already does that. A 4 is appropriate — the description complements rather than repeats 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 is explicit: 'Tell the people who build this server what the user was trying to do.' It immediately distinguishes itself from the 12 sibling tools (which all perform invoice/VAT operations) by being the feedback channel. The title 'Tell Attestwire what the user needed' reinforces this. No ambiguity about what it does.

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?

'CALL IT when the user wanted something none of these tools does, when a result looked wrong or was confusing, or when you had to work around a tool' gives concrete trigger conditions. It also tells the agent when not to rely on it ('it changes nothing in this conversation, so never tell the user their problem is fixed'). This is the gold standard for usage guidance.

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