Skip to content

Expose the GitHub integration through MCP - #232

Merged
imshashank merged 2 commits into
mainfrom
feat/github-mcp-tools
Aug 8, 2026
Merged

Expose the GitHub integration through MCP#232
imshashank merged 2 commits into
mainfrom
feat/github-mcp-tools

Conversation

@imshashank

@imshashank imshashank commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

The gap

Seventy one MCP tools, and not one of them could see a repository. An agent could create a project, a sprint, an issue and a document, but could never associate the code with any of it, and could never find out which pull requests were open against an issue it was working on.

The tools

All four go through the same services the web app uses and the same integration:manage check the REST routes enforce.

Tool
list_github_repositories Every repository the App is installed on, and what each is associated with
link_github_repository Associate with a project, or with the workspace when no project is named
unlink_github_repository Remove one association, leaving the others intact
list_issue_pull_requests The branches, pull requests and checks linked to an issue

The thing the descriptions have to say out loud

Association does not route anything. applyGithubEvent never reads github_repository_link. It looks the repository up in the watch list, takes the organization off it, and resolves issue identifiers found in the pull request against that whole organization. A pull request in any watched repository links to any issue it names.

So the association is for organising the workspace, not for deciding which issues a repository's pull requests may touch. An agent reading a tool called link_github_repository would reasonably assume the opposite, so every description says which it is.

The genuinely load bearing side effect is that linking calls reconcileWatchedRepositories, and that is what makes events reach Orbit at all. Unlinking the last association stops it. Both descriptions say so.

Answers the shape questions too

github_repository_link is a join table with (repository, project) unique where the project is not null, and a second partial unique on the repository alone where it is. So a project may have many repositories, a repository may serve many projects, and projectId = null is the workspace level association. All three are covered by tests.

Tests

Nine in tests/tools/github.test.ts, including one project with two repositories, one repository in two projects, the workspace level case, that linking actually starts watching, that an unknown repository is refused rather than guessed at, and that a member without integration:manage is refused on both read and write.

Watched failing: unregistering the module fails all nine. Full MCP suite 139 pass, typecheck and every verify guard clean.

Greptile Summary

This PR exposes GitHub repository associations and issue-linked pull requests through four MCP tools.

  • Adds tools to list, link, and unlink connected GitHub repositories.
  • Adds issue-scoped pull-request lookup using the same authorization model as the existing web API.
  • Registers the GitHub tools and adds integration, association, watch-state, and authorization coverage.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename Overview
packages/mcp-server/src/tools/github.ts Adds four GitHub MCP tools with authorization consistent with their corresponding management and issue-reading operations.
packages/mcp-server/src/tools/index.ts Registers the new GitHub tool module with the MCP server.
packages/mcp-server/tests/tools/github.test.ts Covers repository discovery, association shapes, watch reconciliation, unknown repositories, unlinking, pull-request lookup, and permission behavior.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[MCP client] --> B{GitHub tool}
  B --> C[List repositories]
  B --> D[Link repository]
  B --> E[Unlink repository]
  B --> F[List issue pull requests]
  C --> G[integration:manage]
  D --> G
  E --> G
  F --> H[issue:read and team-scoped getIssue]
  C --> I[GitHub catalogue service]
  D --> J[Repository association service]
  E --> J
  F --> K[gitLink records]
Loading

Reviews (2): Last reviewed commit: "fix(mcp): pin the permission for reading..." | Re-trigger Greptile

… requests

The GitHub integration had no MCP surface at all. Seventy one tools and
not one of them could see a repository, so an agent could create the
project but never associate the code with it, and could never find out
which pull requests were open against an issue it was working.

Four tools, all going through the same services and the same
integration:manage check the REST routes use:

list_github_repositories   every installed repository and what it is
                           associated with
link_github_repository     associate with a project, or with the
                           workspace when none is named
unlink_github_repository   remove one association, leaving the others
list_issue_pull_requests   the branches, pull requests and checks
                           linked to an issue

The descriptions say plainly that matching is by issue identifier
rather than by association, because an agent reading the tool list
would otherwise reasonably assume linking a repository to a project is
what routes its pull requests.
@imshashank
imshashank requested a review from pulkitxm as a code owner August 8, 2026 11:37
@vercel

vercel Bot commented Aug 8, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
orbit Ready Ready Preview Aug 8, 2026 1:19pm

Request Review

@coderabbitai

coderabbitai Bot commented Aug 8, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@imshashank, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 17 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: a175bdf4-a4fc-4820-83ab-33aa43d5429c

📥 Commits

Reviewing files that changed from the base of the PR and between 66b8f11 and a954211.

📒 Files selected for processing (3)
  • packages/mcp-server/src/tools/github.ts
  • packages/mcp-server/src/tools/index.ts
  • packages/mcp-server/tests/tools/github.test.ts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added tests Test coverage and test infrastructure area: mcp The MCP server, its tools and its OAuth labels Aug 8, 2026
Comment thread packages/mcp-server/src/tools/github.ts
The tool relied on getIssue for its authorization rather than saying
what it required. It now asserts issue:read explicitly and filters to
pull_request rows, which is exactly what the git-links route the issue
page calls already does, so the two cannot drift apart.

Deliberately not integration:manage. An engineer working an issue has
to be able to see the pull request on it, and the product already takes
that position: the route behind the issue page asserts issue:read and
returns the same columns. Raising the MCP bar would make an agent less
able than the page it is looking at.

A test pins that: a member who is refused list_github_repositories can
still read the pull requests on an issue they can see. Swapping the
assertion to integration:manage fails it.
@imshashank
imshashank merged commit 2da40e0 into main Aug 8, 2026
12 checks passed
@imshashank
imshashank deleted the feat/github-mcp-tools branch August 8, 2026 14:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: mcp The MCP server, its tools and its OAuth tests Test coverage and test infrastructure

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant