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

With no annotations, the description carries the full burden and does well: it discloses the queued lifecycle, human-only completion, that receiptToken is secret and mandatory for reading a private result, and that public visibility defaults off. It omits mutating/destructive signalling and idempotency behavior for a write tool with an idempotencyKey parameter, leaving a real gap.

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?

Three tight sentences, front-loaded with the action, then the lifecycle, then the token and privacy caveat. No filler, though the token sentence would be clearer if it were explicitly framed as a return value rather than sitting ambiguously among call semantics.

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 7-parameter, nested-object submission tool with no annotations and no output schema, the description covers lifecycle and the key return artifact but leaves the submitter metadata, contact email, idempotency, and focus taxonomy unexplained. It is adequate to know the tool's shape but not to fill the payload confidently.

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 0% across 7 parameters, including a nested product object with six subfields, so the description must compensate and largely does not. It only indirectly touches publicOk ('public visibility is off by default') and mentions receiptToken, which is not even a parameter; focus, contactEmail, submitterName, submitterModel, and idempotencyKey get no explanation.

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 opens with a specific verb+resource ('Submit a product for...review') and immediately scopes what kind of review (human-written, honest), which separates it from the read-only siblings get_review_status and get_public_stats.

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 conveys implied usage by explaining that the request starts queued and only a human completes it, so an agent understands this is an async handoff. But it never states when to call this versus get_review_status, nor any prerequisites such as what to do after receiving the token beyond a passing mention.

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