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

It discloses the operation's duration ('~5 min'), delivery channel ('result by email + status page'), and key authorization rule ('delivery email must match the purchase email'). It also notes this consumes one prepaid ping, consistent with idempotentHint=false. These details add substantial context beyond the annotations, which only indicate read/write and idempotency hints.

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 front-loaded with the main action and quick-check behavior. The later clauses about purchase requirements and the fallback endpoint are useful, though the pricing detail ('100 pings S$150, 90d') and link are slightly more than strictly necessary. Overall it is compact and each sentence earns its place.

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 tool with three scalar parameters and no output schema, the description completely covers how to call it, what preconditions must hold, what to do if no pack exists, and where results arrive. Since the result is delivered by email and status page rather than via a direct response, this adequately substitutes for an output schema.

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?

The input schema already covers all three parameters with 100% description coverage, including pack_id format ('pp_xxx') and target semantics ('UEN or entity name to check'). The description reinforces email matching and pack possession but does not materially extend parameter meaning beyond the schema, so the baseline of 3 is appropriate.

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 begins with a specific verb and resource: 'Run one prepaid registry ping.' The title 'Redeem a ping-pack check' further clarifies the operation. It does not explicitly distinguish itself from sibling audit tools, but the registry-ping concept and pack-based redemption are distinct enough that an agent can tell the intent.

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 states explicit preconditions: a pack_id is required, the delivery email must match the purchase email, and possession of pack_id authorizes the redeem. It also gives a clear fallback for when the agent lacks a pack: 'POST /api/brief/ping-pack first,' with a pricing link. This is strong when-to-use guidance and leaves little to inference.

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