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

Annotations cover readOnlyHint and openWorldHint, so safety is handled. The description adds genuinely useful behavioral context beyond annotations: the price is a median of at least 5 verified sales in 90 days, sales carry source URLs, and it discloses the full response contents. It stops short of describing pagination or behavior when fewer than 5 sales exist.

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?

Two tight sentences, front-loaded with the payload and ending with accepted input forms. No filler, though the payload list is dense enough to read as a run-on.

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 three-param read tool with no output schema, the description covers what the agent gets back and how prices are derived, which is the key ambiguity. It does not address behavior for cards with fewer than 5 verified sales or pagination of the sale list.

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 descriptions exist for id and query. The description restates the accepted forms and clarifies that query returns the best match when id is unknown, but adds little on max_sales (no mention of the 50/200 default and cap). Baseline 3 fits.

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 ('Full verified data for one card') and enumerates the exact payload: key facts, prices per version/grade, last/record sale, population, and every sale with source URL. This is sharply distinguishable from siblings like search_cards or list_record_sales.

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 explains the three accepted input forms (id, URL, query), which implicitly tells the agent this is the tool for looking up a single known card. However, it does not say when to prefer search_cards over the query path, nor when to use list_record_sales instead of the sales list bundled here.

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