get_checklist

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds a real behavioral trait beyond them: the tool verifies the checklist belongs to the supplied card before returning it, implying an ownership mismatch can fail the call. It does not mention pagination behavior despite offset parameters.

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 sentences, zero filler, with the core action and its verification constraint front-loaded before the ID-discovery hint. Every clause carries information.

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?

With an output schema present, return values need no explanation, and annotations cover the read-only/idempotent profile. The description supplies the two operational facts an agent needs (ownership check, where to get IDs); only the cursor/offset continuation model is left unaddressed.

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 only 33% across 6 parameters, so the description must compensate. It explains the card_id/checklist_id relationship (card used for ownership verification), but says nothing about detail, url, text_offsets, or section_offsets, leaving the pagination/cursor semantics entirely to the schema.

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 ("Read a checklist") plus a scope constraint (verifying it belongs to the supplied card), which is far more than a restatement of the name. It also names get_card as the discovery path, which lightly differentiates it from the card-reading siblings, though it does not contrast against any other checklist-reading tool.

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 a clear prerequisite: checklist IDs are found in get_card full detail, so an agent knows it cannot call this cold. It stops short of stating when to prefer this over simply reading the card's full detail, and offers no exclusions or failure conditions.

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