git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/github-mcp-server" ~/.claude/skills/majiayu000-claude-skill-registry-github-mcp-server && rm -rf "$T"
skills/data/github-mcp-server/SKILL.mdGitHub MCP Server Documentation
This file contains comprehensive documentation about the GitHub MCP (Model Context Protocol) server, including available tools and configuration options.
Note: This file is automatically generated and updated by the
github-mcp-tools-report.md workflow. Manual edits may be overwritten.
Last Updated: [To be filled by workflow]
Overview
The GitHub MCP server provides AI agents with programmatic access to GitHub's API through the Model Context Protocol. It supports two modes of operation:
Local Mode (Docker-based)
- Runs as a Docker container on the GitHub Actions runner
- Uses
environment variable for authenticationGITHUB_PERSONAL_ACCESS_TOKEN - Configurable toolsets via
environment variableGITHUB_TOOLSETS - Supports read-only mode via
environment variableGITHUB_READ_ONLY
Remote Mode (Hosted)
- Connects to hosted GitHub MCP server at
https://api.githubcopilot.com/mcp/ - Uses Bearer token authentication in HTTP headers
- Supports read-only mode via
headerX-MCP-Readonly - No Docker container required
Configuration
Basic Configuration
Local Mode (Docker):
tools: github: mode: "local" toolsets: [default] # or [repos, issues, pull_requests]
Remote Mode (Hosted):
tools: github: mode: "remote" toolsets: [default] # or [repos, issues, pull_requests]
Read-Only Mode
To restrict the GitHub MCP server to read-only operations:
tools: github: mode: "remote" read-only: true toolsets: [repos, issues]
Custom Authentication
Use a custom GitHub token instead of the default:
tools: github: mode: "remote" github-token: "${{ secrets.CUSTOM_GITHUB_PAT }}" toolsets: [repos, issues]
Available Toolsets
The GitHub MCP server organizes tools into logical toolsets. You can enable specific toolsets, use
[default] for the recommended defaults, or use [all] to enable everything.
:::note[Why Use Toolsets?] The
allowed: pattern for listing individual GitHub tools is not recommended for new workflows. Individual tool names may change between GitHub MCP server versions, but toolsets provide a stable API. Always use toolsets: instead. See Migration from Allowed to Toolsets for guidance on updating existing workflows.
:::
:::tip[Best Practice]
Always use
for GitHub tools. Toolsets provide:toolsets:
- Stability: Tool names may change between MCP server versions, but toolsets remain stable
- Better organization: Clear groupings of related functionality
- Complete functionality: Get all related tools automatically
- Reduced verbosity: Cleaner configuration
- Future-proof: New tools are automatically included as they're added :::
Recommended Default Toolsets
The following toolsets are enabled by default when
toolsets: is not specified:
- User and environment context (strongly recommended)context
- Repository managementrepos
- Issue managementissues
- Pull request operationspull_requests
Note: The
users toolset is not included by default and must be explicitly specified if needed.
All Available Toolsets
| Toolset | Description | Common Tools |
|---|---|---|
| User and environment context | , |
| Repository management | , , , |
| Issue management | , , , |
| Pull request operations | , , |
| GitHub Actions/CI/CD | , , |
| Code scanning and security | , |
| Dependency management | Dependabot alerts and updates |
| GitHub Discussions | , |
| Experimental features | Unstable/preview APIs |
| Gist operations | , |
| Label management | , , |
| Notifications | , |
| Organization management | , |
| GitHub Projects | Project board operations |
| Secret scanning | Secret detection and management |
| Security advisories | Advisory creation and management |
| Repository stars | Star-related operations |
| User profiles | , , |
| Advanced search | Search across repos, code, users |
Available Tools by Toolset
This section maps individual tools to their respective toolsets to help with migration from
allowed: to toolsets:.
Context Toolset
- List teams the user belongs toget_teams
- List members of a specific teamget_team_members
Repos Toolset
- Get repository informationget_repository
- Read file contents from repositoryget_file_contents
- Search code across repositoriessearch_code
- List commits in a repositorylist_commits
- Get details of a specific commitget_commit
- Get the latest releaseget_latest_release
- List all releaseslist_releases
Issues Toolset
- Read issue detailsissue_read
- List issues in a repositorylist_issues
- Create a new issuecreate_issue
- Update an existing issueupdate_issue
- Search issues across repositoriessearch_issues
- Add reaction to an issue or commentadd_reaction
- Add a comment to an issuecreate_issue_comment
Pull Requests Toolset
- Read pull request detailspull_request_read
- List pull requests in a repositorylist_pull_requests
- Get details of a specific pull requestget_pull_request
- Create a new pull requestcreate_pull_request
- Search pull requests across repositoriessearch_pull_requests
Actions Toolset
- List GitHub Actions workflowslist_workflows
- List workflow runslist_workflow_runs
- Get details of a specific workflow runget_workflow_run
- Download workflow artifactsdownload_workflow_run_artifact
Code Security Toolset
- List code scanning alertslist_code_scanning_alerts
- Get details of a specific alertget_code_scanning_alert
- Create a code scanning alertcreate_code_scanning_alert
Discussions Toolset
- List discussions in a repositorylist_discussions
- Create a new discussioncreate_discussion
Labels Toolset
- Get label detailsget_label
- List labels in a repositorylist_labels
- Create a new labelcreate_label
Users Toolset
- Get current authenticated user informationget_me
- Get user profile informationget_user
- List userslist_users
Notifications Toolset
- List user notificationslist_notifications
- Mark notifications as readmark_notifications_read
Organizations Toolset
- Get organization detailsget_organization
- List organizationslist_organizations
Gists Toolset
- Create a new gistcreate_gist
- List user's gistslist_gists
Authentication Details
Remote Mode Authentication
The remote mode uses Bearer token authentication:
Headers:
- Required for authenticationAuthorization: Bearer <token>
- Optional, enables read-only modeX-MCP-Readonly: true
Token Source:
- Default:
or${{ secrets.GH_AW_GITHUB_TOKEN }}${{ secrets.GITHUB_TOKEN }} - Custom: Configure via
fieldgithub-token
Local Mode Authentication
The local mode uses environment variables:
Environment Variables:
- Required for authenticationGITHUB_PERSONAL_ACCESS_TOKEN
- Optional, enables read-only modeGITHUB_READ_ONLY=1
- Optional, specifies enabled toolsetsGITHUB_TOOLSETS=<comma-separated-list>
Best Practices
Toolset Selection
- Start with defaults: For most workflows, the recommended default toolsets provide sufficient functionality
- Enable specific toolsets: Only enable additional toolsets when you need their specific functionality
- Security consideration: Be mindful of write operations - consider using read-only mode when possible
- Performance: Using fewer toolsets reduces initialization time and memory usage
Token Permissions
Ensure your GitHub token has appropriate permissions for the toolsets you're enabling:
toolsets: Requires repository read/write permissionsrepos
toolsets: Requires issues read/write permissionsissues
toolsets: Requires pull requests read/write permissionspull_requests
toolsets: Requires actions read/write permissionsactions
toolsets: Requires discussions read/write permissionsdiscussions
Remote vs Local Mode
Use Remote Mode when:
- You want faster initialization (no Docker container to start)
- You're running in a GitHub Actions environment with internet access
- You want to use the latest version without specifying Docker image tags
Use Local Mode when:
- You need a specific version of the MCP server
- You want to use custom arguments
- You're running in an environment without internet access
- You want to test with a local build of the MCP server
Migration from Allowed to Toolsets
If you have existing workflows using the
allowed: pattern, we recommend migrating to toolsets: for better maintainability and stability. Individual tool names may change between MCP server versions, but toolsets provide a stable API that won't break your workflows.
Migration Examples
Using
(not recommended):allowed:
tools: github: allowed: - get_repository - get_file_contents - list_commits - list_issues - create_issue - update_issue
Using
(recommended):toolsets:
tools: github: toolsets: [repos, issues]
Tool-to-Toolset Mapping
Use this table to identify which toolset contains the tools you need:
Tools | Migrate to |
|---|---|
| |
, | |
, , , | |
, , , , | |
, , | |
, , | |
, | |
, | |
, , | |
, | |
| Mixed repos/issues/PRs tools | |
| All tools | |
Quick Migration Steps
- Identify tools in use: Review your current
listallowed: - Map to toolsets: Use the table above to find corresponding toolsets
- Replace configuration: Change
toallowed:toolsets: - Test: Run
to verify tools are availablegh aw mcp inspect <workflow> - Compile: Run
to update the lock filegh aw compile
Using Allowed Pattern with Custom MCP Servers
:::note[When to Use Allowed] The
allowed: pattern is appropriate for:
- Custom MCP servers (non-GitHub)
- Gradual migration of existing workflows
- Fine-grained restriction of specific tools within a toolset
For GitHub tools, always use
toolsets: instead of allowed:.
:::
The
allowed: field can still be used to restrict tools for custom MCP servers:
mcp-servers: notion: container: "mcp/notion" allowed: ["search_pages", "get_page"] # Fine for custom MCP servers
For GitHub tools,
allowed: can be combined with toolsets: to further restrict access, but this pattern is not recommended for new workflows.
Troubleshooting
Common Issues
Issue: Tool not found or not available
- Solution: Check if you're using
to restrict tools. Consider usingallowed:
instead to get all related tools.toolsets: - Verify: Run
to see which tools are actually available.gh aw mcp inspect <workflow-name>
Issue: Missing functionality after specifying toolset
- Cause: Using a too-narrow toolset that doesn't include all needed tools
- Solution: Either add additional toolsets (e.g.,
) or usetoolsets: [default, actions]
for full access[all]
Issue: Workflow using
allowed: list is verbose and hard to maintain
- Solution: Migrate to
configuration using the migration guide abovetoolsets:
Best Practices for Debugging
- Start with
toolset: Most workflows work well with default toolsets[default] - Add specific toolsets as needed: Incrementally add toolsets like
,actions
, etc.discussions - Use
: Verify which tools are actually availablegh aw mcp inspect - Check tool-to-toolset mapping: Reference the tables above to find the right toolset