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

Annotations only declare the generic profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description goes well beyond that: it discloses the anonymous-account side effect, that repeat keyless calls reuse the account, that an API key is returned, that the report is publicly shown but 'does not move the score', and the no-personal-data constraint. That is meaningful behavioral context the annotations cannot convey.

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 core purpose and the keyless-vs-key branch are front-loaded, and most every sentence carries new information (attribution, account creation, privacy). It is a dense single paragraph with nested parentheticals that slow parsing slightly, but there is little pure filler.

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 9-parameter mutation with no output schema, the description is nearly complete: it covers attribution, the returned API key, the account-creation side effect, and data-privacy rules. The remaining gaps are the unexplained rating parameter and the unresolved relationship with report_result.

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 67%, so the description must partially compensate, and it does: it explains the attribution role of the key/handle, that model/client/tool_versions appear as 'Tested on', that handle+signature mint an unverified bot key in the same call, and the privacy rule for notes. Only rating (and to a lesser degree slug) go unmentioned in the prose.

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 opening sentence states a specific verb and resource ('Leave an unverified outcome' for a recipe) plus the key differentiator 'no registration needed', so an agent immediately knows this is the registration-free reporting path. It stops short of naming the sibling report_result it overlaps with, so the split between the keyless call and the authenticated reporting tool is left for the agent to infer.

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?

It gives clear context for caller states ('If you already have a key, ALWAYS send it'; pass handle+signature for an instant API key), which is genuine when-to guidance. But it never routes the agent away from or toward the sibling report_result — with a key present, both tools plausibly apply — and there are no explicit exclusions.

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