Provides tools for creating and editing GitHub issues and pull requests, with safe handling of Markdown body content via temporary files to avoid shell escaping issues.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gh-mcp create an issue in owner/repo titled 'Bug fix' with body 'Fixed typo'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 不要）。
Related MCP server: mcp-gitea
ツール | 引数 | 実行する gh |
|
|
|
|
|
|
|
|
|
|
|
|
読み取り系（gh issue view / gh pr list 等）は body を持たず事故らないため
ラップしない。従来どおり gh を直接呼ぶこと。
返り値: { ok, url, stdout, stderr, exit_code }。url は gh が出力する
作成済み issue/PR の URL（stdout の先頭 http 行）。
uv で依存（fastmcp）を隔離実行する。グローバル Python を汚さない。
claude mcp add gh-mcp -- uv run --project "C:\Users\ynaga\.claude\mcp\gh-mcp" python server.py登録後、claude mcp list で接続を確認できる。
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）。
Add a comment to an issue (or PR). Body is passed via a temp file.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | comment body Markdown. | |
| repo | Yes | ``owner/repo``. | |
| number | Yes | issue or PR number. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses a useful behavioral detail: the body is passed via a temp file, which is not evident from the schema. However, it does not mention other behaviors like authentication, rate limits, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, and the second adds a useful implementation detail. It is front-loaded, concise, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool, the description covers the essential purpose and a key behavioral detail. The output schema exists (though not shown), so return values need not be described. It lacks explicit usage boundaries but is otherwise complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds a note about the body being passed via a temp file but does not enrich the semantics of repo, number, or body beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Add a comment') and target ('to an issue (or PR)'). This specific verb+resource combination distinguishes it from sibling tools like gh_issue_create and gh_issue_edit, which handle creation and editing rather than commenting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—when adding a comment to an issue or PR—but does not explicitly mention alternatives or when not to use it. The naming and sibling list imply differentiation, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GitHub issue. Body is passed via a temp file (no shell quoting).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | issue body Markdown. | |
| repo | Yes | ``owner/repo`` (required; do not rely on gh's default-repo guess). | |
| title | Yes | issue title. | |
| labels | No | optional list of label names. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds a meaningful implementation detail ('Body is passed via a temp file') that helps the agent understand shell quoting is unnecessary. However, it does not mention permissions, side effects, or response behavior, which are relevant for a mutation tool. The added detail is useful but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: the first states the primary action, the second highlights a critical implementation detail. Every word earns its place, and the structure is front-loaded with purpose. No redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the 100% schema coverage, and the presence of an output schema, the description is largely sufficient. It covers the key quirk (temp file) and leaves parameter details to the schema. It does not address usage exclusions or alternative tools, which would push it to 5, but the core information needed to invoke it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's temp-file note adds practical meaning to the 'body' parameter beyond the schema's 'issue body Markdown' — it explains how the value is handled and why shell quoting is not an issue. This enriches parameter understanding, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a GitHub issue' — a specific verb and resource that clearly distinguishes this tool from siblings like gh_issue_comment, gh_issue_edit, and gh_pr_create. The scope is unambiguous and immediately actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this to create a GitHub issue. While no explicit 'when not to use' or alternative tools are named, the verb 'create' and the sibling names make the usage context evident. The schema note about not relying on the default repo adds a practical prerequisite, but this lives in the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Replace an issue's body. Body is passed via a temp file.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | new issue body Markdown (replaces the existing body). | |
| repo | Yes | ``owner/repo``. | |
| number | Yes | issue number. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive 'Replace' behavior and reveals an implementation detail ('Body is passed via a temp file'), which is useful. However, it does not mention permissions, error behavior, or reversibility, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no fluff. Each sentence earns its place: the first states the purpose, the second adds a critical behavioral detail about the temp file. This is an exemplar of minimal effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 3-param tool and the presence of an output schema, the description plus schema is mostly adequate. However, it lacks usage guidance and edge-case context (e.g., behavior for non-existent issues or permission requirements), which prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description adds a small note about the body being passed via a temp file, but this does not significantly enhance understanding beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Replace an issue's body' using a specific verb and resource. It distinguishes this tool from siblings like gh_issue_create, gh_issue_comment, and gh_pr_create by focusing on editing an existing issue's body rather than creating or commenting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention that one should use gh_issue_create for new issues or that this tool only handles body edits, leaving the agent to infer the context from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a pull request. Body is passed via a temp file (no shell quoting).
The current branch must already be pushed to the remote; this wraps
gh pr create only, not the push.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | base branch (e.g. ``master``). | |
| body | Yes | PR body Markdown. | |
| repo | No | optional ``owner/repo``; omit to use the current repo. | |
| draft | No | create as draft when True. | |
| title | Yes | PR title. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It meaningfully reveals that the body is passed via a temp file to avoid shell quoting and that it wraps only `gh pr create`, not the push. This provides useful behavioral context beyond the obvious 'create' action, though it does not mention authentication or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded. The first sentence states the core purpose, and the subsequent sentences add essential context without unnecessary fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and an output schema, so the description appropriately focuses on behavior and prerequisites rather than repeating schema details. It covers the temp-file mechanism and the push requirement. It is largely complete, though it could mention potential error conditions or authentication dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all five parameters, so the baseline is 3. The description adds minimal extra semantics by noting the body is passed via a temp file, which slightly clarifies body handling, but otherwise relies on the schema for parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a pull request,' which is a specific verb with a clear resource. It distinguishes itself from sibling issue-related tools by focusing on pull requests, and the statement 'this wraps ``gh pr create`` only, not the push' further clarifies its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: 'The current branch must already be pushed to the remote' and explicitly states the tool does not perform the push. It implies the user should use this only after pushing, though it does not explicitly name alternatives or when-not-to-use scenarios beyond the push limitation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for siGit (sigit.si): browse repos, search code, manage PRs/issues, web search.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
A MCP server built for developers enabling Git based project management with project and personal…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yukkie/gh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
