list_issue_note_emoji_reactions

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

The annotations already supply readOnlyHint=true and openWorldHint=true, and the description reinforces them by explicitly stating the tool 'does not mutate GitLab data.' It also goes beyond the annotations to disclose error semantics — missing resources, invalid identifiers, insufficient permission, and rate limits are returned as errors. This meaningfully exceeds what the structured fields convey.

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 core purpose is front-loaded in the first clause, but the remainder is one dense run-on paragraph blending several distinct ideas: discussion_id usage, collection-vs-single guidance, read-only safety, error behavior, and parameter-format boilerplate. It earns its sentences, but the tail end ('use required identifiers and pagination fields exactly as documented') reads as low-value filler that adds length without actionable content.

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 moderate-complexity tool with 100% schema coverage and no output schema, the description covers the essentials: purpose, read-only safety, error/rate-limit behavior, and the key conditional (discussion_id for replies). The only meaningful gap is that no return shape or count is mentioned, but per the rubric the absence of an output schema puts the description in a stronger position and it largely delivers what's needed to call the tool correctly.

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 schema documents all four parameters and the description doesn't have to carry that burden. The description's parameter-related additions are thin and partially circular — 'provide the numeric ID or complete URL-encoded path described by the schema' mostly restates the project_id schema description, and the instruction to 'use required identifiers and pagination fields exactly as documented' is boilerplate that references pagination params that don't exist in this 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?

'List all emoji reactions on an issue note' clearly states a specific verb and resource, correctly scoped to issue notes versus the many issue/merge-request emoji siblings. The scope is precise enough that an agent can disambiguate it from list_issue_emoji_reactions, list_merge_request_note_emoji_reactions, and the create/delete variants, even though no sibling is explicitly named.

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?

Provides genuine usage context: 'Pass discussion_id for discussion thread replies' is a concrete conditional, and the collection-vs-single-resource contrast ('choose the corresponding get tool') offers some routing guidance. However, the alternative is generic ('the corresponding get tool') rather than naming a specific sibling, and there is no when-not-to-use or prerequisite guidance such as confirming the note exists first.

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