MCP GitHub CrunchTools
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GITHUB_TOKEN | Yes | GitHub Personal Access Token | |
| GITHUB_API_URL | No | API base URL (set for GHES) | https://api.github.com |
| GITHUB_DEFAULT_ORG | No | Default owner when a tool omits owner |
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": true
} |
| resources | {
"subscribe": false,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_issues_toolB | List issues for a GitHub repository (pull requests excluded). |
| get_issue_toolB | Get a single GitHub issue by number. |
| list_issue_comments_toolA | List the comments on a GitHub issue or pull request conversation, oldest first. Works for plain issues, which list_pull_request_comments_tool does not. On a pull request it returns only the conversation comments; diff comments and reviews come from list_pull_request_comments_tool. |
| create_issue_toolC | Create a new issue in a GitHub repository. |
| create_issue_comment_toolC | Create a comment on a GitHub issue or pull request. |
| update_issue_toolA | Update a GitHub issue, including closing or reopening it. Set state="closed" to close an issue. Set state="open" with state_reason="reopened" to reopen. |
| list_pull_requests_toolC | List pull requests for a GitHub repository. |
| get_pull_request_toolB | Get a single GitHub pull request by number. |
| get_pull_request_diff_toolB | Get the unified diff for a GitHub pull request. |
| get_pull_request_checks_toolA | Get a CI verdict for a PR that distinguishes skipped from failed. Classifies every check-run and commit-status context into passed,
failing, pending, or skipped. SKIPPED checks are NOT failures. Use the
returned |
| update_pull_request_toolA | Update a GitHub pull request, including closing or reopening it. This does NOT merge. Set state="closed" to close a PR without merging. |
| create_pull_request_toolC | Open a GitHub pull request. |
| merge_pull_request_toolA | Merge a GitHub pull request, only once its required checks are green. The tool enforces the base branch's required status checks itself before
merging, because an organization owner's token (or one on a ruleset's
bypass list) lets GitHub merge past failing required checks. It refuses,
naming each offending check, when a required check run or status on the
PR head is missing, pending or failed; when |
| list_pull_request_comments_toolA | List everything said on a GitHub pull request, in one list. Combines the PR's conversation comments (kind "issue_comment"), comments on the diff (kind "review_comment", with path, line, review_id and in_reply_to_id) and submitted reviews (kind "review", with state), oldest first. Every item carries kind, id, author, created_at, body and html_url. Each kind is capped at 300 items; |
| reply_to_review_comment_toolA | Reply in the thread of a pull request review comment.
|
| get_file_content_toolA | Get the decoded text content of a file in a GitHub repository. |
| list_repo_tree_toolC | List the git tree (files and directories) of a GitHub repository. |
| search_code_toolA | Search for code across GitHub. Uses GitHub code search syntax (e.g., "addClass repo:jquery/jquery"). |
| search_issues_toolB | Search for issues and pull requests across GitHub. Uses GitHub issue search syntax (e.g., "is:open is:pr author:octocat"). |
| list_workflow_runs_toolC | List GitHub Actions workflow runs for a repository. |
| trigger_workflow_toolA | Trigger a fresh GitHub Actions run via the workflow_dispatch event. Use this to force a new build. Unlike rerun_workflow_run_tool (which
re-runs an existing run and is rejected by GitHub for runs older than 30
days), this starts a brand-new run regardless of when the workflow last
ran. The target workflow must declare an |
| rerun_workflow_run_toolB | Re-run all jobs in a GitHub Actions workflow run. |
| rerun_failed_jobs_toolB | Re-run only the failed jobs in a GitHub Actions workflow run. |
| get_workflow_run_toolA | Get one GitHub Actions workflow run and its jobs (no logs). |
| get_failed_job_logs_toolA | Get the failure summary of each failed job in a GitHub Actions run. Returns, for every job that failed or timed out, a Logs are fetched for at most 5 failed jobs and all log text together is
capped at 256 KiB; |
| create_release_toolA | Create a GitHub release, creating its tag if the tag does not exist. Publishing a release (draft=false) fires the repository's
|
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 26 tools
Most tools have clearly distinct resource/action targets, and the descriptions specifically clarify tricky adjacent cases such as issue comments versus pull request comments and workflow rerun variants. The main mild overlap is around comment handling across issues and pull requests, but it is not severe enough to cause frequent misselection.
Tool names consistently use snake_case verb_noun phrasing with a uniform _tool suffix, such as list_issues_tool, create_pull_request_tool, and get_failed_job_logs_tool. The pattern is predictable throughout the entire set.
At 26 tools this server is heavy for a single MCP surface and sits at the upper boundary of what is comfortably scannable. The breadth of GitHub operations explains many of the tools, but the set could still benefit from grouping or trimming.
Core issue, pull request, Actions, repository search, and file-reading workflows are covered. However, notable gaps remain around PR review creation/approval, release listing or updates, and branch/commit operations, so agents may hit dead ends in common GitHub workflows.