Skip to main content
Glama
saidsef

GitHub PR Issue Analyser

by saidsef
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Github Add Inline Pr Comment

github_add_inline_pr_comment

Adds inline review comments to specific lines or line ranges in a pull request diff, ensuring comments attach to changed or context lines GitHub accepts.

Instructions

Adds an inline review comment to a line, or to a range of lines, in a file within a PR. The line must fall inside the PR's diff hunks: GitHub rejects a comment on an unchanged line outside any hunk, and on a path not in the diff. A deleted line exists only on side LEFT. Pass head_sha from github_get_pr_content as expected_head_sha, so line numbers taken from that diff apply to that commit. See #517.

Workflow and conventions: github_get_skill('pr-review').

Input Schema

NameRequiredDescriptionDefault
lineYes
pathYes
sideNoLEFT for a line the PR deletes, RIGHT for one it adds or leaves as contextRIGHT
pr_numberYes
repo_nameYes
repo_ownerYes
start_lineNoFirst line of a range ending at line. Omit to comment on line alone
start_sideNoSide start_line sits on. Omit to match side
comment_bodyYes
expected_head_shaNoAttach the comment to this SHA, as github_get_pr_content reports it. Omit for the current head

Output Schema

NameRequiredDescriptionDefault
idYes
bodyYes
authorYes
html_urlYes
created_atYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv54.0.0
    • addedInput schema / properties / expected_head_sha
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Attach the comment to this SHA, as github_get_pr_content reports it. Omit for the current head"
+}
  2. Addedv42.0.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare it is a non-readonly, open-world, non-idempotent, non-destructive write, and the description adds the important extra context of GitHub's server-side rejection rules for lines and paths outside the diff. It also explains the SHA anchoring behavior, though it does not say what happens on retry (e.g. whether a duplicate comment is created), which matters given idempotentHint=false.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then constraints, then workflow pointer; almost every sentence carries information. The trailing 'See #517.' is an opaque issue reference that adds little for an agent and could be dropped.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with an output schema and partial param documentation, the description covers the hard constraints an agent would otherwise get wrong (hunk containment, side semantics, SHA pinning) plus a skill pointer for conventions. Only duplicate/retry behavior and error responses are left unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 40% schema coverage across 10 params, the description usefully compensates: it clarifies that a deleted line exists only on LEFT, that `line` must fall in a diff hunk, that the path must appear in the diff, and that `head_sha` from github_get_pr_content maps to expected_head_sha. repo_owner/repo_name/pr_number/comment_body remain self-evident, so remaining gaps are minor.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Adds an inline review comment to a line, or to a range of lines, in a file within a PR'), which cleanly separates it from github_add_pr_comments and github_reply_to_review_comment. An agent knows immediately this is the line-anchored review comment tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete preconditions rather than just context: the line must be inside a diff hunk, the path must be in the diff, deleted lines need side LEFT, and head_sha should come from github_get_pr_content as expected_head_sha. It does not name the alternatives (e.g. github_add_pr_comments for non-inline comments, github_reply_to_review_comment for threads), so routing is only partly covered.

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

Deploy Server

Other Tools