get_issue

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

No annotations are provided, so the description carries the full burden. It usefully discloses the returned content, but it does not state that this is a read-only operation, nor does it explain the auth requirement beyond the siteApiToken parameter name, leaving the safety/mutation profile unstated.

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?

A single front-loaded sentence with the verb first and the return payload enumerated. Every clause earns its place with no filler.

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?

There is no output schema, so describing the returned fields is valuable and partially complete. However, with no annotations and 0% parameter coverage, gaps remain around auth/scoping and parameter meaning.

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% for both parameters, so the description would need to compensate. It says nothing about what groupId identifies or what siteApiToken is for, leaving both parameters entirely undocumented.

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 clear verb+resource ('Get full detail for a single issue group') and enumerates what detail is returned (stack trace, user events log, network context, console tail). It implicitly distinguishes itself from the sibling list_issues by emphasizing 'single issue group,' though it never names that sibling explicitly.

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?

Usage is implied: an agent calling with a groupId wants the full detail of one issue rather than a list. But there is no explicit when-to-use, no stated prerequisite (e.g., needing a groupId from list_issues first), and no exclusion against alternatives.

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