GitHub MCP
GitHub MCP lets agents work with repositories, issues, pull requests, users, actions, projects, notifications, code security, and other authorized GitHub surfaces.
Verdict
Common use cases
- Check PR review status during standup
- Search issues by label across multiple repos
- Audit recent commits on a release branch
- Pull code snippets into design discussions
- Track sprint velocity from closed issues
Integration
- Vendor
- GitHub MCP
- Category
- other
- Auth
- API_KEY
- Composio slug
github_mcp
Tools
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations tab. 2. Click 'Add Integration', search for GitHub MCP, and select it. 3. You'll be prompted to provide a GitHub personal access token — generate one at github.com/settings/tokens with at least 'repo' scope for private repositories or 'public_repo' for public ones only. 4. Paste the token into Switchy and click 'Connect'. 5. Switchy will verify the token and display which organizations and repositories it can access. 6. To test, create or open a Project, type '@GitHub list open pull requests in owner/repo-name', and send the message. 7. The MCP should return a list of PRs with titles, authors, and status — if it does, you're connected. 8. Adjust token scopes later if you need access to issues, workflows, or additional repositories.
What teammates see: by default, memories from GitHub MCP are scoped to the Project (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
Compatibility data appears once enough Projects have used this MCP together with a given model.
How Switchy teams use it
Starter prompts
List Open PRs
@GitHub list all open pull requests in myorg/myrepo, including author, status, and last updated timestamp
Search Issues by Label
@GitHub search for all open issues labeled 'bug' in myorg/myrepo and summarize the top five by priority
Recent Commits on Branch
@GitHub show the last 10 commits on the 'main' branch of myorg/myrepo with commit messages and authors
PR Review Summary
@GitHub get the review status and all comments for pull request #42 in myorg/myrepo
Repository Activity Report
@GitHub summarize activity in myorg/myrepo over the last 7 days, including new issues, merged PRs, and commit count
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@github list all open pull requests in the main repo that haven't been updated in the last week
Found 4 open pull requests matching your criteria: PR #847 'Refactor authentication flow' (last updated 9 days ago, 2 approvals), PR #831 'Add rate limiting to API endpoints' (last updated 11 days ago, awaiting review), PR #819 'Update dependencies' (last updated 8 days ago, merge conflicts), and PR #802 'Fix memory leak in worker process' (last updated 14 days ago, 1 approval). The authentication refactor and rate limiting PRs appear ready for final review, while the dependencies update needs conflict resolution.
This read operation requires repository access scope in your API key. Response reflects repository state at query time—PR status may change between requests. Useful for identifying stale work during sprint planning or standup prep.
@github create an issue titled 'Investigate slow query performance on user dashboard' and assign it to the backend team label
Created issue #1247 'Investigate slow query performance on user dashboard' in your repository. Applied label 'backend' and set to open status. Issue URL: github.com/your-org/repo/issues/1247. No assignees added yet—you'll need to assign individuals separately or configure team-based auto-assignment in your repository settings.
This write operation creates a permanent record in your repository. Requires issues:write scope. The MCP cannot auto-assign to GitHub teams directly—only individual users. Consider whether your workflow needs manual assignment or CODEOWNERS integration afterward.
@github pull the last 20 commits to main branch and summarize what changed in our API layer
Reviewed 20 commits from the past 6 days. API layer changes: 3 commits added new endpoints for webhook management (commits a4f2e1, b89c03, d12f45), 2 commits refactored error handling to return consistent JSON structures (commits 7e3a92, f04b81), 1 commit increased rate limits for authenticated requests from 1000/hour to 5000/hour (commit c56d29). The webhook endpoints introduce new POST /webhooks/subscribe and DELETE /webhooks/{id} routes. Error refactor affects all 4xx/5xx responses—breaking change for clients parsing old error formats.
This synthesis example combines commit history retrieval with AI reasoning about code changes. Accuracy depends on commit message quality and whether changes are actually in files the MCP can read. Useful for release notes or onboarding, but verify breaking changes manually before communicating to users.
Use-case deep-dives
When GitHub MCP speeds up PR feedback loops
A 5-person engineering team ships 15-20 pull requests a week. The GitHub MCP lets Switchy pull PR diffs, comment threads, and CI status into a single chat context—so the team lead can triage reviews in one pass instead of opening 12 browser tabs. The API key auth means setup takes under two minutes. This works best when your review process is already structured (templates, required checks) and the team uses GitHub's native review features. If your PRs average under 300 lines and you're not doing complex multi-repo dependency checks, this MCP cuts review prep time by half. The buying call: if you spend more than 30 minutes a day context-switching between Slack and GitHub to manage reviews, route that work through Switchy instead.
Using GitHub issues as a lightweight support knowledge base
A 3-person support team at a dev-tools startup uses GitHub issues to track bug reports and feature requests. The GitHub MCP lets Switchy search closed issues by keyword and pull full comment threads—so when a customer asks about a known bug, the support rep gets the engineering context (root cause, workaround, fix timeline) in 10 seconds instead of pinging Slack. This scenario works when your issue volume is under 2,000 open tickets and your engineers write decent issue summaries. If your support load is high enough that you need Zendesk or Intercom, the GitHub MCP becomes a secondary lookup tool, not the primary one. The threshold: if more than 40% of support questions reference past issues, this MCP pays for itself in saved engineer interruptions.
When GitHub MCP clarifies cross-repo blockers
A 6-person product team runs two-week sprints across three repositories. The GitHub MCP pulls issue dependencies, linked PRs, and milestone progress into Switchy—so the PM can build the sprint plan without manually cross-referencing repos in separate tabs. This works when your repos share a consistent labeling scheme (like 'blocked-by' or 'depends-on') and your team actually uses GitHub's issue linking features. If your dependency graph is informal (tracked in Notion or spreadsheets), the MCP can't surface those relationships. The boundary: if you're managing more than 5 repos or your sprints involve external dependencies outside GitHub, you'll need a dedicated project management tool on top of this. For teams under 10 people with tight GitHub hygiene, this MCP turns planning from a 90-minute meeting into a 30-minute async review.
Frequently asked
What does the GitHub MCP do in Switchy?
It connects your GitHub repositories to Switchy's AI workspace so your team can query code, review pull requests, and manage issues without leaving the chat interface. The MCP uses GitHub's API to fetch repository data, meaning you can ask questions about commits, branches, or open PRs and get answers grounded in your actual codebase. It's particularly useful for teams who want AI assistance during code review or sprint planning.
Do I need a GitHub personal access token to set this up?
Yes. The GitHub MCP uses API key authentication, which means you'll generate a personal access token from GitHub's developer settings and paste it into Switchy. You'll need to grant scopes like repo access and possibly admin:org if you want the MCP to read private repositories or organisation-level data. The token belongs to whoever creates it, so use a service account if you want team-wide access that doesn't break when someone leaves.
Can the GitHub MCP create pull requests or merge code?
That depends on the scopes you grant the access token and which tools the MCP exposes. GitHub's API supports write operations like opening PRs, adding comments, and merging branches, but many read-only MCPs deliberately exclude those to avoid accidental changes. Check the MCP's documentation or test it in a non-production repo first. If you need write access, you'll likely need to grant repo or workflow scopes when generating the token.
How is this different from just using GitHub's web interface or CLI?
The GitHub MCP brings repository context into Switchy's shared workspace, so your team can ask natural-language questions about code without switching tabs or running git commands. Instead of manually searching for a commit or reading through issue threads, you ask the AI and it queries GitHub on your behalf. The trade-off is you're limited to what the MCP exposes — if it doesn't surface a specific API endpoint, you'll still need the web interface or CLI for that task.
Who on the team should connect the GitHub MCP?
Whoever has admin access to the repositories you want to query. If you're using a personal access token, that person's GitHub permissions determine what the MCP can see — so a developer with read access to three repos will only expose those three. For broader team use, create a dedicated GitHub service account with the right org-level permissions, generate a token from that account, and connect it in Switchy. This way the integration doesn't break when individuals leave or change roles.