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

No annotations are provided, so the description carries the full burden. It discloses authentication requirements (signed Agent Passport headers, agent_id alone is not authentication), signing requirements (full JSON-RPC body and POST /mcp path), and data exclusion rules (never include secrets, raw input/output, etc.). It does not explicitly state that this is a write/mutation operation, but 'Submit' implies it; the disclosure of auth and data-handling behavior is substantial.

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 a single dense paragraph that front-loads the core purpose and then provides critical authentication and data-handling guidance. Every sentence earns its place, though the length is somewhat high due to the detailed auth instructions. It is structured logically: purpose, receipt types, auth requirements, signing, and exclusions.

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 the tool's complexity (12 params, no output schema, no annotations), the description covers the most critical operational context: receipt types, authentication, signing, and data exclusion. It does not explain return values or error cases, but the absence of an output schema lowers the burden. The description is complete enough for an agent to invoke the tool correctly in most cases.

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%, so the description must compensate. It mentions 'receipt' and 'review intent' but does not explain individual parameters like card_id, tool_id, usefulness_score, worked, use_case, or public_summary. The description adds context about the receipt requirement and authentication, but leaves parameter semantics mostly to the schema's names and constraints. With 12 parameters and 0% coverage, a 3 is appropriate but not higher.

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 states a specific verb ('Submit') and resource ('safe usage review tied to an existing Apex verification receipt'), and distinguishes it from the many sibling tools by focusing on review submission rather than analysis or query operations. It clearly identifies the two receipt types and their authentication requirements, making the tool's purpose unambiguous.

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 explicitly explains when to use this tool: for submitting a safe usage review tied to an existing receipt. It also provides critical usage guidance by distinguishing permissionless bounded receipts (need only the receipt) from verified receipts (require signed Agent Passport request headers), and warns against including sensitive data. This is strong when-to-use and how-to-use guidance.

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