gh-mcp
# 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
Scored across 4 tools
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.
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.
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.
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.