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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description goes well beyond them: it discloses the 50-card cap (10 with include_script_text), the truncated/offset/total contract, that counts_by_status covers the whole board rather than the page, that script text is cut to 300 chars, and that stage on files/comments is an immutable snapshot. It also flags the non-obvious data-location fact that rejection reasons live in history[].comment, not comments — exactly the kind of trap an agent would otherwise fall into.

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 dual-mode distinction is front-loaded and the rest follows logically from it, but the description is dense and long, and the pagination/truncation contract is restated from the schema rather than merely referenced. Nearly every sentence carries real information, yet a tighter version could drop the duplicated caps.

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 six-parameter, zero-required, no-output-schema read tool, the description supplies the return shape (card vs board), pagination and truncation behavior, aggregate-field semantics, and the snapshot caveat on stage. Nothing an agent needs in order to call it correctly and interpret the result 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%, so the baseline is 3; the description earns a bump by explaining the interaction between include_script_text and the row cap and by framing offset as the way to resume when truncated=true. Much of the pagination prose duplicates what the schema already says, so it does not reach the top of the scale.

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 names a specific verb+resource (production kanban pipeline read) and explicitly splits the two modes: without script_id it returns a board filtered by status/assignee, with script_id it returns one full card including files, comments, history and allowed_next_statuses. That level of specificity lets an agent distinguish it from pipeline_set_status and other list siblings without opening the schema.

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 explicit workflow guidance: read allowed_next_statuses before calling pipeline_set_status to avoid blind transition attempts, and it states which parameter selects which mode. The only mild gap is that it does not name other retrieval siblings (e.g. shooting_queue_list) as alternatives, but mode selection and ordering are fully specified.

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