Provides full read/write access to the GitHub REST API, enabling actions like creating issues, commenting, merging pull requests, managing files, branches, releases, labels, and workflows.
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., "@personal-github-mcp List my open pull requests across all repos"
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.
A minimal, personal MCP server that gives Claude (via Claude Code or Claude Desktop) full read/write access to the GitHub REST API, using your own Personal Access Token (PAT) — no third-party app permissions, no 403s from a shared connector's scopes.
It exposes one tool, github_request, that can call any GitHub REST
API endpoint with any HTTP method (GET, POST, PATCH, PUT, DELETE).
That covers everything: creating issues, commenting, merging PRs, creating/
updating files, branches, releases, labels, workflows — the full API at
https://docs.github.com/en/rest.
Go to https://github.com/settings/tokens?type=beta (fine-grained token, recommended) or https://github.com/settings/tokens (classic).
Fine-grained token: scope it to your account, pick "Only select repositories" (or all, if you want), and under Repository permissions grant at least:
Contents: Read and write
Issues: Read and write
Pull requests: Read and write
Metadata: Read-only (required)
Classic token: just check the repo scope.
Copy the token — you won't see it again.
Related MCP server: Git Workflow Automation MCP Server
cd github-mcp-server
npm installAdd to your Claude Code MCP config (~/.claude.json or via claude mcp add):
claude mcp add personal-github -- node /absolute/path/to/github-mcp-server/index.jsThen set the token as an environment variable before launching, or add it
directly to the config's env block:
{
"mcpServers": {
"personal-github": {
"command": "node",
"args": ["/absolute/path/to/github-mcp-server/index.js"],
"env": {
"GITHUB_TOKEN": "ghp_your_token_here"
}
}
}
}Edit your claude_desktop_config.json (Settings → Developer → Edit Config)
and add the same mcpServers block as above, then restart Claude Desktop.
Once connected, ask Claude things like:
"Create an issue in neural-shubh/dark-fleet-detection titled X with body Y"
"List my open pull requests across all repos"
"Update the README.md in neural-shubh/mediscan-ai"
Claude will call github_request with the right method/path/body — e.g.
POST /repos/neural-shubh/dark-fleet-detection/issues with
{"title": "...", "body": "..."}.
The token lives only in your local MCP config / environment — it's never
sent anywhere except api.github.com.
Scope the token as narrowly as you're comfortable with (fine-grained, select repos only) since this server will honor whatever the token allows.
This server does not implement any allow/deny tool policy of its own — the token's scopes are the only guardrail. If you want to restrict it further (e.g. read-only, or single-repo-only) that's easy to add — just ask.
Make an authenticated request to any GitHub REST API v3 endpoint (read or write). Use this for everything: listing/creating/updating repos, issues, pull requests, comments, files (create_or_update via PUT /repos/{owner}/{repo}/contents/{path}), branches, releases, labels, workflows, etc. Full API reference: https://docs.github.com/en/rest. Path must start with '/' and be relative to https://api.github.com (e.g. '/repos/OWNER/REPO/issues'). For GET requests with query params, either append them to path as a query string or pass query. For write requests (POST/PATCH/PUT/DELETE), pass a JSON-serializable object as body.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Optional JSON request body, used for POST/PATCH/PUT requests. | |
| path | Yes | API path relative to https://api.github.com, starting with '/'. Example: '/repos/neural-shubh/dark-fleet-detection/issues' | |
| query | No | Optional query string parameters as key/value pairs. | |
| method | Yes | HTTP method to use. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It covers authentication ('authenticated request'), read/write capability, path format requirements, query param placement, and body requirements for write requests. However, it does not mention rate limits, error responses, or pagination behavior, which would be valuable for such a generic API client.
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 six sentences long, each earning its place: purpose, use cases, API reference link, path rule, query handling, and body handling. It is front-loaded with the core purpose and avoids fluff, making it highly scannable.
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 is complex (generic REST client) with no output schema or annotations. The description comprehensively covers path construction, query/body usage, and links to full API docs. However, it omits explicit description of the return format (likely the GitHub API response) and error behavior, though these are inferable from the API reference link and the tool's nature.
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%, but the description adds contextual meaning: it gives a concrete path example, explains the choice between appending query params to the path vs using the query object, and clarifies that body must be a JSON-serializable object. This enriches the schema descriptions without redundancy.
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 function: 'Make an authenticated request to any GitHub REST API v3 endpoint (read or write).' It also enumerates specific use cases (repos, issues, PRs, etc.), making the scope unmistakable. This is a specific verb+resource description that fully distinguishes the tool's generic nature.
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 explicitly instructs 'Use this for everything: listing/creating/updating repos, issues, pull requests, comments, files...' and provides practical guidance on constructing paths, handling query parameters, and passing body payloads. Since there are no sibling tools, it clearly positions this as the universal GitHub API access tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0github_requestWith only one tool, there is no possibility of confusion between different tools. The tool's purpose as a generic GitHub API request handler is clear and unambiguous.
The single tool name 'github_request' directly describes its function. Since there is only one tool, there is no inconsistent naming pattern to evaluate.
A single tool is on the lower end of the spectrum and feels thin for a GitHub MCP server. However, the tool is powerful and comprehensive, so it is not trivial, but it places a heavy burden on the agent to know the API specifics.
The tool claims to cover any GitHub REST API endpoint, making it functionally complete for the domain. It supports all HTTP verbs and includes query parameters and body handling, so no obvious operations are missing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Manage repositories, users, releases, and automate GitHub workflows
Access the GitHub API, enabling file operations, repository management, search functionality, and…
GitHub MCP — wraps the GitHub public REST API (no auth required for public endpoints)
GitHub Private MCP Pack — access private repos, org data via OAuth.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/neural-shubh/personal-github-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server