What can you do with this server?

Summary: @sumirati/mcp-github is an MCP server that gives AI agents full GitHub REST API (2022-11-28) access through a 5-tool hybrid surface backed by an on-demand catalog of 83 actions across 13 domains. * Discover actions — github_find_actions searches the 83-action catalog by keyword or domain filter, returning names, domains, mutating flags, and parameter signatures. * Execute any action — github_execute_action runs any catalog action (e.g. create_pull_request, list_issues, trigger_workflow) with validated params, token-projected Markdown/JSON output, and read-only mode blocking mutations. * Read files — get_file_contents fetches Base64-decoded file contents, symbol outlines (outline_only), line ranges, or directory listings at any ref without cloning. * Inspect repositories — get_repository returns metadata, visibility, default branch, HTML URL, stars, forks, and open issue counts. * Review commits — get_commit returns commit metadata, author info, and token-capped unified diffs (with lockfile collapsing). * Manage repositories & branches — search/create repos, create/update/delete files, list/get/create/delete branches, branch protection rules, and fork repositories. * Handle commits & statuses — list commits, atomic multi-file commits via Git Trees API, and read/write commit status checks. * Work with pull requests — full PR lifecycle (create, update, merge), diffs, inline review comments, replies, and formal reviews. * Track issues & labels — list/get/create/update issues, comments, and repository labels. * Manage milestones, collaborators, variables, secrets — milestone tracking, collaborator permissions, Actions variables, and secret metadata. * Use gists, releases, tags — full gist lifecycle, release publishing, and lightweight/annotated tag creation. * Observe CI/CD — list workflows, runs, jobs, and artifacts; extract smart failure logs; trigger, cancel, or rerun workflows. * Access user/org/team data — authenticated user, public profiles, organizations, team creation, accessible repos, and API health/rate-limit diagnostics. * Audit webhooks, topics, and security — repository topics, webhook configuration, and Dependabot vulnerability alerts. * Save tokens by default — Markdown output, conservative pagination (per_page: 10), diff truncation at 400 lines, log tailing, and recursive hypermedia-field stripping yield 91–99% reductions.

Which integrations are available for this server?

Provides tools for interacting with the GitHub REST API, enabling AI agents to manage repositories, files, branches, pull requests, issues, labels, comments, releases, and tags, as well as retrieve user and organization information. Provides tools for interacting with GitHub Actions, enabling AI agents to list and inspect CI/CD workflows, workflow runs, and jobs, fetch job logs, and trigger, cancel, or rerun workflows.

How do I use @sumirati/mcp-github?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@sumirati/mcp-github list open pull requests in sumirati/mcp-github" 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.

@sumirati/mcp-github

by sumirati

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Summary: @sumirati/mcp-github is an MCP server that gives AI agents full GitHub REST API (2022-11-28) access through a 5-tool hybrid surface backed by an on-demand catalog of 83 actions across 13 domains.

Discover actions — github_find_actions searches the 83-action catalog by keyword or domain filter, returning names, domains, mutating flags, and parameter signatures.
Execute any action — github_execute_action runs any catalog action (e.g. create_pull_request, list_issues, trigger_workflow) with validated params, token-projected Markdown/JSON output, and read-only mode blocking mutations.
Read files — get_file_contents fetches Base64-decoded file contents, symbol outlines (outline_only), line ranges, or directory listings at any ref without cloning.
Inspect repositories — get_repository returns metadata, visibility, default branch, HTML URL, stars, forks, and open issue counts.
Review commits — get_commit returns commit metadata, author info, and token-capped unified diffs (with lockfile collapsing).
Manage repositories & branches — search/create repos, create/update/delete files, list/get/create/delete branches, branch protection rules, and fork repositories.
Handle commits & statuses — list commits, atomic multi-file commits via Git Trees API, and read/write commit status checks.
Work with pull requests — full PR lifecycle (create, update, merge), diffs, inline review comments, replies, and formal reviews.
Track issues & labels — list/get/create/update issues, comments, and repository labels.
Manage milestones, collaborators, variables, secrets — milestone tracking, collaborator permissions, Actions variables, and secret metadata.
Use gists, releases, tags — full gist lifecycle, release publishing, and lightweight/annotated tag creation.
Observe CI/CD — list workflows, runs, jobs, and artifacts; extract smart failure logs; trigger, cancel, or rerun workflows.
Access user/org/team data — authenticated user, public profiles, organizations, team creation, accessible repos, and API health/rate-limit diagnostics.
Audit webhooks, topics, and security — repository topics, webhook configuration, and Dependabot vulnerability alerts.
Save tokens by default — Markdown output, conservative pagination (per_page: 10), diff truncation at 400 lines, log tailing, and recursive hypermedia-field stripping yield 91–99% reductions.

GitHub MCP Server (`@sumirati/mcp-github`)

A modern, 2026 AI-native Model Context Protocol (MCP) server for GitHub REST API, engineered for autonomous AI agents and developer workflows.

npm version License: MIT GitHub

What makes v2 Unique: The 2026 5-Tool Hybrid Standard

In early MCP servers, exposing 50–100+ eager tool definitions flooded every LLM turn with thousands of redundant schema tokens ("System Prompt Tax") and degraded reasoning coherence.

@sumirati/mcp-github solves this with a 5-Tool Hybrid Surface:

Glama TDQS Coherence Tier A (5/5): By exposing exactly 5 tools to the client, the server sits in the ideal 3–15 tool coherence sweet spot.
Ultra-Lean System Prompt Tax: Drops schema overhead from 23,112 tokens (92,447 B) down to 1,125 tokens (4,498 B) (95.1% reduction), preserving context windows and maximizing LLM prompt-cache hits.
Zero-Hop Hourly Drivers: The 3 operations developers and agents use constantly (get_file_contents, get_repository, get_commit) remain eager tools for instant zero-hop execution.
100% Platform Access on Demand: The entire platform surface of 83 actions across 13 domains is accessible on-demand via dynamic action discovery (github_find_actions $\rightarrow$ github_execute_action), delivering 91%–99% token savings with default high-density Markdown tables and summaries (format: "markdown" | "json").
Resilient Fallback: If an agent directly invokes any catalog action name (e.g. list_pull_requests), the server dynamically executes it with full input validation and projection.

LLM Prompt Context (5-Tool Hybrid Surface):
├── 1. github_find_actions(query, [domain], [format])     [Meta Discovery]
├── 2. github_execute_action(action, params, [format])   [Meta Dynamic Execution]
├── 3. get_file_contents(owner, repo, path)               [Eager Daily Driver #1]
├── 4. get_repository(owner, repo)                        [Eager Daily Driver #2]
└── 5. get_commit(owner, repo, ref)                       [Eager Daily Driver #3]

Under the hood (Dynamic Registry):
└── 83 Curated Actions across 13 Domains (grounded in GitHub REST API 2022-11-28)

Related MCP server: GitHub Dev Copilot

Core Capabilities Across 13 Domains

Repositories & Branch Governance (repositories, 12 actions): Full repository lifecycle, branch management, branch protection rules (get_branch_protection), file reading (auto Base64-decoded, symbol outlines, line slicing), single-file commits, and forks.
Commits & Commit Statuses (commits, 6 actions): Commit history, token-capped commit diffs (get_commit), atomic multi-file commits via Git Trees API (create_commit, push_files), and commit status checks.
Pull Requests & Code Reviews (pull-requests, 11 actions): PR lifecycle (create, update, merge), review comments, inline diff reviews, and unified diff inspection with lockfile filtering.
Issues & Labels (issues, 8 actions): Issue tracking, upstream indexed filtering, conversation comments, and label management.
Project Milestones (milestones, 4 actions): Milestone creation, progress tracking, and deadline management.
Collaborators & Permissions (collaborators, 4 actions): Audit and manage repository collaborators and permission levels.
Actions Variables & Secrets (variables, 6 actions): Manage repository Actions configuration variables and inspect secret metadata.
Gists & Code Snippets (gists, 5 actions): Full gist lifecycle for sharing multi-file code snippets and configurations.
GitHub Actions & CI/CD (actions, 10 actions): Workflow inspection, workflow runs, job step breakdown, build artifacts (list_workflow_run_artifacts, get_workflow_run_artifact), smart failure log extraction (get_job_logs), run cancel/rerun, and manual workflow dispatch.
Releases & Git Tags (releases, 5 actions): Release publishing, lightweight/annotated tag creation, and release asset inspection.
User, Organizations, Teams & Diagnostics (user, 7 actions): Authenticated user identity, organization inspection, team creation (create_team), accessible repositories, and API health/rate-limit diagnostics (system_health_check).
Webhooks & Repository Topics (webhooks, 4 actions): Audit repository event webhooks and manage repository topic tags.
Security & Dependabot (security, 1 action): Audit Dependabot vulnerability alerts by state and severity.

Quickstart & Installation

Option 1: Run with `npx` (No installation needed)

npx -y @sumirati/mcp-github

Option 2: Install Globally

npm install -g @sumirati/mcp-github
mcp-github

Option 3: Local Clone

git clone https://github.com/sumirati/mcp-github.git
cd mcp-github
npm install
npm test
npm start

Environment Configuration

Variable	Required	Default	Description
`GITHUB_PERSONAL_ACCESS_TOKEN`	Yes	—	GitHub Personal Access Token (classic or fine-grained)
`GITHUB_TOKEN`	No	—	Alternative token variable name
`GITHUB_API_URL`	No	`https://api.github.com`	Base API URL (or GitHub Enterprise Server)
`GITHUB_READ_ONLY`	No	`false`	Enable 3-tier read-only mode (`true`, `1`, `yes`)
`GITHUB_EXPOSE_ALL_TOOLS`	No	`false`	Set to `true` (or `GITHUB_EXPOSE_LEGACY_TOOLS=true`) to expose all 83 tools directly on `ListTools` for legacy clients
`MCP_OUTPUT_FORMAT`	No	`markdown`	Default output format for tool execution (`markdown` or `json`)

Client Configuration

Google Antigravity / Claude Desktop / Cursor

Add to your MCP configuration file (mcp_config.json or claude_desktop_config.json):

Using npm / npx (Recommended):

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@sumirati/mcp-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-github-token>",
        "GITHUB_READ_ONLY": "false"
      }
    }
  }
}

Using local clone:

{
  "mcpServers": {
    "github": {
      "command": "node",
      "args": ["/path/to/mcp-github/index.js"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<your-github-token>",
        "GITHUB_READ_ONLY": "false"
      }
    }
  }
}

Complete Action Catalog Reference (83 Actions)

All 83 actions feature strict Zod input validation and 2-tier output projection:

1. The 5 Client-Exposed Tools (Hybrid Mode)

Tool	Type	Description
`github_find_actions`	Meta	Search and discover available GitHub operations across all 13 domains with compact parameter signatures
`github_execute_action`	Meta	Execute any discovered GitHub platform action with input validation and token-optimized projection
`get_file_contents`	Eager	Read raw file contents (auto Base64 decoded), symbol outlines, line ranges, or directory listings at any ref
`get_repository`	Eager	Retrieve repository metadata, visibility, description, default branch, HTML URL, and counts
`get_commit`	Eager	Inspect Git commit details, author info, and token-capped file diffs

2. Repositories & Branches (`repositories` — 12 actions)

Action	Description	Mutating?
`search_repositories`	Search for repositories across GitHub or within an organization using query qualifiers (e.g. 'org:myorg language:typescript') with capped pagination (max 100). If owner and repository name are known, prefer 'get_repository' for exact O(1) lookup.	No
`get_repository`	Get repository metadata, visibility, description, default branch, clone URL, and statistics for an exact owner/repo. Use when verifying repository settings or checking default branch name.	No
`create_repository`	Create a new GitHub repository under the authenticated user account or a specified organization. Requires write permissions and GITHUB_READ_ONLY=false. Auto-initializes with a default README commit unless auto_init is false.	Yes
`get_file_contents`	Read current file contents, extract symbol outlines ('outline_only: true'), slice line ranges, or list directory entries at a specified git ref. Automatically decodes Base64 into UTF-8. Use 'outline_only: true' first to inspect structure in ~50-100 tokens, then request specific line ranges.	No
`create_or_update_file`	Create a new file or overwrite an existing file on a branch in a single atomic commit. If updating, provide the file's current blob SHA in 'sha' (or leave empty to auto-resolve). Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`delete_file`	Delete an existing file from a branch in a git commit. Requires the current blob SHA to guard against concurrent overwrites. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`list_branches`	List branches in a repository with protection status and head commit SHAs. Supports upstream filtering by protected status and capped pagination (max 100). If branch name is already known, prefer 'get_branch'.	No
`get_branch`	Get detailed status of a specific branch, including branch protection rules and latest commit details. Use to verify branch existence or protection policies before merging or deleting.	No
`get_branch_protection`	Retrieve comprehensive branch protection rules for a specific Git branch, including required status checks, required reviews, admin enforcement, and force-push / deletion restrictions.	No
`create_branch`	Create a new git branch pointing to a commit SHA or branched from an existing branch (defaults to 'main'). Use before committing changes or opening a pull request. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`delete_branch`	Delete a branch from a repository. Protected: explicitly rejects requests to delete the default branch (e.g. 'main') to prevent repository breakage. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`fork_repository`	Fork a repository into the authenticated user's account or a specified organization namespace. Use when contributing to upstream projects where direct push access is restricted. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

3. Git Commits & Statuses (`commits` — 6 actions)

Action	Description	Mutating?
`list_commits`	List repository commit history chronologically with upstream filtering (sha, path, author, since, until) and capped pagination (max 100). For viewing actual line-by-line diffs of a commit, use get_commit instead.	No
`get_commit`	Get detailed commit metadata, file modification statistics, and unified diffs for a specific commit SHA or ref. Use when reviewing code changes in a commit or debugging regressions. Diffs are token-budget optimized and truncated at max_diff_lines (default: 400 lines).	No
`create_commit`	Create an atomic Git commit with multiple created, updated, or deleted files using the GitHub Git Trees API. Use when refactoring, applying multi-file code changes, or updating code and docs together. Avoids multiple individual single-file commits and does not require local git cloning. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`push_files`	Alias for 'create_commit': atomically commit additions, modifications, or deletions to multiple files in a single Git commit via the GitHub Git Database API. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`get_commit_status`	Get the combined status check state (pending, success, failure) and individual check runs for a commit SHA or branch ref.	No
`create_commit_status`	Set or update a commit status check (pending, success, failure, error) on a specific commit SHA. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

4. Pull Requests & Code Reviews (`pull-requests` — 11 actions)

Action	Description	Mutating?
`list_pull_requests`	List and filter pull requests with upstream indexed parameters (state, head, base) and capped pagination (max 100). To inspect a known PR, prefer 'get_pull_request' with pull_number; for diffs, use get_pull_request_diff.	No
`get_pull_request`	Get detailed status of a specific pull request including mergeability (clean, dirty, unstable), head/base branch refs, author, and assignees. Use to check if a PR is ready to merge or blocked. Do NOT use to read code changes; use get_pull_request_diff instead.	No
`get_pull_request_diff`	Retrieve unified git diff for a pull request to review code modifications. Use this tool when analyzing code changes, reviewing patches, or preparing inline comments. Do NOT use for checking PR mergeability or metadata (use get_pull_request instead). Diffs are token-optimized and automatically truncated at max_lines (default: 400 lines) to prevent LLM context overflows.	No
`create_pull_request`	Create a new pull request from a head branch into a base branch. Requires write permissions and GITHUB_READ_ONLY=false. The head branch must already exist and have at least one commit difference from the base branch.	Yes
`update_pull_request`	Update an existing pull request's title, body, open/closed state, or base branch. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`merge_pull_request`	Merge a pull request into its base branch using merge, squash, or rebase method. Requires write/admin permissions and GITHUB_READ_ONLY=false. Ensure the PR mergeable state is clean before merging.	Yes
`list_pull_request_comments`	List inline code review comments anchored to specific diff lines of a pull request. Use when inspecting line-by-line review feedback. For overall PR review approvals or change requests, use list_pull_request_reviews instead.	No
`create_pull_request_comment`	Post an inline review comment anchored to a specific file and line number in the pull request. Requires commit_id, path, and line number in the file. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`create_pull_request_reply`	Reply to an existing pull request review comment thread. Requires comment_id of the parent comment. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`list_pull_request_reviews`	List formal code reviews (approvals, change requests, comment summaries) submitted on a pull request. Use to check reviewer decisions and approval gates before merging.	No
`create_pull_request_review`	Submit a formal code review on a pull request with an approval decision (APPROVE, REQUEST_CHANGES, or COMMENT) and optional summary body or inline comments. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

5. Issues & Labels (`issues` — 8 actions)

Action	Description	Mutating?
`list_issues`	Search and filter repository issue tickets with upstream indexed parameters (state, labels, assignee, creator, mentioned, milestone, since) and capped pagination (max 100). Filters out pull requests. If the issue number is already known, prefer 'get_issue' for exact O(1) lookup.	No
`get_issue`	Get full details of a specific issue ticket, including markdown body, assignees, milestone, state reason, and comment count. Use when investigating a bug report or reading issue specifications.	No
`create_issue`	Create a new issue ticket in a repository with optional labels, assignees, and milestone. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`update_issue`	Update an existing issue's title, body, state ('open'/'closed'), state reason ('completed'/'not_planned'), labels, assignees, or milestone. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`list_issue_comments`	List discussion comments on an issue ticket chronologically. Use to read conversation history, debugging updates, or user feedback on an issue.	No
`create_issue_comment`	Add a markdown comment to an issue ticket. Use to reply to discussions, log progress, or provide resolution details. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`list_labels`	List all labels configured in a repository with their names, descriptions, and hex color codes. Use to discover available tags before creating or updating issues.	No
`create_label`	Create a new label in a repository with a name, description, and 6-character hex color code. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

6. Project Milestones (`milestones` — 4 actions)

Action	Description	Mutating?
`list_milestones`	List project milestones in a repository with open/closed issue counts and due dates. Use to monitor release roadmaps or locate milestone numbers before associating them with issues or PRs.	No
`get_milestone`	Get detailed status of a specific milestone, including title, open/closed issues count, creation date, and deadline. Use when reviewing milestone progress or inspecting milestone deadlines.	No
`create_milestone`	Create a new project milestone with a title, description, and optional due date. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`update_milestone`	Update an existing milestone's title, description, state ('open'/'closed'), or due date. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

7. Collaborators & Roles (`collaborators` — 4 actions)

Action	Description	Mutating?
`list_collaborators`	List collaborators who have access to a repository along with their assigned roles and permissions. Use to audit team access or check user memberships.	No
`get_collaborator_permission`	Check a specific user's exact permission level ('admin', 'maintain', 'write', 'triage', 'read', or 'none') on a repository. Use to verify authorization before attempting privileged operations.	No
`add_collaborator`	Add or invite a GitHub user to collaborate on a repository with a specified permission level. If the user is not an organization member, this sends a collaboration invitation. Requires admin permissions and GITHUB_READ_ONLY=false.	Yes
`remove_collaborator`	Remove a collaborator from a repository, revoking their direct access. Requires admin permissions and GITHUB_READ_ONLY=false.	Yes

8. Actions Variables & Secrets (`variables` — 6 actions)

Action	Description	Mutating?
`list_actions_variables`	List non-sensitive GitHub Actions configuration variables defined on a repository with their values and timestamps. Use for inspecting build environment parameters.	No
`get_actions_variable`	Get the plain text value and last updated timestamp of a specific GitHub Actions repository variable by name.	No
`create_actions_variable`	Create a non-sensitive configuration variable for GitHub Actions workflows. Requires write/admin permissions and GITHUB_READ_ONLY=false. For sensitive credentials, use repository secrets instead.	Yes
`update_actions_variable`	Update the value of an existing non-sensitive GitHub Actions configuration variable. Requires write/admin permissions and GITHUB_READ_ONLY=false.	Yes
`delete_actions_variable`	Delete a non-sensitive configuration variable from GitHub Actions. Requires write/admin permissions and GITHUB_READ_ONLY=false.	Yes
`list_actions_secrets`	List GitHub Actions repository secret names and timestamps. Behavioral safety: secret values are permanently masked by GitHub and never returned in plaintext.	No

9. Gists & Code Snippets (`gists` — 5 actions)

Action	Description	Mutating?
`list_gists`	List code snippets and gists owned by the authenticated user with file summaries. Use to locate code snippet IDs before reading or editing.	No
`get_gist`	Get full source code contents, files, and description of a specific GitHub gist by ID. Use to inspect standalone code snippets or configuration templates.	No
`create_gist`	Create a new public or secret GitHub gist with one or more files. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`update_gist`	Update an existing gist's description or modify/rename/delete individual files within the gist. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`delete_gist`	Permanently delete a gist by its identifier. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

10. GitHub Actions & CI/CD Observability (`actions` — 10 actions)

Action	Description	Mutating?
`list_workflows`	List GitHub Actions CI/CD workflow files configured in a repository (.github/workflows). Use to discover workflow names and IDs before triggering or inspecting runs.	No
`list_workflow_run_artifacts`	List artifacts produced by a specific GitHub Actions workflow run, including file size, download archive URLs, and expiration timestamps. Use to discover generated build outputs, test logs, or release binaries.	No
`get_workflow_run_artifact`	Retrieve metadata and download archive URL for a specific GitHub Actions build artifact by its numeric artifact ID. Use when downloading build deliverables or inspecting individual artifacts.	No
`list_workflow_runs`	List workflow execution runs with status, conclusion ('success', 'failure'), triggering event, and commit SHA. Use to check CI/CD pipeline health or find run IDs.	No
`get_workflow_run`	Get detailed status, timing, and conclusion for a specific workflow execution run. Use when monitoring CI pipeline completion.	No
`list_workflow_run_jobs`	List all individual jobs and step breakdown within a workflow run. Use to identify which specific job or step failed during a build.	No
`get_job_logs`	Fetch plain text execution logs for an Actions job with smart failure extraction and ANSI stripping. Behavioral safety: scans for errors/panics to extract failure blocks and trims massive logs to preserve LLM token context.	No
`trigger_workflow`	Dispatch a workflow run on a branch or tag via workflow_dispatch event with custom inputs. Requires write permissions and GITHUB_READ_ONLY=false. The target workflow file must define a workflow_dispatch trigger.	Yes
`cancel_workflow_run`	Cancel a queued or currently executing GitHub Actions workflow run. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`rerun_workflow`	Re-execute all jobs in a completed or failed GitHub Actions workflow run. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

11. Releases & Git Tags (`releases` — 5 actions)

Action	Description	Mutating?
`list_releases`	List published and draft releases in a repository with release titles, asset download counts, and published dates. Use to check release history or download URLs.	No
`get_release`	Get full details of a specific release by tag name or numeric release ID, including changelog body and asset links.	No
`create_release`	Publish a formal GitHub release for a tag, with title, markdown release notes/changelog, and pre-release/draft flags. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`list_tags`	List git tags in a repository with tag names and commit SHAs. Use to inspect available version tags before publishing a release.	No
`create_tag`	Create a git tag (lightweight reference or annotated tag object when message is provided) pointing to a specific commit SHA. Requires write permissions and GITHUB_READ_ONLY=false.	Yes

12. User, Organizations & Teams (`user` — 7 actions)

Action	Description	Mutating?
`system_health_check`	Perform end-to-end connectivity, latency, rate limit quota, and permission diagnostics against the GitHub API. Verifies token validity, authenticated account details, remaining rate limits, and active read-only policy.	No
`get_authenticated_user`	Retrieve profile metadata (login, name, email, public_repos, followers) for the currently authenticated GitHub token. Use to verify token identity and scope.	No
`get_user`	Retrieve public profile information (login, name, company, bio, public_repos count) for any specified GitHub user by username.	No
`list_user_organizations`	List GitHub organizations that the authenticated user belongs to. Use to discover org namespaces for creating or querying repositories.	No
`get_organization`	Retrieve comprehensive details for a specific GitHub organization (name, description, email, blog, public/private repos). Use when verifying organization access or inspecting org settings.	No
`create_team`	Create a new team in a GitHub organization. Supports parent_team_id to establish nested child teams. Requires organization owner/admin privileges and GITHUB_READ_ONLY=false.	Yes
`list_accessible_repositories`	List repositories accessible to the authenticated user (owned, collaborated on, or member of). Use to discover available repositories across accounts.	No

13. Webhooks & Topics (`webhooks` — 4 actions)

Action	Description	Mutating?
`get_repository_topics`	Get all topic tags associated with a GitHub repository. Use to inspect project categories and discoverability keywords.	No
`set_repository_topics`	Replace all topic tags on a repository with a new array of topic strings. Requires write permissions and GITHUB_READ_ONLY=false.	Yes
`list_repository_webhooks`	List configured event webhooks on a repository with target URLs, active status, and subscribed event triggers.	No
`get_repository_webhook`	Get detailed configuration of a specific repository webhook by ID, including delivery URL and subscribed events.	No

14. Security & Dependabot (`security` — 1 action)

Action	Description	Mutating?
`list_dependabot_alerts`	List Dependabot vulnerability alerts for a repository, including affected package, severity (critical, high, medium, low), and patch advisory.	No

Benchmarks: Reproducible Token Economy Proof (`test/benchmark-test.js`)

Grounded strictly in official GitHub REST API (2022-11-28) response schemas (test/fixtures/github-api-v3-fixtures.js) and verified on every npm test run via node test/benchmark-test.js:

Operation	Raw GitHub API (`2022-11-28`)	Projected JSON (`format: "json"`)	Default Markdown (`format: "markdown"`)	Verified Reduction
System Prompt Tax (83 tools vs 5 hybrid tools)	23,112 tokens (92,447 B)	—	1,125 tokens (4,498 B)	95.1% savings
`get_repository` (1 repository)	1,321 tokens (5,283 B)	104 tokens (414 B)	85 tokens (340 B)	93.6% savings
`list_issues` (10 issues)	15,375 tokens (61,499 B)	1,567 tokens (6,267 B)	313 tokens (1,250 B)	98.0% savings
`list_pull_requests` (10 PRs with `head`/`base` repo)	46,536 tokens (186,141 B)	1,586 tokens (6,341 B)	330 tokens (1,317 B)	99.3% savings
`list_workflow_runs` (10 workflow runs)	14,957 tokens (59,826 B)	839 tokens (3,356 B)	212 tokens (846 B)	98.6% savings
`get_file_contents` (`outline_only: true`)	3,589 tokens (14,355 B)	331 tokens (1,323 B)	314 tokens (1,255 B)	91.3% savings

How Token Compression Works

System Prompt Tax Reduction (95.1% savings): Shrinks MCP ListTools schema footprint from 83 full tool schemas (23,112 tokens / 92,447 B) down to the 5-tool hybrid surface (1,125 tokens / 4,498 B).
Recursive Output Projection Filter (projectOutput): Automatically strips GitHub REST API v3 hypermedia template URLs (*_url RFC 6570 templates), avatar_url, gravatar_id, node_id, site_admin, _links, internal api.github.com self-links, and null/"" fields.
Smart Diff & Lockfile Truncation: Commit and PR diffs automatically collapse dependency lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, go.sum, Cargo.lock, *.min.js) via ignore_lockfiles: true by default. Pass ignore_lockfiles: false to inspect full lockfile diffs.
Conservative Default Pagination: All list actions default to per_page: 10 (max: 100).
Default High-Density Markdown Format: Discovery (github_find_actions), execution (github_execute_action), and all 3 eager tools default to format: "markdown".
Unified Diff Truncation: PR (max_lines) and commit (max_diff_lines) diffs default to 400 lines.
Safe Log Tailing: CI workflow job logs extract the failure block and teardown tail (tail_lines, default: 100) with ANSI escape sequence stripping.

Roadmap

Completed in v2.1

Upstream indexed filtering & strict pagination caps (state, labels, assignee, creator, mentioned, milestone, since)
Client error resilience (Secondary rate limit / abuse detection, 403/404 scope diagnostics, empty-body 201/202 handling)
Hardened output projection with recursion depth guard (maxDepth = 32), RFC 6570 hypermedia URL stripping, and empty collection preservation
Nested child team & organization management (create_team, get_organization)
Smart CI/CD failure log extraction & ANSI sequence stripping in get_job_logs (strip_ansi, smart_failure)
Outline-first code symbol extraction & line range slicing in get_file_contents (outline_only, start_line, end_line)
Atomic multi-file commits (create_commit, push_files) supporting file creation, updates, and deletions via GitHub Git Trees API
Pre-flight mergeability & conflict verification (get_mergeability)
Token scope self-auditing & permission pre-flight

Future Horizons (v2.x)

Standardized collection _summary headers to facilitate multi-turn history pruning in LiteLLM / Eigent agent orchestration
Remote Transports: Streamable SSE and HTTP remote server modes
Scoped GraphQL query engine for relational deep inspections
DevSecOps code scanning & secret scanning alert queries
Scoped & rate-guarded code search within project repositories

Acknowledgements & Lineage

This project incorporates architectural concepts, schemas, and patterns from:

@modelcontextprotocol/sdk (MIT License) — Copyright (c) Anthropic, PBC.
zod (MIT License) — Colin McDonnell.
GitHub REST API Specifications — GitHub, Inc.
jmrplens/gitlab-mcp-server — Dynamic action discovery and meta-dispatcher pattern concepts.
@sumirati/mcp-gitlab — Sibling project architecture, 3-tier read-only mode, and token projection standards.

See NOTICE for complete third-party attribution details.

License

Available Tools

5 tools

get_commitGet CommitA

Read-onlyIdempotent

Get detailed commit metadata, author information, message, and unified git diffs for a specific commit SHA or reference. Eager daily driver tool for reviewing code modifications, patches, or investigating regressions. Output diffs are token-optimized and automatically truncated to max_diff_lines (default: 400 lines).

Name	Required	Description	Default
`ref`	Yes	Commit SHA, branch name, or tag reference to inspect
`path`	No	Optional file path filter: only include diff and stats for this single file
`repo`	Yes	Repository name (e.g. 'Hello-World' or 'mcp-github')
`owner`	Yes	Repository owner (user or organization, e.g. 'octocat' or 'buggycode')
`format`	Yes	Output format: 'markdown' (default) or 'json'	markdown
`max_diff_lines`	Yes	Maximum unified diff lines to return across files to conserve LLM context tokens (default: 400)
`ignore_lockfiles`	Yes	If true, automatically collapses diffs for lockfiles and minified assets (default: true)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive behavior, so safety is covered. The description adds genuinely useful behavioral context beyond that: output diffs are token-optimized and automatically truncated to max_diff_lines (default 400), which warns the agent that results may be incomplete for large commits. It stops short of describing error behavior for invalid refs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the purpose and return contents, followed by the use case and then the truncation caveat. No filler and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description must carry the return-shape burden, and it does: it lists metadata, author info, message, and unified diffs. It is slightly thin on edge cases (e.g., behavior when a ref is invalid or a commit is large beyond truncation), which keeps it from a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including ref, path, max_diff_lines and ignore_lockfiles is already documented in the schema. The description's mention of truncation at max_diff_lines (default 400) restates what the schema property already says, adding little new semantic value. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get detailed commit metadata... unified git diffs for a specific commit SHA or reference') and enumerates exactly what is returned (metadata, author, message, diffs). This is clearly distinguishable from sibling tools get_repository and get_file_contents, which operate on repositories and files rather than commit history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete usage contexts ('reviewing code modifications, patches, or investigating regressions') and signals this is a frequently-used 'daily driver' tool. It does not name alternatives or state when not to use it, so it falls short of the explicit when/when-not/alternatives bar for a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_file_contentsGet File ContentsA

Read-onlyIdempotent

Read current file contents, extract symbol outlines, slice line ranges, or list directory entries from a repository at a specified git ref without cloning. Automatically decodes Base64 file contents into plain text UTF-8. Eager daily driver tool for inspecting source code, configuration files, and directory layouts.

Name	Required	Description
`ref`	No	Git reference (branch name, tag, or commit SHA) to read from (default: default branch / HEAD)
`path`	Yes	Relative path to file or directory in repository (e.g. 'README.md', 'src/index.js', or '' for root)
`repo`	Yes	Repository name (e.g. 'Hello-World' or 'mcp-github')
`owner`	Yes	Repository owner (user or organization, e.g. 'octocat' or 'buggycode')
`end_line`	No	Optional 1-based end line to slice file contents
`start_line`	No	Optional 1-based start line to slice file contents
`outline_only`	Yes	Extract top-level symbol signatures (functions, classes, interfaces, types) with line numbers to conserve tokens (default: false)

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds real value beyond them: no cloning required, automatic Base64-to-UTF-8 decoding, and token conservation via outline mode. It omits error/edge behavior (binary files, missing paths), keeping it at a 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the core capability and followed by behavioral detail and usage context. Dense but not padded; 'Eager daily driver tool' is slightly colloquial but conveys intent efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only, 7-parameter tool with no output schema, the description covers all four operating modes and the key behavioral traits (decoding, no clone, token conservation). The main gap is what the returned content looks like for directory listings versus file reads, but this is minor for a read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description goes further by tying its modes to parameters: symbol outlines map to outline_only, line ranges to start_line/end_line, and directory layouts to path. This semantic linkage helps the agent understand how the parameters combine, though it adds no syntax details beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Read current file contents') and enumerates the four distinct modes (read, outline extraction, line-range slicing, directory listing) plus the git-ref scope. It is easily distinguishable from siblings like get_commit and get_repository, which deal with different resources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear usage context ('Eager daily driver tool for inspecting source code, configuration files, and directory layouts') that tells the agent when this tool is the natural choice. It stops short of naming alternatives or exclusions (e.g., when to prefer get_commit or get_repository instead), so it is clear context rather than explicit routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_repositoryGet RepositoryA

Read-onlyIdempotent

Get comprehensive repository metadata, visibility, description, default branch, HTML URL, star count, fork count, and open issues count for an owner/repo. Eager daily driver tool for verifying repository configuration and existence.

Name	Required	Description	Default
`repo`	Yes	Repository name (e.g. 'Hello-World' or 'mcp-github')
`owner`	Yes	Repository owner (user or organization, e.g. 'octocat' or 'buggycode')
`format`	Yes	Output format: 'markdown' (default) or 'json'	markdown

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the concrete field list, which is helpful, but says nothing about auth requirements, rate limits, or pagination beyond what annotations supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the resource and returned fields followed by a usage hint. Every clause carries information and there is no boilerplate, though the field enumeration is slightly list-like.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully enumerates the returned metadata so an agent knows what it gets back. The safety semantics are fully covered by annotations, leaving only minor gaps around error behavior and rate limits.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so owner, repo, and format are all documented in the schema. The description only restates the 'owner/repo' pair and adds no syntax or format guidance (e.g., the markdown vs json choice), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Get') and resource ('repository') and enumerates the exact metadata returned (visibility, description, default branch, HTML URL, stars, forks, open issues). The sibling tools operate on clearly different resources, but the description never explicitly distinguishes itself from them, keeping it just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Eager daily driver tool for verifying repository configuration and existence' implies when to reach for it, giving useful context. However, there are no explicit exclusions or named alternatives among the siblings (get_file_contents, get_commit, etc.).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

github_execute_actionExecute GitHub ActionA

Execute any supported GitHub action from the 83-action catalog by action name with parameters. Requires the exact action name (discovered via github_find_actions) and its corresponding argument dictionary. Output is automatically compressed with strict token projection filters (stripping hypermedia URL templates, avatar links, empty fields, node_ids) and formatted as compact Markdown by default. Mutating actions are blocked when running in read-only mode (GITHUB_READ_ONLY=true).

Name	Required	Description	Default
`action`	Yes	Exact name of the GitHub action to execute (e.g. 'create_pull_request', 'list_issues', 'trigger_workflow', 'create_branch')
`format`	Yes	Output format: 'markdown' (default, token-optimized compact table/text for LLM) or 'json' (structured JSON)	markdown
`params`	No	Parameters dictionary for the action matching its parameter schema
`parameters`	No	Alias for params (for cross-client compatibility)

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false). The description goes well beyond that by disclosing output post-processing (token projection filters, stripped URL templates/avatars/node_ids, compact Markdown default) and the read-only gating of mutating actions, which annotations do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences, front-loaded with the core verb+resource and the prerequisite before moving to output and gating behavior. Every sentence carries information, though the middle sentence packs many compression details into one run-on clause.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully explains the return format and projection behavior, and it covers the input prerequisite and mutation gating. It omits error/failure behavior and rate-limit or pagination handling, which would be needed for a 5 on a dispatcher of this breadth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents action, format, params, and parameters (including the alias). The description reinforces the exact-name requirement and the params dictionary but adds no format/syntax detail beyond what the schema provides, making the baseline 3 correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Execute) and resource (GitHub action from the 83-action catalog), and notes it is name-driven with parameters. It partially differentiates from siblings by pointing at github_find_actions for name discovery, though it doesn't contrast with the other readers in the sibling set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly states the precondition: the exact action name must first be discovered via github_find_actions, and flags that mutating actions are blocked under GITHUB_READ_ONLY=true. It gives no explicit 'when not to use' guidance or alternative for direct API-style calls, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

github_find_actionsFind GitHub ActionsA

Read-onlyIdempotent

Search and discover available GitHub actions in the 83-action catalog by keyword query or domain filter. Use this discovery tool first whenever you need to perform an action outside the 3 eager daily drivers (e.g. managing PRs, issues, releases, workflows, collaborators, webhooks, variables, security alerts). Returns matching action names, domain categories, mutating flags, descriptions, and parameter signatures so you can construct the call for github_execute_action.

Name	Required	Description	Default
`query`	No	Search keyword query to match against action names, domains, or descriptions (e.g. 'pull request', 'issue comment', 'webhook', 'deploy', 'dependabot')
`domain`	No	Optional domain filter to restrict discovery to a specific functional category
`format`	Yes	Output format: 'markdown' (default, compact human/LLM-readable text table) or 'json' (structured object with parameter schemas)	markdown

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds catalog size (83 actions), the existence of 3 eager daily drivers, and the return payload (names, domains, mutating flags, descriptions, parameter signatures). This is useful behavioral context beyond annotations, though it doesn't cover rate limits or pagination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose, then usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a discovery tool with 100% schema coverage and no output schema, the description covers purpose, usage, and return shape. It could be slightly more complete by explaining how results map to execution parameters, but it's sufficient for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds meaning by mentioning 'keyword query or domain filter' and the return payload, but doesn't add syntax beyond the schema's examples. Slight uplift for clarifying the purpose of query and domain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: 'Search and discover available GitHub actions in the 83-action catalog'. Differentiates from siblings by naming the catalog and indicating it's a discovery tool, while github_execute_action is the execution counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this discovery tool first whenever you need to perform an action outside the 3 eager daily drivers' and lists example domains. Also states the downstream step: construct the call for github_execute_action, and mentions the 3 eager daily drivers as an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

5 tool updatesv2.2.0Oct 17, 2026

Changedget_commit5 fields changed

removedInput schema / properties / file_path

Removed value: -{
-  "description": "Optional file path filter: only include diff and stats for this single file",
-  "type": "string"
-}

addedInput schema / properties / format

Added value: +{
+  "default": "markdown",
+  "description": "Output format: 'markdown' (default) or 'json'",
+  "enum": [
+    "json",
+    "markdown"
+  ],
+  "type": "string"
+}

addedInput schema / properties / ignore_lockfiles

Added value: +{
+  "default": true,
+  "description": "If true, automatically collapses diffs for lockfiles and minified assets (default: true)",
+  "type": "boolean"
+}

addedInput schema / properties / path

Added value: +{
+  "description": "Optional file path filter: only include diff and stats for this single file",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "owner",
-  "repo",
-  "ref",
-  "max_diff_lines"
-]New value: +[
+  "owner",
+  "repo",
+  "ref",
+  "max_diff_lines",
+  "ignore_lockfiles",
+  "format"
+]

Changedget_file_contents4 fields changed

addedInput schema / properties / end_line

Added value: +{
+  "description": "Optional 1-based end line to slice file contents",
+  "type": "number"
+}

addedInput schema / properties / outline_only

Added value: +{
+  "default": false,
+  "description": "Extract top-level symbol signatures (functions, classes, interfaces, types) with line numbers to conserve tokens (default: false)",
+  "type": "boolean"
+}

addedInput schema / properties / start_line

Added value: +{
+  "description": "Optional 1-based start line to slice file contents",
+  "type": "number"
+}

changedInput schema / required

Previous value: -[
-  "owner",
-  "repo",
-  "path"
-]New value: +[
+  "owner",
+  "repo",
+  "path",
+  "outline_only"
+]

Changedget_repository2 fields changed

addedInput schema / properties / format

Added value: +{
+  "default": "markdown",
+  "description": "Output format: 'markdown' (default) or 'json'",
+  "enum": [
+    "json",
+    "markdown"
+  ],
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "owner",
-  "repo"
-]New value: +[
+  "owner",
+  "repo",
+  "format"
+]

Changedgithub_execute_action2 fields changed

changedInput schema / properties / format / default
```
Previous value: -"json"New value: +"markdown"
```

changedInput schema / properties / format / description

Previous value: -"Output format: 'json' (default) or 'markdown' (compact human/LLM-readable text)"New value: +"Output format: 'markdown' (default, token-optimized compact table/text for LLM) or 'json' (structured JSON)"

Changedgithub_find_actions2 fields changed

changedInput schema / properties / format / default
```
Previous value: -"json"New value: +"markdown"
```

changedInput schema / properties / format / description

Previous value: -"Output format: 'json' (default, structured object) or 'markdown' (compact human/LLM-readable text table)"New value: +"Output format: 'markdown' (default, compact human/LLM-readable text table) or 'json' (structured object with parameter schemas)"

45 tool updatesv2.1.0Oct 15, 2026
- Removedcancel_workflow_run
- Removedcreate_branch
- Removedcreate_issue
- Removedcreate_issue_comment
- Removedcreate_label
- Removedcreate_or_update_file
- Removedcreate_pull_request
- Removedcreate_pull_request_comment
- Removedcreate_pull_request_reply
- Removedcreate_release
- Removedcreate_repository
- Removedcreate_tag
- Removeddelete_file
- Removedfork_repository
- Removedget_authenticated_user
- Addedget_commit
- Changedget_file_contents2 fields changed
  - changedInput schema / properties / path / description
```
Previous value: -"Path to the file or directory in repository (e.g. 'README.md' or 'src/index.js')"New value: +"Relative path to file or directory in repository (e.g. 'README.md', 'src/index.js', or '' for root)"
```
  - changedInput schema / properties / ref / description
```
Previous value: -"Branch name, tag, or commit SHA (default: default branch / HEAD)"New value: +"Git reference (branch name, tag, or commit SHA) to read from (default: default branch / HEAD)"
```
- Removedget_issue
- Removedget_job_logs
- Removedget_pull_request
- Removedget_pull_request_diff
- Removedget_release
- Removedget_user
- Removedget_workflow_run
- Addedgithub_execute_action
- Addedgithub_find_actions
- Removedlist_accessible_repositories
- Removedlist_branches
- Removedlist_issue_comments
- Removedlist_issues
- Removedlist_labels
- Removedlist_pull_request_comments
- Removedlist_pull_requests
- Removedlist_releases
- Removedlist_tags
- Removedlist_user_organizations
- Removedlist_workflow_run_jobs
- Removedlist_workflow_runs
- Removedlist_workflows
- Removedmerge_pull_request
- Removedrerun_workflow
- Removedsearch_repositories
- Removedtrigger_workflow
- Removedupdate_issue
- Removedupdate_pull_request
43 tool updatesv1.0.0Oct 15, 2026
- First observedcancel_workflow_run
- First observedcreate_branch
- First observedcreate_issue
- First observedcreate_issue_comment
- First observedcreate_label
- First observedcreate_or_update_file
- First observedcreate_pull_request
- First observedcreate_pull_request_comment
- First observedcreate_pull_request_reply
- First observedcreate_release
- First observedcreate_repository
- First observedcreate_tag
- First observeddelete_file
- First observedfork_repository
- First observedget_authenticated_user
- First observedget_file_contents
- First observedget_issue
- First observedget_job_logs
- First observedget_pull_request
- First observedget_pull_request_diff
- First observedget_release
- First observedget_repository
- First observedget_user
- First observedget_workflow_run
- First observedlist_accessible_repositories
- First observedlist_branches
- First observedlist_issue_comments
- First observedlist_issues
- First observedlist_labels
- First observedlist_pull_request_comments
- First observedlist_pull_requests
- First observedlist_releases
- First observedlist_tags
- First observedlist_user_organizations
- First observedlist_workflow_run_jobs
- First observedlist_workflow_runs
- First observedlist_workflows
- First observedmerge_pull_request
- First observedrerun_workflow
- First observedsearch_repositories
- First observedtrigger_workflow
- First observedupdate_issue
- First observedupdate_pull_request

Deploy Server

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

TDQS

A3.9/5.0

Scored 2026-10-17 08:00 across 5 tools

Disambiguation4/5

The three eager tools (get_repository, get_file_contents, get_commit) each target a distinct resource, and the find/execute pair has a clear discover-then-run relationship. Minor overlap exists because repo/file/commit reads are also reachable through github_execute_action, but the descriptions clearly frame the get_ tools as fast-path shortcuts.

Naming Consistency4/5

Two coherent families exist: snake_case get_noun for the eager daily drivers and github_verb_noun for the catalog tools, each internally consistent. The split prefix conventions are a minor deviation but deliberate and readable.

Tool Count4/5

Five visible tools is lean, but the find/execute meta-tools compress an 83-action surface into two entries, which is efficient rather than thin. The design is well-scoped, though direct-operation coverage is intentionally minimal.

Completeness4/5

The 83-action catalog spans PRs, issues, releases, workflows, collaborators, webhooks, variables, and security alerts, giving broad lifecycle coverage through github_execute_action. The eager tools alone lack full CRUD, but agents can work around this via the catalog.

Maintenance

ActivityNo data

ResponsivenessSyncing

Resources

Related MCP Connectors

smithery-ai-github
ai.smithery
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Version Control Developer Tools CI/CD & DevOps
295
https://server.smithery.ai/@smithery-ai/github/mcp
Robinson MCP for GitHub
com.robinsonaisystems
Operate GitHub from your AI assistant: repos, PRs, issues, Actions. Previews and read-only mode.
Version Control Developer Tools CI/CD & DevOps
1
https://github.robinsonaisystems.com/api/mcp
Github A
io.github.pipeworx-io
GitHub MCP — wraps the GitHub public REST API (no auth required for public endpoints)
Version Control Developer Tools Project Management
532
https://gateway.pipeworx.io/github/mcp
GitHub Copilot Tools
io.github.faizu526
GitHub Copilot MCP: code, repo, PR, workflow tools for AI assistants.
Version Control Developer Tools CI/CD & DevOps
1
https://abstracts-reggae-campus-endorsed.trycloudflare.com/mcp/mcp

Related MCP Servers

GitHub MCP Server
Version Control Developer Tools
pipseedai
A
license
A
quality
Not graded
maintenance
Enables AI agents to interact with GitHub repositories through the GitHub REST API for managing files, issues, and repository metadata. It supports both read operations like searching code and write operations such as creating repositories and updating issue comments.
Updated 9 months ago (2026-02-06 10:47 UTC)
9
-
GitHub Dev Copilot
Version Control Developer Tools
yashwant-kumar08
F
license
Not graded
quality
C
maintenance
Enables AI agents to interact with GitHub via MCP, managing repositories, issues, PRs, and analyzing repository health through tools like list_repositories, read_issues, create_issue, comment_on_pr, and analyze_repo_health.
Updated 3 months ago (2026-08-17 16:38 UTC)
-
github-repos
Version Control Developer Tools Code Analysis
VishalBasker
F
license
Not graded
quality
C
maintenance
Enables read-only browsing and querying of GitHub repositories, including listing repos, reading files, fetching READMEs, searching code, and viewing commit history via MCP.
Updated 2 months ago (2026-08-25 07:01 UTC)
-
github-mcp-server
Version Control Project Management Developer Tools
shubham055555
F
license
Not graded
quality
B
maintenance
Enables AI agents to interact with GitHub repositories and issues through MCP tools, supporting listing repositories, listing and searching issues, and retrieving specific issues via the GitHub REST API.
Updated 2 months ago (2026-09-02 07:22 UTC)
-

GitHub MCP Server (@sumirati/mcp-github)

What makes v2 Unique: The 2026 5-Tool Hybrid Standard

Core Capabilities Across 13 Domains

Quickstart & Installation

Option 1: Run with npx (No installation needed)

Option 2: Install Globally

Option 3: Local Clone

Environment Configuration

Client Configuration

Google Antigravity / Claude Desktop / Cursor

Using npm / npx (Recommended):

Using local clone:

Complete Action Catalog Reference (83 Actions)

1. The 5 Client-Exposed Tools (Hybrid Mode)

2. Repositories & Branches (repositories — 12 actions)

3. Git Commits & Statuses (commits — 6 actions)

4. Pull Requests & Code Reviews (pull-requests — 11 actions)

5. Issues & Labels (issues — 8 actions)

6. Project Milestones (milestones — 4 actions)

7. Collaborators & Roles (collaborators — 4 actions)

8. Actions Variables & Secrets (variables — 6 actions)

9. Gists & Code Snippets (gists — 5 actions)

10. GitHub Actions & CI/CD Observability (actions — 10 actions)

11. Releases & Git Tags (releases — 5 actions)

12. User, Organizations & Teams (user — 7 actions)

13. Webhooks & Topics (webhooks — 4 actions)

14. Security & Dependabot (security — 1 action)

Benchmarks: Reproducible Token Economy Proof (test/benchmark-test.js)

How Token Compression Works

Roadmap

Completed in v2.1

Future Horizons (v2.x)

Acknowledgements & Lineage

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

GitHub MCP Server (`@sumirati/mcp-github`)

Option 1: Run with `npx` (No installation needed)

2. Repositories & Branches (`repositories` — 12 actions)

3. Git Commits & Statuses (`commits` — 6 actions)

4. Pull Requests & Code Reviews (`pull-requests` — 11 actions)

5. Issues & Labels (`issues` — 8 actions)

6. Project Milestones (`milestones` — 4 actions)

7. Collaborators & Roles (`collaborators` — 4 actions)

8. Actions Variables & Secrets (`variables` — 6 actions)

9. Gists & Code Snippets (`gists` — 5 actions)

10. GitHub Actions & CI/CD Observability (`actions` — 10 actions)

11. Releases & Git Tags (`releases` — 5 actions)

12. User, Organizations & Teams (`user` — 7 actions)

13. Webhooks & Topics (`webhooks` — 4 actions)

14. Security & Dependabot (`security` — 1 action)

Benchmarks: Reproducible Token Economy Proof (`test/benchmark-test.js`)