Skip to main content
Glama
aq35
by aq35

GitHub PR Review MCP

プライベートGitHubリポジトリのPull Requestコメントを収集するMCPサーバーです。

できること

  • PRのコメント群を一括収集

    • issueコメント

    • reviewコメント

    • reviewサマリー

  • 未返信のreviewコメントを抽出

Related MCP server: PR Reviews MCP Server

前提

  • Node.js 18+

  • GitHub Personal Access Token

    • プライベートリポジトリを扱うため repo 権限が必要

セットアップ

npm install
npm run build

.env を作成して設定してください(dotenv で自動読み込みされます)。

cp .env.example .env

.env 例:

GITHUB_TOKEN=ghp_xxx
TEST_REPOSITORY=owner/repo
TEST_PULL_NUMBER=123
# TEST_INCLUDE_RESOLVED_REPLIES=true
# GITHUB_API_BASE_URL=https://github.example.com/api/v3

起動

npm start

開発時は以下で直接起動できます。

npm run dev

実動作テスト

このブランチ内だけで動作確認を完結する場合は、.envTEST_REPOSITORYTEST_PULL_NUMBER を設定したうえで、以下を実行してください。

npm run test:collect

引数で明示指定することもできます。

npm run test:collect -- owner/repo 123

第3引数で includeResolvedReplies を指定できます。

npm run test:collect -- owner/repo 123 false

このコマンドはローカルでMCPサーバーを起動し、collect_pr_feedback を実行して結果JSONを表示します。

MCPクライアント設定例

{
  "mcpServers": {
    "github-pr-review": {
      "command": "node",
      "args": ["/absolute/path/to/mcp_tool/dist/index.js"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxx"
      }
    }
  }
}

提供ツール

1) collect_pr_feedback

PRのコメント情報をまとめて取得します。

  • 入力

    • repository: owner/repo

    • pullNumber: PR番号

    • includeResolvedReplies (任意, default: true): 返信コメントを含めるか

  • 出力

    • PRメタ情報

    • issueコメント一覧

    • reviewコメント一覧

    • 未返信reviewコメント一覧

    • review一覧

運用イメージ

  1. collect_pr_feedback で現状コメントを収集

  2. 未返信コメントや修正要望を整理して、ローカルで修正を進める

  3. 修正内容をPRブランチへ修正単位でコミットする

Available Tools

1 tool
collect_pr_feedbackB

Collect PR review comments, issue comments, and review summaries for a PR.

ParametersJSON Schema
NameRequiredDescriptionDefault
pullNumberYesPull request number
repositoryYesGitHub repository in owner/repo format
includeResolvedRepliesNoInclude reply comments in the review comment list

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It only lists what is collected but omits important traits like read-only nature, rate limits, pagination, or data format. The agent has insufficient information to anticipate behavior.

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?

The description is a single concise sentence that front-loads the action and resource. It could be slightly more specific (e.g., mentioning GitHub), but it is efficient with no wasted words.

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?

Given the lack of output schema, the description does hint at the returned data types but does not specify structure, format, or whether the tool is read-only. It is adequate but not comprehensive.

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

Parameters3/5

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

All parameters have schema descriptions with 100% coverage, so the baseline is 3. The main description adds no extra meaning beyond what's in the schema, providing no additional value.

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 clearly states the action ('Collect') and the resource ('PR review comments, issue comments, and review summaries'), making the tool's purpose unambiguous. The repository parameter clarifies the context (GitHub).

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

Usage Guidelines3/5

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

The description does not provide any when-to-use or when-not-to-use guidance, nor does it mention alternatives. Since no sibling tools are listed, the lack of usage guidance is acceptable but still a gap.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev0.1.0
    • First observedcollect_pr_feedback

TDQS

B3.3/5.0
Disambiguation5/5

With only one tool, there is no potential for confusion between tools. The tool's purpose is clearly described.

Naming Consistency5/5

Single tool name follows a consistent verb_noun pattern ('collect_pr_feedback'), so no inconsistency exists.

Tool Count1/5

A single tool for a PR review server is severely inadequate. Expected tools for PR listing, diff viewing, commenting, etc., are missing.

Completeness1/5

The tool surface is extremely incomplete. It only provides feedback collection, with no tools for creating, updating, or managing PRs or reviews.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aq35/mcp_tool'

If you have feedback or need assistance with the MCP directory API, please join our Discord server