Repository navigation
Feature request: expose an MCP server so AI agents can interact with PRs and issues #9070
Description
Summary
Add a Model Context Protocol (MCP) server to the extension so that AI coding agents running inside VS Code (Claude Code, GitHub Copilot extensions, etc.) can programmatically invoke the extension's PR and issue capabilities without a human clicking UI elements.
Motivation
The extension already exposes a rich set of commands through VS Code's command palette. Agents like Claude Code can call vscode.commands.executeCommand, but that requires the agent to be running inside VS Code and to know the exact command IDs. An MCP server would give any MCP-capable agent a stable, discoverable, schema-validated interface, regardless of how it is hosted.
Concretely: when an agent is working a PR (rebasing, fixing CI, iterating on review feedback) it currently has to shell out to gh CLI for everything. If the extension exposed an MCP server the agent could instead call typed tools and get back structured data that matches what the extension already knows — open diffs, review threads, CI status, notifications — without leaving the editor context.
Proposed tool groups
The list below was derived by querying contributes.commands from the extension's package.json and grouping commands by functional area. Each group maps naturally to one or more MCP tools.
Pull request lifecycle
Review
| MCP tool | Source commands |
|---|---|
start_review |
pr.startReview, pr.preReview |
submit_review |
review.approve, review.requestChanges, review.comment |
create_review_comment |
pr.createComment, pr.createSingleComment, pr.addFileComment |
edit_review_comment |
pr.editComment, pr.saveComment, pr.deleteComment |
resolve_review_thread |
pr.resolveReviewThread, pr.unresolveReviewThread |
create_suggestion |
pr.makeSuggestion, review.createSuggestionFromChange, review.createSuggestionsFromChanges |
apply_suggestion |
pr.applySuggestion, pr.applySuggestionWithCopilot |
mark_file_viewed |
pr.markFileAsViewed, pr.unmarkFileAsViewed, pr.resetViewedFiles |
diff_with_pr_head |
review.diffWithPrHead, review.diffLocalWithPrHead, pr.diffOutdatedCommentWithHead |
Issues
| MCP tool | Source commands |
|---|---|
create_issue |
issue.createIssue, issue.createIssueFromSelection, issue.createIssueFromClipboard, issue.createIssueFromFile |
get_issue |
issue.openIssue, issue.openDescription, issue.getCurrent |
start_working_on_issue |
issue.startWorking, issue.startWorkingBranchPrompt |
stop_working_on_issue |
issue.stopWorking |
copy_issue_link |
issue.copyIssueUrl, issue.copyIssueNumber, issue.copyGithubPermalink |
Notifications
| MCP tool | Source commands |
|---|---|
list_notifications |
notifications.refresh |
mark_notification_read |
notification.markAsRead, notifications.markPullRequestsAsRead |
mark_notification_done |
notification.markAsDone, notifications.markPullRequestsAsDone |
summarize_notification |
notification.chatSummarizeNotification |
Metadata helpers (new PR creation)
| MCP tool | Source commands |
|---|---|
add_assignees |
pr.addAssigneesToNewPr |
add_reviewers |
pr.addReviewersToNewPr |
add_labels |
pr.addLabelsToNewPr |
add_milestone |
pr.addMilestoneToNewPr |
add_projects |
pr.addProjectsToNewPr |
Implementation notes
- The MCP server can be registered via
vscode.lm.registerMcpServer(available since VS Code 1.99) and activated lazily when an MCP-capable client connects. - For read-only tools (
get_pull_request,list_notifications, …) the server can delegate directly to the extension's existing data models — no extra GitHub API calls needed. - For write tools (
submit_review,merge_pull_request, …) a confirmation prompt to the user would be appropriate before the first call, similar to how Copilot Edits asks for approval. - The
github.api.preloadPullRequestinternal command suggests there is already an API surface; the MCP server could build on that.
Alternatives considered
- Using the
ghCLI: works but has no awareness of what the extension has already fetched; forces duplicate API calls and loses the extension's diff/comment context. - VS Code Language Model tools: the
vscode.lmtool registration API is closer but limited to Copilot Chat inside VS Code; MCP reaches agents running outside the editor.
Related
- MCP spec: https://modelcontextprotocol.io/
- VS Code MCP extension hosting docs: https://code.visualstudio.com/api/extension-guides/mcp
Activity
feat: add MCP server to expose pull request and issue tools to AI agents
lmilbaum commentedon Oct 16, 2026
Hi — I've been working on an implementation of this. Here's a quick design summary before opening the PR, in case there are concerns worth surfacing first (this adds a network listener).
Design
Approach: bridge over existing LM tools, not new GitHub API code
src/lm/tools/already has 9vscode.LanguageModelToolclasses wired to Copilot Chat. The plan builds a thin MCP adapter over them — the descriptions and input schemas come straight fromcontributes.languageModelToolsinpackage.json, so there is one source of truth and new tools appear in both places by construction.Transport
A Node
http.createServerlistener bound to127.0.0.1on a random port, inside the extension host. A 256-bit per-session bearer token is exposed as$GITHUB_PR_MCP_URL/$GITHUB_PR_MCP_TOKENin integrated terminals viacontext.environmentVariableCollection. Agents started in that terminal can connect automatically; apr.copyMcpServerConfigcommand copies a ready-to-paste JSON snippet orclaude mcp addone-liner.Security controls:
crypto.timingSafeEqualtoken comparison, Host-header DNS-rebinding check, Origin-header check, 4 MB body limit, 127.0.0.1-only bind.Protocol
Hand-rolled legacy-era MCP (2025-11-25 / 2025-06-18 / 2025-03-26) — about 250 lines. This avoids touching
package-lock.json(repo guidance forbids it) and keeps the dependency surface flat. Modern (2026-07-28) clients fall back gracefully. Switching to@modelcontextprotocol/serverlater would be a one-file change.Write-tool confirmation
create_pull_requestandresolve_review_threadshow a VS Code modal (Allow / Allow for session / Deny) before executing. TheprepareInvocationmessages from the existing LM tool are reused as the dialog detail.Gating
githubPullRequests.experimental.mcpServerboolean setting, application scope, defaultfalse. Independent ofexperimental.chat. A no-op browser stub keeps the web build clean.MVP tools (9, all backed by existing LM tools)
get_active_pull_requestget_viewed_pull_requestget_issue_or_pull_requestget_pull_request_status_checkssearch_issues_and_pull_requestslist_labelsget_notificationcreate_pull_requestresolve_review_threadOpen questions I'd love feedback on
@modelcontextprotocol/servervs hand-rolled? Happy to add the SDK if you'd prefer and are willing to update the lockfile.registerMcpServerDefinitionProvider? Left out to avoid duplicating tools in Copilot Chat. Worth wiring up?context.secretsand/or a port setting be added?Happy to adjust scope or approach before opening the PR if any of this raises flags.
feat: add MCP server to expose pull request and issue tools to AI agents
alexr00 commentedon Oct 16, 2026
This is outside the scope of this extension. The GitHub MCP probably does everything you care about.
lmilbaum commentedon Oct 20, 2026
Thanks for the clarification. I agree that the GitHub MCP server already covers most GitHub-side operations, and duplicating those isn't the goal.
The gap I was trying to address is VS Code-specific PR context that this extension already maintains, such as the active or currently viewed PR and the review context in the editor. A GitHub API-based MCP server doesn't inherently know what the developer is looking at in VS Code.
With that distinction in mind, would a narrower integration that exposes only the extension's editor-local context to external agents be worth considering, perhaps by reusing the existing LM tools? Or is exposing that context to external agents also outside the intended scope of this extension?
I'm fine with the issue remaining closed. I'd just like to understand whether this is a scope boundary or whether there's a better place to pursue that specific use case.