GitHub
Code hosting, issues, pull requests, and CI state.
Verdict
Common use cases
- Create feature branches from chat during planning
- Triage new issues by adding labels and assignees
- Review open PRs and request changes inline
- Check CI workflow status before merging
- Add collaborators to repos without leaving Slack
Integration
- Vendor
- GitHub
- Category
- developer-tools
- Auth
- OAUTH2
- Tools
- 50
- Composio slug
github
Tools
- Accept a repository invitation
Accepts a pending repository invitation that has been issued to the authenticated user.
- Add app access restrictions
Replaces github app access restrictions for an existing protected branch; requires a json array of app slugs in the request body, where apps must be installed and have 'contents' write permissions.
- Add a repository collaborator
Adds a github user as a repository collaborator, or updates their permission if already a collaborator; `permission` applies to organization-owned repositories (personal ones default to 'push' and ignore this field), and an invitation may b
- Add a repository to an app installation
Adds a repository to a github app installation, granting the app access; requires authenticated user to have admin rights for the repository and access to the installation.
- Add a selected repository to a user secret
Grants a specified repository access to an authenticated user's existing codespaces secret, enabling codespaces created for that repository to use the secret.
- Add assignees to an issue
Adds or removes assignees for a github issue; changes are silently ignored if the authenticated user lacks push access to the repository.
- Add email for auth user
Adds one or more email addresses (which will be initially unverified) to the authenticated user's github account; use this to associate new emails, noting an email verified for another account will error, while an existing email for the cur
- Add labels to an issue
Adds labels (provided in the request body) to a repository issue; labels that do not already exist are created.
- Add org runner labels
Adds new custom labels to an existing self-hosted runner for an organization; existing labels are not removed, and duplicates are not added.
- Add or update team membership for a user
Adds a github user to a team or updates their role (member or maintainer), inviting them to the organization if not already a member; idempotent, returning current details if no change is made.
- Add or update team project permissions
Grants or updates a team's permissions ('read', 'write', or 'admin') for a specific project, which must exist within the specified organization and be linked to it.
- Add or update team repository permissions
Sets or updates a team's permission level for a repository within an organization; the team must be a member of the organization.
- Add project collaborator
Adds a specified github user as a collaborator to an existing organization project with a given permission level.
- Add repo to org secret with selected access
Adds a repository to an existing organization-level github actions secret that is configured for 'selected' repository access.
- Add runner labels
Adds and appends custom labels to a self-hosted repository runner, which must be registered and active.
- Add selected repository to an organization secret
Adds a repository to an organization secret's access list when the secret's visibility is 'selected'; this operation is idempotent.
- Add selected repository to an organization variable
Grants a repository access to an organization-level github actions variable, if that variable's visibility is set to 'selected repositories'.
- Add selected repo to org secret
Grants an existing repository access to an existing organization-level dependabot secret; the repository must belong to the organization, and the call succeeds without change if access already exists.
- Add social accounts for the authenticated user
Adds one or more social media links (which must be valid, full urls for platforms supported by github) to the authenticated user's public github profile.
- Add status check contexts
Adds status check contexts (provided in the request body, e.g., `{"contexts": ["new-context"]}`) to a protected branch, requiring these contexts to have been previously reported.
- Add team access restrictions
Overwrites the list of teams (and their child teams) granted push access to a protected branch; the list of team slugs must be provided in the http post request body.
- Add user access restrictions
Sets/replaces list of users allowed to push to a protected branch; usernames (e.g., `["user1"]`) must be a json array in request body (not schema parameters), an empty array `[]` removes all restrictions.
- Add users to codespaces access for an organization
Sets or replaces the list of organization members granted codespaces access billed to the organization; ensure the organization's billing settings allow access for selected members.
- Approve a workflow run for a fork pull request
Approves a workflow run from a forked repository's pull request; call this when such a run requires manual approval due to workflow configuration.
- Assign an organization role to a team
Assigns an existing organization-level role (identified by `role id`) to a team (identified by `team slug`) within a github organization (`org`), provided the organization, team, and role already exist.
- Assign an organization role to a user
Assigns a specific organization role to a user who is a member or an outside collaborator in a github organization, using a valid role id.
- Authuserdockerconflictpackageslist
Lists docker packages for the authenticated user that encountered conflicts during the docker migration process.
- Block a user
Blocks an existing individual github user (not an organization or your own account), preventing them from interacting with your account and repositories.
- Block a user from an organization
Blocks an existing github user from an existing organization, preventing their contributions, collaboration, and forking of the organization's repositories.
- Cancel a GitHub Pages deployment
Cancels an existing, ongoing or queued github pages deployment for a repository using its `pages deployment id`.
- Cancel a workflow run
Cancels a workflow run in a github repository if it is in a cancellable state (e.g., 'in progress' or 'queued').
- Check a token
Checks if a github app or oauth access token is valid for the specified client id and retrieves its details, typically to verify its active status and grants.
- Check if a gist is starred
Checks if a gist, identified by `gist id`, is starred by the authenticated user, returning an empty response (204) if starred, or a 404 error if not starred or not found.
- Check if a user can be assigned
Verifies if a github user can be assigned to issues in a repository; assignability is confirmed by an http 204 (no content) response, resulting in an empty 'data' field in the response.
- Check if a user can be assigned to an issue
Checks if a specified github user can be assigned to a given issue within a repository.
- Check if a user follows another user
Checks if a github user `username` follows `target user`; returns a 204 http status if true, 404 if not or if users are invalid.
- Check if a user is a repository collaborator
Checks if a user is a collaborator on a specified github repository, returning a 204 status if they are, or a 404 status if they are not or if the repository/user does not exist.
- Check if a user is blocked by an organization
Checks if a github user is blocked by an organization; a successful response (204 no content) indicates the user is blocked, while a 404 not found error indicates the user is not blocked.
- Check if a user is blocked by the authenticated user
Checks if the specified github user is blocked by the authenticated user; a 204 no content response indicates the user is blocked, while a 404 not found indicates they are not.
- Check if person is followed by authenticated user
Checks if the authenticated github user follows a target github user; an http 204 status indicates the user is followed, while an http 404 status indicates the user is not followed or the target user does not exist.
- Check if pull request merged
Checks if a specified github pull request has been merged, indicated by a 204 http status (merged) or 404 (not merged/found).
- Check if repo starred by auth user
Use to determine if the authenticated user has starred a specific github repository, which is confirmed by an http 204 status (resulting in an empty dictionary in the response data); the action fails (e.g., http 404) if the repository is no
- Check private vulnerability reporting status
Checks if private vulnerability reporting is enabled for the specified repository.
- Check team permissions for a project
Checks if a team has 'read', 'write', or 'admin' permissions for an organization's specific classic project, returning the project's details if access is confirmed.
- Check team permissions for a repository
Checks a team's permissions for a specific repository within an organization, including permissions inherited from parent teams.
- Clear repository cache by key
Deletes github actions caches from a repository matching a specific `key` and an optional git `ref`, used to manage storage or clear outdated/corrupted caches; the action succeeds even if no matching caches are found to delete.
- Clear self-hosted runner org labels
Removes all custom labels from a self-hosted runner for an organization; default labels (e.g., 'self-hosted', 'linux', 'x64') will remain.
- List repositories starred by the authenticated user
Deprecated: lists repositories starred by the authenticated user, including star creation timestamps; use 'list repositories starred by the authenticated user' instead.
- List stargazers
Deprecated: lists users who have starred a repository; use `list stargazers` instead.
- Star a repository for the authenticated user
Deprecated: stars a repository for the authenticated user; use `star a repository for the authenticated user` instead.
Setup
Setup guide
- 11. In Switchy, open your workspace settings and navigate to the Integrations tab. 2. Click 'Add Integration', search for GitHub, and select it from the list. 3. Click 'Connect to GitHub' to start the OAuth flow in a new browser tab. 4. GitHub will ask you to authorize Switchy — review the requested scopes (repo, workflow, user, admin:org) and click 'Authorize'. 5. If you belong to organizations, choose which ones to grant access to, then confirm. 6. You'll return to Switchy with a success message; the GitHub MCP now appears in your integrations list. 7. Open any Space, type '@GitHub list my repositories', and send — you should see a list of repos you own or collaborate on. 8. If the response is empty or you see an auth error, revisit Integrations and click 'Reconnect' to refresh your token.
What teammates see: by default, memories from GitHub are scoped to the Space (PROJECT visibility) - you can mark any memory PRIVATE or share it ORG-wide.
Works well with
Top models
How Switchy teams use it
Starter prompts
List Open Pull Requests
@GitHub list all open pull requests in the repository my-org/api-server and include the author and status checks for eachOpen in a Space →
Create a Feature Branch
@GitHub create a new branch called feature/user-authentication in the repository my-org/web-app based on the main branchOpen in a Space →
Triage an Issue
@GitHub add the labels 'bug' and 'high-priority' to issue #42 in my-org/mobile-app and assign it to @janeOpen in a Space →
Check Workflow Status
@GitHub show me the status of the most recent workflow run for the main branch in my-org/backend-serviceOpen in a Space →
Add a Collaborator
@GitHub add the user contractor-username as a collaborator with push permission to the repository my-org/docs-siteOpen in a Space →
Example outputs
Illustrative - representative of the model's voice and quality, not literal recordings.
@github list all open pull requests in our main repo that have been waiting for review longer than 3 days
Found 4 open pull requests awaiting review for over 3 days in your-org/main-repo: 1. PR #847: "Refactor authentication flow" (opened 5 days ago, requested reviewers: @alice, @bob) 2. PR #839: "Add rate limiting to API endpoints" (opened 6 days ago, no reviewers assigned) 3. PR #831: "Update dependencies" (opened 8 days ago, requested reviewers: @charlie) 4. PR #824: "Fix memory leak in worker process" (opened 11 days ago, draft status) This is an illustrative example showing how the MCP would surface stale PRs by combining repository query capabilities with date filtering.
This example uses GitHub's pull request listing and filtering tools. Requires 'repo' OAuth scope for private repositories. The MCP can read PR metadata (status, reviewers, dates) but cannot determine why reviews are delayed—you'll need to check individual PR discussions for context.
@github create a new issue in the backend repo titled 'Investigate slow query performance' and assign it to the database team label
Created issue #1247 in your-org/backend-repo: Title: "Investigate slow query performance" Status: Open Labels: database-team Assignees: None (label applied, but no users auto-assigned) URL: https://github.com/your-org/backend-repo/issues/1247 The issue is now visible to your team. You can add assignees, milestones, or additional labels through follow-up prompts or directly in GitHub. This illustrative example shows the MCP creating an issue and applying labels in a single action.
This example demonstrates issue creation and label assignment. Requires 'repo' OAuth scope with write access. The MCP creates labels if they don't exist, but cannot auto-assign users to issues—you must explicitly add assignees in a separate step or mention them in the issue body.
@github summarize the last 15 commits to the main branch and draft a changelog entry for our next release
Analyzed 15 commits to main branch (Dec 10-18, 2024). Key changes: **Features:** - Added webhook retry logic with exponential backoff (#891) - Implemented user preference caching layer (#887) **Fixes:** - Resolved race condition in session cleanup (#894) - Fixed incorrect timestamp formatting in exports (#889) **Chores:** - Updated 8 dependencies for security patches - Refactored test suite for faster CI runs **Suggested Changelog (v2.4.0):** "This release improves reliability with webhook retry logic and session handling fixes. User preference loading is now faster via a new caching layer. Includes security updates for 8 dependencies." This illustrative example shows the MCP retrieving commit history and the AI synthesizing it into release notes.
This example pairs GitHub's commit history API with AI reasoning to generate human-readable summaries. Requires 'repo' scope for private repositories. The quality of the changelog depends on commit message clarity—poorly described commits will produce vague summaries. The MCP reads commits but cannot push the changelog back to GitHub; you'll need to copy it manually or use a separate write action.
Use-case deep-dives
When OAuth2 beats PATs for temporary access grants
A 6-person startup brings on two contractors for a 3-month build sprint. The GitHub MCP's 'add a repository collaborator' and 'add a repository to an app installation' tools let the team script onboarding without sharing admin credentials. OAuth2 means each Switchy user authenticates once, then the workspace can grant repo access in bulk during standup. The trade-off: if your contractors need access to more than 20 repos, the per-repo tool calls get tedious—consider a GitHub team instead. For short engagements with 5-10 repos, this MCP turns a 30-minute manual task into a 2-minute chat command. Worth it if you onboard contractors quarterly or more.
Label and assign issues without leaving support chat
A 4-person support team fields bug reports in Intercom, then manually opens GitHub issues and tags them 'bug', 'high-priority', or 'needs-repro'. The GitHub MCP's 'add labels to an issue' and 'add assignees to an issue' tools let the team create and route issues from Switchy while the customer is still on the line. OAuth2 means each support rep authenticates once; after that, the workspace can label and assign on their behalf. The boundary: if your issue volume exceeds 50 per day, the MCP's rate limits (5,000 requests per hour per user) start to pinch—at that scale, a webhook-driven sync is cleaner. For teams closing 10-30 issues daily, this MCP cuts the context-switch tax in half.
Audit and update branch rules across 15 repos in one pass
A 10-person engineering team runs a bi-weekly retro where they review which repos still allow direct pushes to main. The GitHub MCP's 'add app access restrictions' tool (plus the implicit read-protection endpoints in the 50-tool set) lets the team query and update branch protection rules without opening 15 browser tabs. OAuth2 means the engineering lead authenticates once, then the workspace can read and write rules on repos they admin. The catch: if your org has more than 30 repos, the tool's json-array input format gets unwieldy—you'll want a CSV upload or a GitHub Actions workflow instead. For teams managing 10-20 repos, this MCP turns a 45-minute audit into a 5-minute chat session during retro.
Frequently asked
What can the GitHub MCP do in Switchy?
The GitHub MCP gives your team programmatic access to 50 GitHub operations — accepting repo invitations, managing collaborators, adding labels to issues, configuring branch protections, and granting app installation access. It's built for teams that want to automate GitHub workflows without writing custom scripts or maintaining API tokens manually.
What OAuth scopes does the GitHub MCP request?
GitHub's OAuth2 flow will ask for scopes matching the operations you plan to use — typically `repo` for full repository access, `admin:org` for organization management, and `user` for email and profile actions. The MCP requests permissions upfront; you can't selectively grant access to individual tools after connecting. Review the consent screen carefully before authorizing.
Can the GitHub MCP create new repositories or delete existing ones?
No. The 50 tools focus on managing existing resources — collaborators, issues, labels, branch protections, and app installations. Repository creation and deletion aren't included. If your workflow requires spinning up repos programmatically, use GitHub's REST API directly or a dedicated infrastructure-as-code tool like Terraform with the GitHub provider.
How is this different from just using GitHub's web UI or API?
The MCP wraps GitHub's API into discrete, reusable tools your team can chain together in Switchy workflows. Instead of writing curl commands or maintaining authentication tokens, you connect once via OAuth2 and call tools by name. It's faster than clicking through the web UI and more maintainable than one-off scripts, especially for repetitive admin tasks.
Who on my team should connect the GitHub MCP?
Whoever connects it grants Switchy access to repositories and organizations they can see. For organization-wide workflows — like managing collaborators or branch protections — connect with an account that has admin or owner permissions. Personal repositories work fine with a standard member account. One connection per workspace; all team members share the same GitHub identity.