MCP GitHub CrunchTools

Reply To Review Comment Tool

reply_to_review_comment_tool

Reply in the thread of a pull request review comment.

Instructions

Reply in the thread of a pull request review comment.

comment_id is the id of a "review_comment" item from list_pull_request_comments_tool whose in_reply_to_id is empty; GitHub rejects a reply to a reply, so answer the comment that started the thread.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "repo": "<repo>",
      "pull_number": "<pull_number>",
      "comment_id": "<comment_id>",
      "body": "<body>"
    },
    "name": "reply_to_review_comment_tool"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	Reply body (Markdown)
`repo`	Yes	Repository name
`owner`	No	Repository owner (defaults to GITHUB_DEFAULT_ORG if unset)
`comment_id`	Yes	ID of the review comment to reply to
`pull_number`	Yes	Pull request number

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.2.0Oct 14, 2026

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the 'no reply-to-reply' rejection behavior, but says nothing about authentication/scope requirements, rate limits, or what happens on success (partially covered by the output schema). Disclosed behavior is genuine but narrow.

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

Conciseness5/5

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

Two sentences, zero filler, and the thread-reply constraint is front-loaded before the operand detail. Every clause earns its place.

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

Completeness3/5

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

For a mutation tool with no annotations, the description covers the critical input constraint and the return shape is handled by the output schema. It still leaves permission/scope requirements and failure modes other than the reply-to-reply rejection unstated.

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?

Schema coverage is 100%, so the baseline is 3, and the description genuinely adds meaning beyond the schema by defining what comment_id must be (a thread-starting review_comment from list_pull_request_comments_tool). It does not, however, clarify owner/repo resolution or body formatting beyond the schema's own 'Markdown' note.

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?

The description states a specific verb and resource ('Reply in the thread of a pull request review comment') and explicitly names the sibling tool that supplies the required id (list_pull_request_comments_tool), so the agent can distinguish this from generic comment-creation siblings without opening any schema.

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?

It gives a concrete selection rule: comment_id must come from a review_comment item whose in_reply_to_id is empty, and explains why (GitHub rejects a reply to a reply). That is strong context, though it never contrasts this tool against other comment-writing siblings like create_issue_comment_tool.

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