List merge request reactions

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, covering the safety profile. The description adds useful context about targeting individual notes via note_id, but doesn't mention pagination or return structure, which is only partially compensated by the output schema.

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 a single, front-loaded sentence with 13 words. It conveys the action, resource, and a key optional scope (notes) without redundancy. Ideal conciseness.

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 and annotations covering the safety profile, the description sufficiently scopes the operation to MR or note reactions. It explains the required context and the optional note_id use case, making it complete for invocation, though a mention of pagination would slightly improve completeness.

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 descriptions cover only project and merge_request_iid (40%). The tool description clarifies note_id's role by mentioning 'or one of its notes', but page and per_page are not elaborated beyond their names and constraints. The description partially compensates for the low coverage but leaves pagination semantics underspecified.

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 uses a specific verb 'List' and resource 'emoji reactions on a GitLab merge request or one of its notes', clearly defining its scope. It distinguishes itself from sibling tools that add/remove reactions and from issue-specific reactions.

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 clearly indicates when to use the tool—to retrieve reactions on an MR or a note—and the resource scope is explicit. However, it doesn't name any alternative tools or explicitly state exclusions, though alternatives are implied by sibling names.

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