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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond that: the department scoping rule, the explicit not-found failure mode for other divisions, and the fact that richer PSA datasets are login-gated and unreachable through this tool. Return-format detail is modest, so not a 5.

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?

A single dense paragraph, but front-loaded with the core purpose and then the enumerated fields, scope, and exclusions. Every clause carries information (field list, division scope, error behavior, access limits); the enumerated return fields are slightly redundant given an output schema exists, which keeps it from a 5.

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?

An output schema exists so return values need not be explained, yet the description still names the fields, and it additionally covers the one realistic failure path (wrong PSA division → not-found) and unavailable login-gated datasets. Nothing an agent needs to call this correctly 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% (one required string param), so the baseline is 3. The description adds meaning the (truncated) schema does not: that the cert number is the numeric value printed on the graded item's label, telling the agent where to source it.

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?

States a specific verb and resource ('PSA's own public Cert Verification record for one certification number') and enumerates the exact fields returned. An agent can immediately distinguish this cert-verification lookup from the sibling CardFacts checklist, Price Guide, and autograph/ticket gallery tools.

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?

Gives clear applicability context: scoped to PSA's trading-card department, and a cert from another division returns a not-found error. It also rules out PSA's Population Report and Auction Prices Realized as unavailable here. It stops short of naming which sibling tool to use instead, so it earns a 4 rather than a 5.

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