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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds a genuinely useful non-obvious behavior: a card's list replaces the list in the conversation once the card sends it to the chat. It does not explain the response shape or how the re-run interacts with the card's stored filters, which caps it at 4.

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?

Only three sentences and the purpose is front-loaded, which is good. But the opening sentence is grammatically tangled ('The list last screened in the card a screen_equities card_ref names, re-run now') and the closing parenthetical quote is overhead that slows parsing.

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 single-parameter read tool with full annotation coverage and no output schema, the definition covers purpose, trigger, and the key side-effect on conversation state. What is missing is what the returned list contains or how it differs from a fresh screen, but that is a modest gap given the tool's simplicity.

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 only documented facts about card_ref are its type and 12-hex pattern. The description does supply provenance — card_ref is the reference produced by screen_equities naming a screener card — which is real added meaning. It still says nothing about how to obtain or validate the ref beyond that, so baseline-plus rather than strong.

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 identifies both the resource (the list screened in a card identified by a screen_equities card_ref) and the action (re-run it now and return it). It names the sibling screen_equities as the origin of the card_ref, which helps separate it from the tool that creates screens. The phrasing is a dense noun phrase rather than a clean verb+resource statement, and requires re-reading, which keeps it below a 5.

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 gives an explicit trigger: 'when the client says they re-screened or asks what the card shows.' That is concrete routing guidance an agent can match against user intent. It does not state when *not* to use it (e.g., for a fresh screen, use screen_equities), so it falls short of a 5.

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