Expose the GitHub integration through MCP - #232
Conversation
… 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.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
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 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
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. Comment |
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.
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:managecheck the REST routes enforce.list_github_repositorieslink_github_repositoryunlink_github_repositorylist_issue_pull_requestsThe thing the descriptions have to say out loud
Association does not route anything.
applyGithubEventnever readsgithub_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_repositorywould 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_linkis 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, andprojectId = nullis 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 withoutintegration:manageis refused on both read and write.Watched failing: unregistering the module fails all nine. Full MCP suite 139 pass, typecheck and every
verifyguard clean.Greptile Summary
This PR exposes GitHub repository associations and issue-linked pull requests through four MCP tools.
Confidence Score: 5/5
The PR appears safe to merge.
No blocking failure remains.
Important Files Changed
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]Reviews (2): Last reviewed commit: "fix(mcp): pin the permission for reading..." | Re-trigger Greptile