developer-toolsoauth2

GitHub

Code hosting, issues, pull requests, and CI state.

Verdict

GitHub via MCP is the integration that turns your AI assistant from "answers questions about code" into "actually does work in your repo." Pull request reviews, issue triage, branch management, file edits, CI status — all reachable from the model with one auth flow. What we notice: the GitHub MCP shines when you stop thinking of it as "search Github" and start using it as "agent harness for your repo." Hand the model an issue link and ask for a fix; it'll read the issue, find the relevant files, propose a branch and a PR, and explain its reasoning along the way. Read-only operations (search code, list PRs, fetch a file) are fast and reliable. Write operations (create branch, commit, open PR) need a model that's careful — Sonnet 4.7 and GPT-5 handle them cleanly; weaker models occasionally rename a branch they shouldn't. Best for: repo-aware coding workflows where the model needs to read context before answering; PR review automation (summarise the diff, flag risky changes, draft the description); issue triage and labeling at scale; CI investigation ("why did this fail, what changed"). Avoid for: orgs where AI write access to a production repo is a policy issue (use read-only mode); deeply nested mono-repos where the search tool struggles to find the right scope without help; one-off questions that don't really need repo state. Practical frame: free with a GitHub account; the model handles authentication via OAuth. The cost is the model's tokens. A team running GitHub-MCP-heavy reviews on Sonnet 4.7 lands at "10-20% more model spend than chat-only" — recovered ~10x in PR review time saved.

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

  1. 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

Not enough Spaces yet to publish anonymised usage stats (we require ≥ 50 Spaces per week).

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 each
Open 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 branch
Open 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 @jane
Open 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-service
Open in a Space →

Add a Collaborator

@GitHub add the user contractor-username as a collaborator with push permission to the repository my-org/docs-site
Open in a Space →

Example outputs

Illustrative - representative of the model's voice and quality, not literal recordings.

Prompt

@github list all open pull requests in our main repo that have been waiting for review longer than 3 days

Output

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.

Notes

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.

Prompt

@github create a new issue in the backend repo titled 'Investigate slow query performance' and assign it to the database team label

Output

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.

Notes

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.

Prompt

@github summarize the last 15 commits to the main branch and draft a changelog entry for our next release

Output

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.

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

Onboarding contractors to private repos

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.

Triaging customer-reported bugs in issues

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.

Sprint retrospective branch protection audit

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.

Compare with

Compare with anything else →
Data last verified 7 hours ago.Sources aggregated hourly to weekly. See docs/architecture/model-directory.md.