Skip to main content
Glama
README.md
# gh-mcp

`gh`(GitHub CLI)の **body を持つ操作だけ**を薄くラップする stdio MCP サーバ。

## なぜ

issue / PR の長文 Markdown body をシェル経由で `gh` に渡すと、PowerShell の
here-string(`@'...'@`)・stop-parsing トークン(`--%`)・クォートエスケープで
繰り返し事故る。このサーバは body を **JSON 引数**で受け取り、一時ファイルに書いて
`gh ... --body-file <tmp>` を `shell=False` で実行する。シェルが body 文字列を
一切見ないので、事故が構造的に消える。

公式 GitHub MCP(HTTP)が接続不安定なための代替でもある。認証は既存の
`gh auth` ログインをそのまま使う(**PAT 不要**)。

## 提供ツール(事故が多い body 持ち系のみ)

| ツール | 引数 | 実行する gh |
|---|---|---|
| `gh_issue_create` | `repo, title, body, labels?` | `gh issue create --repo R --title T --body-file <tmp> [--label ...]` |
| `gh_issue_comment` | `repo, number, body` | `gh issue comment N --repo R --body-file <tmp>` |
| `gh_issue_edit` | `repo, number, body` | `gh issue edit N --repo R --body-file <tmp>` |
| `gh_pr_create` | `base, title, body, repo?, draft?` | `gh pr create --base B --title T --body-file <tmp> [--repo R] [--draft]` |

読み取り系(`gh issue view` / `gh pr list` 等)は body を持たず事故らないため
**ラップしない**。従来どおり `gh` を直接呼ぶこと。

返り値: `{ ok, url, stdout, stderr, exit_code }`。`url` は gh が出力する
作成済み issue/PR の URL(stdout の先頭 http 行)。

## 登録

`uv` で依存(fastmcp)を隔離実行する。グローバル Python を汚さない。

```bash
claude mcp add gh-mcp -- uv run --project "C:\Users\ynaga\.claude\mcp\gh-mcp" python server.py
```

登録後、`claude mcp list` で接続を確認できる。

## 動作確認(手動)

```bash
uv run --project "C:\Users\ynaga\.claude\mcp\gh-mcp" python -c "import server; print([t for t in dir(server) if t.startswith('gh_')])"
```

## 前提

- `gh` 2.x がインストール済みで `gh auth status` が通っていること。
- `gh` は PATH から解決。見つからなければ `C:\Program Files\GitHub CLI\gh.exe` に
  フォールバックする(`server.py` の `_resolve_gh`)。

TDQS

A3.9/5.0

Scored across 4 tools

Disambiguation5/5

Each tool targets a distinct resource-action pair: create issue, comment on issue/PR, edit issue body, create PR. No two tools overlap in purpose, making selection unambiguous.

Naming Consistency5/5

All tools follow the consistent `gh_<resource>_<action>` pattern (gh_issue_create, gh_issue_comment, gh_issue_edit, gh_pr_create), making the function of each tool predictable.

Tool Count5/5

The four tools form a focused, well-scoped set for GitHub issue and PR creation and editing. The count is within the ideal 3-15 range and each tool earns its place.

Completeness2/5

The set lacks read operations (list/get issues or PRs) and PR lifecycle management (merge, close). An agent cannot discover existing resources or manage them beyond creation and editing, leaving significant functional gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues