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

Annotations give little signal (all false), so the description carries the load. It discloses side effects (a new list is created if listName doesn't exist), default printId behavior, and the 20-item per call limit. It does not cover possible failure modes or return behavior, but the main side effects are stated.

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 tight and front-loaded; the first sentence states purpose. The only questionable sentence is 'Deckodex Pro.' which adds little to invocation, but overall the text is short and free of redundancy.

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 mutating tool with no output schema, the description leaves a few gaps: it does not say what happens if both listId and listName are omitted (both are optional in the schema), and it does not describe the response shape. It covers the main selection logic but not the complete contract.

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%, and the description fully compensates: it explains listId (from a previous result), listName (reused/created), printId (from get_card with default), and the items limit. Only count is left to the schema, which already documents min/max.

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 opens with a specific verb and resource: 'Add cards to one of the signed-in user's card lists (wishlists, trade binders…)' which makes the tool's purpose unambiguous. It does not explicitly name sibling tools to differentiate, but the 'card lists' concept distinguishes it from collection/deck 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?

It provides concrete guidance on when to use by specifying the target context (signed-in user's card lists) and how to choose a list via listId or listName, including the reuse-or-create behavior. However, it never contrasts it with alternatives like update_collection or save_deck, so an agent must infer when this is the right tool.

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