github-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_PORT | No | Port for the streamable HTTP transport when MCP_TRANSPORT=http. Example: 3102. | |
| MCP_TRANSPORT | No | Transport mode: 'stdio' (default) or 'http'. | stdio |
| GITHUB_PERSONAL_ACCESS_TOKEN | Yes | A fine-grained PAT with permissions: Issues r/w, Pull requests r/w, Contents r, Checks r, Metadata r (auto-granted). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_meA | Get the authenticated GitHub user (login, name, profile URL). |
| list_issuesB | List issues in a repository. |
| search_issuesA | Search issues and pull requests with GitHub search syntax. |
| get_issueA | Get a single issue with its body and (optionally) its comments. |
| create_issueC | Create an issue. |
| update_issueA | Update an issue's title, body, or state. Title/body replace in full. |
| add_issue_commentB | Comment on an issue. Also works on pull requests. |
| list_pull_requestsB | List pull requests in a repository. |
| get_pull_requestA | Get a pull request with its changed files and CI check summary. Files are capped at the first 100; files_truncated is true when the PR has more. Checks summarize GitHub Actions runs on the head commit. |
| create_pull_requestC | Create a pull request. |
| add_pr_commentA | Comment on a pull request (general conversation, not a code review). |
| search_repositoriesA | Search repositories, sorted by popularity (stars) descending. Use this to explore existing repos and projects, e.g. find the most starred implementations of a tool or library. |
| get_repoA | Get a repository's summary card (stars, forks, language, topics). Use with search_repositories to evaluate repos found by popularity. |
| get_file_contentsA | Get the raw text contents of a file in a repository. Files larger than 100,000 characters are refused to protect the context window; fetch a narrower path instead. |
| search_codeB | Search code with GitHub code search syntax. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Each tool targets a distinct resource and action: issues, PRs, repos, code, file contents, and user info. Search tools are clearly separated by domain (issues, repos, code), and comment tools are distinct for issues vs PRs. No meaningful overlap.
All names follow a consistent verb_noun snake_case pattern (get_, list_, create_, update_, add_, search_). Even edge cases like 'get_me' and 'get_file_contents' fit the pattern, with no mixing of camelCase or other styles.
15 tools is at the upper boundary of the ideal range but each one earns its place. The set covers core GitHub workflows without unnecessary redundancy, and the count is well-proportioned to the server's scope.
Issue management is complete (list, get, create, update, comment, search). PR management covers list, get, create, and comment, but lacks update and merge operations, which are common lifecycle actions. Repo exploration is solid with get/search, and code/file retrieval is covered. Minor gaps exist, but agents can work around them.