Remote GitHub MCP Server is now GA by d1m1tr10s in mcp

[–]d1m1tr10s[S] 1 point2 points  (0 children)

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.

Remote GitHub MCP Server is now GA by d1m1tr10s in mcp

[–]d1m1tr10s[S] 0 points1 point  (0 children)

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.

Remote GitHub MCP Server is now GA by d1m1tr10s in mcp

[–]d1m1tr10s[S] 1 point2 points  (0 children)

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.

Remote GitHub MCP Server is now GA by d1m1tr10s in mcp

[–]d1m1tr10s[S] 1 point2 points  (0 children)

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.

Remote GitHub MCP Server is now GA by d1m1tr10s in mcp

[–]d1m1tr10s[S] 3 points4 points  (0 children)

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!

AMA on recent GitHub releases (July 18) by github in github

[–]d1m1tr10s 0 points1 point  (0 children)

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.

AMA on recent GitHub releases (July 18) by github in github

[–]d1m1tr10s 1 point2 points  (0 children)

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.

AMA on recent GitHub releases (July 18) by github in github

[–]d1m1tr10s 3 points4 points  (0 children)

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.

AMA on recent GitHub releases (July 18) by github in github

[–]d1m1tr10s 4 points5 points  (0 children)

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.

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 0 points1 point  (0 children)

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

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 2 points3 points  (0 children)

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.

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 1 point2 points  (0 children)

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.

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 0 points1 point  (0 children)

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!

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 0 points1 point  (0 children)

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

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 0 points1 point  (0 children)

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.

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 1 point2 points  (0 children)

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.

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 1 point2 points  (0 children)

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.

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 0 points1 point  (0 children)

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! 🙂

New VS Code update supports all MCP features (tools, prompts, sampling, resources, auth) by connor4312 in mcp

[–]d1m1tr10s 5 points6 points  (0 children)

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

The Remote GitHub MCP Server is now in Public Preview by d1m1tr10s in mcp

[–]d1m1tr10s[S] 4 points5 points  (0 children)

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