Github List Pr Comments

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about inline comments carrying file/line info, which is behavioral detail beyond the schema. However, it doesn't disclose pagination behavior, default kind, or what the response structure looks like, though the output schema exists. No contradiction with annotations.

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 with no filler, and the key differentiator (inline comments carry file/line) is front-loaded. The description is appropriately sized for the tool's complexity. It could arguably be more explicit about usage, but it earns its place.

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 read-only list tool with an output schema and annotations covering safety, the description is mostly complete. It explains the distinction between comment kinds, which is the main contextual nuance. It doesn't mention pagination defaults or rate limits, but those are minor given the schema and output schema. The sibling list shows related tools, and the description helps distinguish from review-listing tools.

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%, so the description should compensate for undocumented parameters. The description does clarify the meaning of 'inline' vs 'conversation' comments, which adds value beyond the schema's enum. However, it doesn't explain repo_owner, repo_name, pr_number, page, or per_page semantics beyond what the schema already provides. The baseline is 3 given partial coverage, and the description adds some but not full compensation.

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 clearly states the tool lists comments on a pull request, with a specific verb and resource. It distinguishes inline comments from conversation comments by noting inline comments carry file/line context, which helps differentiate from sibling tools like github_list_pr_reviews and github_add_pr_comments. However, it doesn't explicitly name sibling alternatives, so it falls short of a 5.

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 implies usage for reviewing prior comments on a PR ('so a second review can tell what it already said'), which gives some context. It does not explicitly state when to use this vs alternatives like github_list_pr_reviews or github_get_pr_content, nor does it mention exclusions. The kind parameter in the schema adds some guidance, but the description itself lacks explicit routing.

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