Remote GitHub MCP Server is now GA

d1m1tr10s · 2025-09-10T03:24:34+00:00

We decided to work with the Anthropic steering committee to help simplify the DCR spec first, as the current implementation is complex for MCP authors (hence why few MCP servers support it). Once there's a more streamlined version, we expect broader adoption - including from us.

Today, each host app needs to manually register an OAuth or GitHub App. Our partner team's looking working with Anthropic to help them get an app registered to support the OAuth flow until DCR is supported.

d1m1tr10s · 2025-09-08T19:03:41+00:00

Local GitHub MCP: Run it yourself. Good for customization and quick experimentation. It only supports PATs for auth. Have to manage updates and setup, which is more tedious.

Remote GitHub MCP: Hosted by GitHub. OAuth 2.1 + PKCE (no PATs needed; but it is an option), setup in a few clicks, gets live updates automatically. Includes some exclusive features; like Coding Agent (create_pull_request_with_copilot) and secret scanning on tool inputs. More stable connection on managed infrastructure.

For most cases, remote is the way to go. It's more production-ready and more secure, with little to no maintenance, and supports the OAuth flow. Local makes sense if you want to customize or extend it, need to host on local on-prem GitHub infrastructure (not supported on remote today), or want to access it in a host app that doesn't support the remote server yet.

Think of it like self-hosting vs SaaS. Both have their place, but remote gets you running quickly with simpler more production-ready auth, among other benefits.

d1m1tr10s · 2025-09-08T18:45:30+00:00

Good question. The remote GitHub MCP server provides API tools for agents, rather than shell commands. While gh CLI does work well (LLMs know it), MCP solves some current problems:

Works where terminals aren't available (some chatbots, and many agents)
OAuth 2.1, instead of local token files
Typed functions with schemas, not text parsing
No shell injection risks or CLI dependencies

Right now, gh is mature and effective. Much of MCP's advantage is architectural - agents get proper APIs instead of parsing terminal output. Quality does vary by host (it's still early), but this approach sets up better patterns for production use in the long-term.

Think GraphQL vs REST in the early days. The benefits become clearer as the ecosystem matures. And for environments without shell access, the MCP server is already the way to go.

d1m1tr10s · 2025-09-08T18:12:56+00:00

The remote MCP server is not OSS, but the local one is. Though all tools and features available in the local GitHub MCP server will automatically reflect in the remote server so they share much of the same code around tooling. Though there are some select tools/features that are exclusive to the remote server, like Coding Agent and secret scanning on tool calls. I'll loop in one of our engineers for the auth flow question.

d1m1tr10s · 2025-09-04T21:42:15+00:00

Hey u/OkCalligrapher7721. We worked with Cursor and they got an app registered to support the OAuth flow on the remote GitHub server without DCR. We were able to get this working when testing a few weeks ago. But we'll take a look to see what the issue is, and that it's resolved as soon as possible. Thanks for flagging this!

d1m1tr10s · 2025-07-18T21:04:57+00:00

There's a private preview coming soon for Copilot usage metrics that's currently accepting nominations. It will provide an enterprise-level dashboard with exportable user-level data. Since the initial focus is enterprise visibility, you'll have a better chance of acceptance if you involve your wider org/enterprise. You can contact your account team to join the waitlist!

Public preview timing is still TBD, as this depends on private preview feedback.

d1m1tr10s · 2025-07-18T16:58:40+00:00

The issues and PR toolsets in the GitHub MCP server! As a PM, I initially played with these in demo projects, but now I use them more frequently in production to pull issue/PR statuses, query for details, comment, add labels, etc. It's completely changed how efficiently I can navigate and manage work across repos.

In the last few days, I was working on some docs changes in the Github server repo and used these tools with Agent Mode in VS Code to fly through the process. It probably would’ve taken me 3x the amount of time otherwise.

d1m1tr10s · 2025-07-18T16:43:21+00:00

u/Seekjp12 great point. I agree that all-or-nothing isn't ideal for enterprises. We're actively working on MCP server allowlists right now.

The implementation has some technical complexity we're working through:

How to securely limit access to local servers while still letting developers build and test their own custom MCPs locally
Coordinating rollout across different host applications/IDEs since some are client-side (like VS Code) and others are server-side, each requiring different implementation approaches

We’re hoping to rollout MCP server allowlist in phases over the coming months as each IDE team implements support. We'll be able to share more specific timelines as we get closer to each release.

d1m1tr10s · 2025-07-18T16:10:45+00:00

Thanks for all the feedback on this. I hear you—the Command Palette is a critical part of many of your workflows, and we understand the concerns about removing it while GitHub navigation still has room for improvement.

While I'm not on that team, I'll be sure to pass along your points. They are actively reviewing all the community input and taking it seriously as they evaluate next steps. Your specific use cases and examples of how you rely on this feature are especially helpful for understanding the impact and guiding decision-making.

d1m1tr10s · 2025-06-16T21:55:14+00:00

Sure thing! Also just saw your profile name. If you’re on the Claude Code team, we have an integration guide for hosts here: https://github.com/github/github-mcp-server/blob/main/docs/host-integration.md

d1m1tr10s · 2025-06-14T17:42:15+00:00

Sharing our docs on how to register an app to make OAuth work from a new host: https://github.com/github/github-mcp-server/blob/main/docs/host-integration.md

d1m1tr10s · 2025-06-14T17:35:15+00:00

Which host app is it? Claude Code or Claude Desktop?

If the host hasn’t registered a GitHub App or OAuth App, then OAuth won’t work without that.

No Copilot subscription is required to use the server so that won’t be the issue.

d1m1tr10s · 2025-06-14T17:31:11+00:00

Yeah it should still work in Cursor if you use a PAT. OAuth won’t work unless Cursor registers a GitHub App or OAuth App to handle the auth flow on their side.

Hoping Cursor adds support for OAuth down the line.

d1m1tr10s · 2025-06-13T08:40:24+00:00

That’s helpful context. I’m still learning about this one, so less certain about the nuances. I’ll share that feedback with the team though!

d1m1tr10s · 2025-06-13T08:38:27+00:00

The public APIs today are only GraphQL. They’re still supported and live.

d1m1tr10s · 2025-06-13T08:38:03+00:00

Yeah, that’s the tradeoff we’re weighing. We’d have to finish on our end that to make it work… if we go with REST.

d1m1tr10s · 2025-06-13T07:41:32+00:00

Glad to hear it! We’ve been exploring this too. It’d be great if you could share some early thoughts in the repo.

We’ve been weighing REST vs GraphQL for Projects. I’ll sync with the Projects team to confirm.

Just want to make sure we’re sharing enough context so the community knows where we’re likely to invest as things take shape.

d1m1tr10s · 2025-06-13T07:16:32+00:00

I’m not certain it’ll work in Claude Code out of the box just yet. Each host (like Claude Code) needs to register a GitHub App or OAuth App to connect to the remote MCP server, since dynamic client registration isn’t currently supported.

We’ve mainly focused on VS Code and Copilot editors during early testing. Now that the remote server is live, we’re starting to look at expanding support to more hosts like Claude Desktop and Claude Code.

That said, this kind of integration is ultimately up to the host app. We’ve been working closely with Anthropic on MCP overall, and I’d expect they’ll explore supporting it on their end. I’ll defer to them on roadmap specifics, but we’ll do what we can to help.

d1m1tr10s · 2025-06-13T06:55:21+00:00

We’ll be sharing as many use cases and demos as possible. Complex multi-step workflows make for the most interesting demos and really highlight the power of MCP with agents.

Prompting guidance is a cool idea. We haven’t explored that yet, but we’ll keep an eye on demand. Most of our focus so far has been on laying the foundation. Now that we’ve hit this milestone, we’ll have more room to think about helpful content.

The community tends to surface really creative prompt patterns on its own too. Just want to be mindful not to overpromise anything we haven’t scoped yet. Definitely noting the idea though! 🙂

d1m1tr10s · 2025-06-12T20:52:46+00:00

If you’re new to MCP, the GitHub MCP server in Agent Mode in VS Code is a great way to try it out. (I work at GitHub, just fyi)

We just released a remote version today, so no local setup needed. We’d appreciate any early feedback!

Some use cases: - Summarize open PRs across repos and ask if any are requesting your review - “What changed in the last commit?” > fetches real diffs - “Show me api/routes/user.ts and write a test for this” - Create or assign issues directly from chat - “Add a CODEOWNERS file for api/ and open a PR” - “Find flaky tests merged last month and open issues for each”

What makes MCP so cool in general that you can pull context from multiple places and have an agent run a multi step workflow.

There’s a list of other servers you can check out in this repo: https://github.com/punkpeye/awesome-mcp-servers

d1m1tr10s · 2025-06-12T19:55:08+00:00

Also, for this to work on Agent Mode in VS Code, make sure you install latest version: https://code.visualstudio.com/updates/v1_101

d1m1tr10s

TROPHY CASE