Author name: ITMAITY

Imagine you’re coding in VS Code with Copilot agent mode. You ask it: “What’s the status of PR #72?” But instead of fetching the details from GitHub, the model hallucinates an answer based on outdated context or guessed semantics. It sounds convincing, but it’s just wrong. Models, after all, are only as good as the context given to them. If large language models (LLMs) don’t have the ability to connect to other apps and tools, they’re not as useful as they can be. This is the core problem that Model Context Protocol (MCP) was built to solve. MCP is an open protocol that standardizes how LLM apps connect to and work with your external tools and data sources. It is similar to the Language Server Protocol (LSP) in that both follow client-server architecture, they simplify interaction between systems, and they provide standardized communication patterns. In essence, MCP is the LSP of LLMs. And now, GitHub has open-sourced its own MCP server. It acts as a source-of-truth interface between GitHub and any LLM, reducing hallucinations and unlocking new automation workflows. We cover this (and more!) in our latest episode of the GitHub Podcast! Listen below 👇 Trying to catch up quickly on MCP? We put together a guide on everything you need to know (but were too embarrassed to ask) about MCP.  Get the guide > MCP architecture MCP is based on a client-server architecture where an MCP host  — an AI app like Copilot Chat — maintains a dedicated 1:1 connection with MCP servers. Some key concepts to understand: MCP host: an LLM app that wants to access data via MCP (eg. VS Code, Copilot Chat) MCP clients: maintain a 1:1 connection with MCP servers, inside the host app MCP servers: lightweight programs that expose specific capabilities through MCP  GitHub’s MCP Server The GitHub MCP Server connects AI tools directly to GitHub’s platform. Instead of performing REST or GraphQL API calls, you point your MCP-compatible client or agent to the server, and request exactly what you need. For example, you could ask it to: List all open issues in a repository Show pull requests waiting for review Fetch metadata about a repo or file Create or comment on issues The magic is that you can now use natural language to make requests that are automagically converted into structured, semantically meaningful API calls. You’re no longer creating custom  API endpoints or parsing markdown descriptions. Ask for what you need in natural language to fetch real-time data from GitHub. And because the server speaks MCP, it can work with any compatible host. Copilot Workspace, VS Code plugins, LLM-based products, custom chat UIs, and homegrown agents can all request context or trigger actions using the same standardized interface. How it works The architecture is conceptually simple, but powerful: Server: GitHub’s MCP Server is a standalone service that listens for structured MCP requests. Client: A connector between the host and server. It knows how to translate user intent into valid MCP requests. Host: The AI front-end (like an IDE assistant or chat UI) that surfaces the conversation and sends structured prompts downstream. When a user asks a question, the host translates the question into a semantic request, the client packages it as an MCP request, and the server fetches the real data from GitHub and returns it as structured JSON. This creates a clean separation between the language model, the UX, and the data or tools it can access. Each layer is modular, testable, and swappable. How to get started using the GitHub Remote MCP Server The best part: You can start using GitHub’s MCP server today! Here’s what you need: MCP Host: VS Code or any other LLM application that supports MCP MCP Client: Copilot agent, LLM chat UI, or custom client that speaks MCP GitHub MCP Server: Available from the official GitHub MCP Server repo To install the GitHub MCP Server in VS Code follow these steps: Add the server configuration by copying this code snippet: { “servers”: { “github”: { “type”: “http”, “url”: “https://api.githubcopilot.com/mcp/” } } } Create the configuration file: In your project root, create a directory named /vscode Inside that directory, create a file named mcp.json Paste the above code into the file Complete setup: Click the start button that appears Complete the OAuth flow when prompted You’re now ready to use the GitHub MCP server in VS Code! Start automating with the GitHub MCP now Watch this video where I installed the GitHub MCP Server and automagically created five issues with natural language! Real-world use cases Early adopters have used MCP servers to create useful tools. Markdown automation: One team used the MCP server to turn dozens of GitHub Issues into Markdown content files for a community microsite. The issues had been collected as part of a campaign. Previously, converting them into site-ready content required tedious and manual reformatting. With MCP, the team created a script that fetched all labeled issues, cleaned and formatted the text, and committed the files automatically. It turned the process into a quick, repeatable job. Weekly team digests: Another team built a lightweight bot that scans specific GitHub repos and compiles a weekly digest. It pulls recent pull requests, issues, and merged changes, and summarizes them in Markdown. The report is posted to Slack every Monday morning, keeping distributed teams aligned without needing a meeting. Because it uses MCP, the bot isn’t tied to hard-coded GitHub queries; the same code could run against any MCP-compliant server. Conversational project assistants: A small open source team built a chat-based interface where contributors could ask natural-language questions like “What issues are waiting on review?” or “What changed in the last release?” The agent uses MCP to translate those questions into structured GitHub queries, fetch real-time data, and return conversational summaries.  Personal LLM dashboards: One developer connected their own GitHub account to an MCP-aware agent running on a local dashboard. The assistant provides proactive prompts each morning: pull requests they need to review, stale issues in

In June, we experienced three incidents that resulted in degraded performance across GitHub services. June 5 17:47 UTC (lasting 1 hour and 33 minutes) On June 5, 2025, between 17:47 UTC and 19:20 UTC, the Actions service was degraded, leading to run start delays and intermittent job failures. During this period, 47.2% of runs had delayed starts of 14 minutes on average, and 21.0% of runs failed. The impact extended beyond Actions itself; 60% of Copilot Coding Agent sessions were cancelled, and all Pages sites using branch-based builds failed to deploy (though Pages serving remained unaffected). The issue was caused by a spike in load between internal Actions services exposing a misconfiguration that caused throttling of requests in the critical path of run starts. We mitigated the incident by correcting the service configuration to prevent throttling and have updated our deployment process to ensure the correct configuration is preserved moving forward. June 12 17:55 UTC (lasting 3 hours and 12 minutes) On June 12, 2025, between 17:55 UTC and 21:07 UTC, the GitHub Copilot service was degraded and experienced unavailability for Gemini models and reduced availability for Claude models. Users experienced significantly elevated error rates for chat completions, slow response times, timeouts, and chat functionality interruptions across VS Code, JetBrains IDEs, and GitHub Copilot Chat. This was due to an outage affecting one of our model providers. We mitigated the incident by temporarily disabling the affected provider endpoints to reduce user impact. We are working to update our incident response playbooks for infrastructure provider outages and improve our monitoring and alerting systems to reduce our time to detection and mitigation of issues like this one in the future. June 17 19:32 UTC (lasting 31 minutes) On June 17, 2025, between 19:32 UTC and 20:03 UTC, an internal routing policy deployment to a subset of network devices caused reachability issues for certain network address blocks within our datacenters. Authenticated users of the github.com UI experienced 3-4% error rates for the duration of the incident. Authenticated callers of the API experienced 40% error rates. Unauthenticated requests to the UI and API experienced nearly 100% error rates. Actions experienced 2.5% of runs being delayed for an average of 8 minutes and 3% of runs failing. Large File Storage (LFS) requests experienced 1% errors. At 19:54 UTC, the deployment was rolled back, and network availability for the affected systems was restored. At 20:03 UTC, we fully restored normal operations. To prevent similar issues, we are expanding our validation process for routing policy changes. Please follow our status page for real-time updates on status changes and post-incident recaps. To learn more about what we’re working on, check out the GitHub Engineering Blog. The post GitHub Availability Report: June 2025 appeared first on The GitHub Blog. ​ Company news, News & insights, GitHub Availability Report The GitHub Blog

Open source software is open digital infrastructure that our economies and societies rely on. Nevertheless, open source maintenance continues to be underfunded, especially when compared to physical infrastructure like roads or bridges. So we ask: how can the public sector better support open source maintenance?  As part of our efforts to support developers, GitHub’s developer policy team has commissioned a study from Open Forum Europe, Fraunhofer ISI and the European University Institute that explores how one of the open source world’s most successful government programs, the German Sovereign Tech Agency, can be scaled up to the European Union level. That study was published today. Here’s what it says and what you can do to help make the EU Sovereign Tech Fund (EU-STF) a reality. The maintenance challenge There is a profound mismatch between the importance of open source maintenance and the public attention it receives. The demand-side value of open source software to the global economy is estimated at $8.8 trillion, and the European Commission’s own research shows that OSS contributes a minimum of €65-95 billion to the EU economy annually. Basic open source technologies, such as libraries, programming languages, or software development tools, are used in all sectors of the economy, society, and public administrations. Open source is everywhere Open source is valuable Open source is underfinanced 96% of all code bases contain OSS $8.8T demand-side value to global economy 1/3 of OSS maintainers are unpaid 77% of a given code base is OSS €65-95M minimum contribution to annual EU GDP 1/3 are the only maintainer of their OSS project The flip side of everybody benefiting from this open digital infrastructure is that too few feel responsible for paying the tab. The Sovereign Tech Agency’s survey of over 500 OSS maintainers showed that a third of them are not paid at all for their maintenance work, but would like to be. Another third earns some income from OSS maintenance, but is not able to make a living off this work. Perhaps even more alarmingly, a third of respondents are solo maintainers, and almost three quarters of surveyed projects are maintained by three people or fewer. As prominent security incidents such as the xz backdoor or the Log4Shell vulnerability have shown in recent years, it can mean serious risks for the OSS community’s health and the security of our global software ecosystem if too much is put on the shoulders of small, overworked, and underappreciated teams. At GitHub, we are helping address this open source sustainability challenge through GitHub Sponsors, the GitHub Secure Open Source Fund, free security tooling for maintainers, and other initiatives. Yet we recognize that there is a significant gap between the immense public value of open source software and the funding that is available to maintain it, a gap that this research is seeking to address. Designing an impactful fund Building on the success story of the German Sovereign Tech Agency, which has invested over €23 million in 60 OSS projects in its first two years of operation (2022-2024), the EU-STF should have five main areas of activity: Identifying the EU’s most critical open source dependencies, Investments in maintenance, Investments in security, Investments in improvement, Strengthening the open source ecosystem. The study proposes two alternative institutional setups for the EU-STF: either the creation of a centralized EU institution (the moonshot model), or a consortium of EU member states that provide the initial funding and apply for additional resources from the EU budget (the pragmatic model). In both cases, to make the fund a success, the minimum contribution from the upcoming EU multiannual budget should be no less than €350 million. This would not be enough to meet the open source maintenance need, but it could form the basis for leveraging industry and national government co-financing that would make a lasting impact. Equipped with the learnings from the German Sovereign Tech Agency and other government open source programs, such as the US Open Technology Fund or the EU’s Next Generation Internet initiative, the study identified seven design criteria that the EU-STF must meet: Pooled financing. To address the maintenance funding gap, industry, national governments and the EU should all be able to put money into the same pot. It is not in the interest of overworked open source maintainers to have to research and apply to dozens of separate funds, all with slightly different funding criteria. That’s why GitHub’s Secure Open Source Fund pools funding from many industry partners into one coherent program. The EU-STF should follow the same logic and be capable of collecting contributions from industry, national governments and the EU budget alike. Low bureaucracy. If you’re one of those aforementioned unpaid solo maintainers, the last thing you need is to sink several days of work into a complicated application process with an uncertain outcome that many EU funding programs are unfortunately known for. The EU-STF should combine a lightweight application process along with its own research to identify and proactively contact critical OSS infrastructure projects. Funding recipients should have limited reporting requirements to make sure that they can spend their time on improving the health of their OSS projects, not jumping through administrative hoops. Political independence. Public funding programs often follow technological trends, such as blockchain, quantum computing or AI. Open source maintenance often gets overlooked, because it is neither a new development nor limited to a particular economic sector: it is foundational to all of them. An EU-STF has to be politically independent enough to shield it from frequent pivots to new, politically salient topics, and instead keep it focused on the mission of securing and maintaining our public software infrastructure. Flexible funding. There is no one-size-fits-all model for open source maintenance. Many maintainers are hired by companies to work on OSS as part of their day jobs. Others maintain projects in their free time. Some critical OSS projects are governed by a foundation or other nonprofit, yet others are made up of a loose collective of individuals scattered across the globe.

If you’ve ever dusted off an old project and thought, “How did I leave things in such a mess?”, you’re in good company. On my latest Rubber Duck Thursdays stream, I dove back into my OctoArcade Next.js app, only to rediscover a host of UI gremlins. So, we experimented with something that felt like magic: letting GitHub Copilot agent mode, paired with Playwright MCP server, identify and fix UI bugs. Along the way, I learned (again) how crucial it is to provide AI tools like Copilot with clear, detailed requirements.  Let’s walk through how I used these agentic tools to debug, test, and (mostly) solve some tricky layout issues, while covering practical tips for anyone looking to leverage Copilot’s agent workflows in real-world projects. 💡 Useful Links Use agent mode in VS Code Use MCP servers in VS Code Playwright MCP The setup: Revisiting OctoArcade (and its bugs) I started by firing up OctoArcade, my collection of GitHub-themed mini-games built with Next.js and TypeScript. Within minutes, I realized I had been introducing a new game to the app, but hadn’t quite gotten around to fixing some bugs. Here’s what we accomplished in one stream session: Problem: Navigation header overlapping game content across all games Solution: Copilot agent mode and Playwright MCP server identified the issue through visual inspection, and implemented a global header fix Bonus: Fixed some additional UI issues (unintended gaps between the game canvas and footer) discovered during testing Result: Hands-off debugging that solved problems I’d stepped away from, and had previously spent some cycles on fixing Let me walk you through how this worked and what you can learn for your own debugging workflows. Making sure Copilot custom instructions are set up With my environment set up in VS Code Insiders, I checked that my Copilot custom instruction files (.github/copilot-instructions.md, *.instructions.md files) were up to date. This is usually my first step before using any agentic features, as these instructions provide important context on my expectations, coding styles, and working practices — influencing how Copilot responds and interacts with my codebase. In my last blog post, we spent time exploring recommended practices when setting up Copilot custom instructions. We also covered how the copilot-setup-steps.yml sets up a developer environment when using Copilot coding agent. Take a look at that blog post on using GitHub Copilot coding agents to refactor and automate developer workflows to learn more. 💡 Did you know? Learn more about instruction files: Adding repository custom instructions for GitHub Copilot (with instructions for different editors) Adding custom instructions to your repository is my go-to reference, as I personally find the structure of the file very helpful github/awesome-copilot has a collection of community contributed instructions, reusable prompts, chat modes and more Always keep your Copilot custom instructions current (including descriptions of your repository structure, common steps like building and testing, and any expectations before making commits). Copilot agents depend on this context to deliver relevant changes. When I think my instructions file is out of date, I typically prompt Copilot in agent mode with a prompt along the lines of: Based on the #codebase, please can you update the custom instructions file for accuracy? Please make sure to keep the structure (i.e. headings etc.) as-is. Thanks! In some of my instruction files, I’ve even instructed Copilot to keep key documentation (README, .github/copilot-instructions.md, etc.) up to date when it makes significant changes (like refactoring files or adding new features). Agentic debugging: UI troubleshooting with Playwright MCP Playwright MCP server is a powerful tool for end-to-end testing and UI automation. Since it’s an MCP server, you can access it through your favorite AI tools that support the Model Context Protocol, like Copilot agent mode and Copilot coding agent! In agent mode, Copilot can use Playwright’s structured tools to: Load web pages Simulate user actions (clicks, navigation) Inspect rendered layouts without needing vision models This means you can ask Copilot to “see” what a human would, spot layout issues, and even propose CSS or component fixes. To get started with Playwright, it’s as easy as adding the below to your MCP configuration: {   “mcpServers”: {     “playwright”: {       “command”: “npx”,       “args”: [“@playwright/mcp@latest”]     }   } } Once you have started the MCP server, you should see that Copilot now has access to a suite of new tools for browser interaction like: browser_snapshot – Capture accessibility snapshots of pages browser_navigate – Navigate to URLs browser_click, browser_type, browser_hover – Interact with elements browser_resize – Test different viewport sizes browser_take_screenshot – Visual documentation And many more: You can find the full list in the tools section of Playwright MCP server’s README With access to a new set of tools to solve the UI challenges, it was time to point Copilot at the problem. Meaning, I now had the task of clearly defining the requirements in my initial prompt…easier said than done. The debugging journey: Real-time fixes and lessons learned 1. Describe the problem and let agent mode work I noticed that, in several pages, the main content was tucked behind the navigation bar. This was particularly noticeable on any pages that rendered games. On some pages (like OctoPong), I saw inconsistent spacing between game elements and the footer. To get Copilot agent mode started, I aimed to be as explicit as possible in my prompts: I have spotted that there is a bit of a UI error. It seems like the main content of any page “starts” behind the navigation bar. This is more evident on the games like octosnap, octopong and octobrickbreaker. Can you take a look at the site using Playwright (you’ll need to spin up an instance of the server), take a look at the pages, and then investigate? Thanks! It loaded up the pages to configure each game, but didn’t try loading the games themselves (so missed some context). I followed up in a separate prompt: Sorry, I wanted you to take a look when a game is actually loaded too. Can you play the game Octopong and Octosnap –

AI features can make an open source project shine. At least, until setup asks for a paid inference API key.  Requiring contributors or even casual users to bring their own large language model (LLM) key stops adoption in its tracks: $ my-cool-ai-tool Error: OPENAI_API_KEY not found Developers may not want to buy a paid plan just to try out your tool, and self hosting a model can be too heavy for laptops or GitHub Actions runners.  GitHub Models solves that friction with a free, OpenAI-compatible inference API that every GitHub account can use with no new keys, consoles, or SDKs required. In this article, we’ll show you how to drop it into your project, run it in CI/CD, and scale when your community takes off. Let’s jump in. The hidden cost of “just add AI” AI features feel ubiquitous today, but getting them running locally is still a challenge for a few reasons: Paid APIs: The simplest path is to ask users for an OpenAI or Anthropic key. That’s a non-starter for many hobbyists and students because paid APIs are too expensive. Local models: Running a 2 B-parameter LLM can work for lightweight tasks, but anything that requires more intelligence will quickly blow past typical laptop memory — let alone the 14 GB container that backs a GitHub Actions runner. Docker images and weights: You can bundle a model with your app, but distributing multi-gigabyte weights balloons install size and slows CI. Every additional requirement filters out potential users and contributors. What you need is an inference endpoint that’s: Free for public projects Compatible with existing OpenAI SDKs Available wherever your code runs, like your laptop, server, or Actions runner That’s what GitHub Models provides. GitHub Models in a nutshell What it is: A REST endpoint that speaks the chat/completions spec you already know. What you get: A curated set of models (GPT-4o, DeepSeek-R1, Llama 3, and more) hosted by GitHub. Who can call it: Anyone with a GitHub Personal Access Token (PAT), or a repository’s built-in GITHUB_TOKEN when you opt-in via permissions. How much it costs: Free tier for all personal accounts and OSS orgs; metered paid tier unlocks higher throughput and larger context windows. Because the API mirrors OpenAI’s, any client that accepts a baseURL will work without code changes. This includes OpenAI-JS, OpenAI Python, LangChain, llamacpp, or your own curl script. How to get started with GitHub Models Since GitHub Models is compatible with the OpenAI chat/completions API, almost every inference SDK can use it. To get started, you can use the OpenAI SDK: import OpenAI from “openai”; const openai = new OpenAI({ baseURL: “https://models.github.ai/inference/chat/completions”, apiKey: process.env.GITHUB_TOKEN // or any PAT with models:read }); const res = await openai.chat.completions.create({ model: “openai/gpt-4o”, messages: [{ role: “user”, content: “Hi!” }] }); console.log(res.choices[0].message.content); If you write your AI open source software with GitHub Models as an inference provider, all GitHub users will be able to get up and running with it just by supplying a GitHub Personal Access Token (PAT). And if your software runs in GitHub Actions, your users won’t even need to supply a PAT. By requesting the models: read permission in your workflow file, the built-in GitHub token will have permissions to make inference requests to GitHub Models. This means you can build a whole array of AI-powered Actions that can be shared and installed with a single click. For instance: Code review or PR triage bots Smart issue tagging workflows Weekly repository activity report generators And anything else that a GitHub Action can do Plus, using GitHub Models makes it easy for your users to set up AI inference. And that has another positive effect: it’s easier for your contributors to set up AI inference as well. When anyone with a GitHub account can run your code end to end, you’ll be able to get contributions from the whole range of GitHub users, not just the ones with an OpenAI key. Zero-configuration CI with GitHub Actions Publishing an Action that relies on AI used to require users to add their inference API key as a GitHub Actions secret. Now you can ship a one-click install: yaml # .github/workflows/triage.yml permissions: contents: read issues: write models: read # 👈 unlocks GitHub Models for the GITHUB_TOKEN jobs: triage: runs-on: ubuntu-latest steps: – uses: actions/checkout@v4 – name: Smart issue triage run: node scripts/triage.js The runner’s GITHUB_TOKEN carries the models:read scope, so your Action can call any model without extra setup. This makes it well suited for: Automated pull request summaries Issue deduplication and tagging Weekly repository digests Anything else you can script in an Action Scaling when your project takes off The GitHub Models inference API is free for everyone. But if you or your users want to do more inference than the free rate limits allow, you can turn on paid inference in your settings for significantly larger context windows and higher requests-per-minute.  When your community grows, so will traffic. So it’s important to consider the following:  Requests per minute (RPM): While the free tier offers default limits, the paid tier offers multiples higher. Context window: Free tier tops out at standard model limits; paid enables 128k tokens on supported models. Latency: The paid tier runs in its own separate deployment, so you’re not in the same queue as free tier users. To get started, you can enable paid usage in Settings > Models for your org or enterprise. Your existing clients and tokens will keep working (but they’ll be faster and support bigger contexts). Take this with you LLMs are transforming how developers build and ship software, but requiring users to supply their own paid API key can be a barrier to entry. The magic only happens when the first npm install, cargo run, or go test just works. If you maintain an AI-powered open source codebase, you should consider adding GitHub Models as a default inference provider. Your users already have free AI inference via GitHub, so there’s little downside to letting them use it with

Model Context Protocol (MCP) enables AI agents to connect to external tools and data sources without having to implement API-specific connectors. Whether you’re extracting key data from invoices, summarizing support tickets, or searching for code snippets across a large codebase, MCP provides a standardized way to connect LLMs with the context they need.  Below we’ll dig into why security is such a crucial component to MCP usage, especially with a recent specification release, as well as how developers of both MCP clients and MCP servers can build secure integrations from the get-go. Why security matters for MCP Unlike traditional APIs that serve known clients in somewhat controlled environments, MCP servers act as bridges between AI agents and an unlimited number of data sources that can include sensitive enterprise resources. So, a security breach won’t just compromise data — it can give malicious actors the ability to manipulate AI behavior and access connected systems. To help prevent common pitfalls, the MCP specification now includes security guidelines and best practices that address common attack vectors, like confused deputy problems, token passthrough vulnerabilities, and session hijacking. Following these patterns from the start can help you build systems that can handle sensitive tools and data. Understanding the MCP authorization The MCP specification uses OAuth 2.1 for secure authorization. This allows MCP, at the protocol level, to take advantage of many modern security capabilities, including: Authorization server discovery: MCP servers implement OAuth 2.0 Protected Resource Metadata (PRM) (RFC 9728) to advertise the authorization servers that they support. When a client attempts to access a protected MCP server, the server will respond with a HTTP 401 Unauthorized and include a WWW-Authenticate header pointing to the metadata endpoint. Dynamic client registration: This is automatic client registration using OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591). This removes the need for manual client setup when AI agents connect to MCP servers dynamically. Resource indicators: The specification also mandates RFC 8707 Resource Indicators, ensuring that tokens are bound to specific MCP servers. This prevents token reuse attacks and helps maintain clear security boundaries. Even with the latest changes to authorization specs, like the clean split between the responsibilities of the authorization server and the resource server, developers don’t need to worry about implementing security infrastructure from scratch. (Because the requirement to follow the OAuth2.1 conventions didn’t change.) So developers can just use off-the-shelf authorization servers and identity providers.  Because MCP requires implementers to snap to OAuth 2.1 as the default approach to authorization, this also means that developers can use existing OAuth libraries to build the authorization capabilities into their MCP servers without anything super-custom. This is a massive time and effort saver. The complete authorization flow When it comes to connecting to protected MCP servers, a MCP client will need to somehow find out what credentials the server needs. Luckily, because of the aforementioned discovery mechanism, this is a relatively straightforward flow: Discovery phase. MCP client attempts to access MCP server without credentials (that is a token). Server response. MCP server returns a HTTP 401 Unauthorized response with a metadata URL in the WWW-Authenticate header. Metadata retrieval. MCP client fetches Protected Resource Metadata, parses it, and then gets the authorization server endpoints. Client registration. MCP client automatically registers with authorization server (if supported). Some clients may be pre-registered. Authorization request. MCP client initiates OAuth flow with Proof Key for Code Exchange (PKCE) and the resource parameter. User consent. The user authorizes access through the authorization server. Token exchange. MCP client exchanges authorization code for access token. Authenticated requests. All subsequent requests from MCP client to MCP server include Bearer token. Nothing in the flow here is MCP-specific, and that’s the beauty of MCP snapping to a common industry standard. There’s no need to reinvent the wheel because a robust solution already exists. Implementing authorization in MCP Most OAuth providers work well for MCP server authorization without any additional configuration, though one of the more challenging gaps today is the availability of Dynamic Client Registration. However, support for that feature is slowly rolling out across the identity ecosystem, and we expect it to be more common as MCP gains traction. Aside from the authorization server, when implementing authorization for your MCP server, you will need to consider several key components and behaviors: PRM endpoint. The MCP server must implement the /.well-known/oauth-protected-resource endpoint to advertise supported authorization server scopes. The MCP TypeScript SDK already integrates this capability natively, with other MCP SDK support coming very soon. Token validation middleware. You need to make sure that your MCP server is only accepting tokens meant for it. Many open source solutions, like PyJWT, can help you here by: Extracting Bearer tokens from Authorization headers Validating token signatures using your OAuth provider’s JSON Web Key Sets (JWKS) endpoint Checking token expiration and audience claims Ensuring tokens were issued specifically for your MCP server (this part is critical for the security of your infrastructure) Error handling. Your MCP server will need to return proper HTTP status codes (HTTP 401 Unauthorized for missing/invalid tokens, HTTP 403 Forbidden for insufficient permissions) with appropriate WWW-Authenticate headers. Anthropic, together with the broader MCP community, is working on integrating a lot of these capabilities directly into the MCP SDKs, removing the need to implement many of the requirements from scratch. For MCP server developers, this will be the recommended path when it comes to building implementations that conform to the MCP specification and will be able to work with any MCP client out there. Handling multi-user scenarios Multi-tenancy in MCP servers introduces unique security challenges that go beyond simple authorization and token validation. When your MCP server handles requests from multiple users — each with their own identities, permissions, and data — you must enforce strict boundaries to prevent unauthorized access and data leakage. This is a classic “confused deputy” problem, where a legitimate user could inadvertently trick the MCP server into accessing resources they shouldn’t. OAuth tokens are the foundation for securely identifying users. They often contain

What started in 2006 with just 40 farm families in western Kenya has grown into a powerful movement. Today, One Acre Fund serves 5 million farm families across ten countries in eastern and southern Africa. Their ambitious goal? By 2030, they aim to support 10 million farm families annually. How? By using open source technology and AI, aiming to generate an astounding $1 billion in new revenue for these communities. Cultivating impact with technology For smallholder farmers — those typically working with an acre or less of land — intensifying agriculture is crucial for their prosperity. This process of producing more food with the same amount of land, not only brings higher crop yields, but stimulates the economy, strengthens community, and enables farmers to scale. One Acre Fund’s core mission is to empower these farmers, providing a direct pathway out of poverty. But unlike traditional microfinance, they don’t just loan cash. Instead, they provide vital farm resources like fertilizer and seed, plus training and services, directly equipping farmers with the tools they need to succeed. They also help the farmers they serve to improve their soil health and plant trees to not only increase yields but also help farmers be more resilient to weather changes due to climate change. In the past, farmers used to fear using technology. But, as we provide training to them, they’re now eager to use it. Blaise Murame, Regional Lead, One Acre Fund Technology is at the heart of One Acre Fund’s rapid growth. They’ve transitioned from an entirely analog approach — meeting farmers in the field with paper records — to a highly digitized system. This transformation has revolutionized their operations, making everything from logistics and delivery to farmer registration and the development of training materials more efficient. Farmers, initially hesitant, are now eager to embrace this tech, after receiving resources and tools on time and achieving their goals faster than ever before. Growing products to empower farmers A significant part of One Acre Fund’s tech leap comes from their adoption of GitHub Copilot.  Since the coming of GitHub Copilot, the time it used to take us three weeks, that development work can be finished within a week. That’s affecting our goals – we’re able to set more goals than last year. Yididiya Gebredingel, Developer, One Acre Fund By introducing GitHub Copilot, One Acre Fund has been able to move much faster on their development, and they can focus on the pieces that are actually creating impact in the field. This acceleration has enabled them to set and achieve more goals, with developers completing projects three times faster and over 30% of their work being assisted by AI. As a nonprofit, working with some of the world’s poorest populations means operating on razor-thin margins.This makes the cost-effectiveness of their solutions paramount. Open source technology provides the ideal balance, offering both “solution maturity and solution flexibility” without the burden of exponentially growing license fees as they scale. Embracing the open source community is a strategic move for One Acre Fund, as they’ve migrated most of their core operational systems to open source to leverage collaborative development and community support. As a nonprofit, we can’t tolerate license fees that will grow exponentially as we scale. Open source gives us the right balance between solution maturity and solution flexibility. Sarah Hylden, Global Director of Operations, One Acre Fund Ultimately, One Acre Fund believes that if you have an intervention that works to create a sustainable pathway out of poverty for farmers, and you know it works, then you have a moral obligation to scale it. And with the help of GitHub Copilot, they are doing just that — moving faster and making a greater impact in the lives of millions of farm families. Explore a better way of working by trying GitHub Copilot for free today, or if you’re a nonprofit organization, check out GitHub for Nonprofits for exclusive discounts. The post Scaling for impact: How GitHub Copilot supercharges smallholder farmers appeared first on The GitHub Blog. ​ Open Source, Social impact, GitHub Copilot The GitHub Blog

Running the Model Context Protocol (MCP) server locally works, but managing Docker, rotating access tokens, and pulling updates is a hassle. GitHub’s managed MCP endpoint eliminates these infrastructure headaches, letting you focus on what you love — shipping code. In this 201-level tutorial, we’ll walk through upgrading from the local MCP setup to GitHub’s managed endpoint. You’ll get OAuth authentication, automatic updates, and access to toolsets that open the door to richer AI workflows you simply can’t pull off with a bare‑bones local runtime. You’ll also learn how to customize tool access with read-only modes, streamline your AI workflows with dynamic toolsets, and get ready for agent-to-agent collaboration using GitHub Copilot. The GitHub remote  MCP server is GitHub’s fully hosted, always‑up‑to‑date implementation of MCP Instead of wrestling with Docker and personal access tokens on your machine, you point your IDE or agent host to https://api.githubcopilot.com/mcp/ and authenticate once with OAuth. GitHub handles the rest. With our server, we enable the following toolsets by default, but you can disable anything you don’t need with a simple flag when you start the server:  Repository intelligence: Search code, stream files, and open pull requests without a local clone. Issue and pull request automation: File, triage, label, review, and even merge from a single agent prompt. CI/CD visibility: Inspect workflow runs, fetch logs, and re‑run failed jobs right inside chat. Security insights: Surface code scanning and Dependabot alerts so fixes land before exploits do. Fine‑grained controls: Toggle specific toolsets or flip the server to read‑only for extra safety. Get started > But first, why switch to our hosted server?  Running the open source MCP server locally works, but it carries hidden costs. Here’s what changes when you go remote: Local Docker server Hosted MCP endpoint Maintain a Docker image, upgrade manually GitHub patches and upgrades automatically Manage personal‑access tokens (PATs) Sign in once with OAuth; scopes handled for you Expose the server on localhost only Reachable from any IDE or remote‑dev box Full write access unless you customise the binary Built-in read‑only switch and per‑toolset flags If you need an air‑gapped environment, stick with local. For most teams, the hosted server eliminates infrastructure work and lets you focus on automation. With that, let’s dive in. A few things you need before you get started: GitHub Copilot or Copilot Enterprise seat VS Code 1.92+ (or another MCP‑capable client) Network access to https://api.githubcopilot.com A test repository to experiment with Step 1: Install the remote MCP server Setting up GitHub’s remote MCP server server is a breeze compared to local Docker-based installations. Hosted by GitHub, it eliminates the need for managing Docker containers or manually handling updates, offering a streamlined, cloud-native experience. How to install the remote server on VS Code or VS Code Insiders: Open the command palette and run:> GitHub MCP: Install Remote Server Complete the OAuth flow to connect your GitHub account. Restart the server to finish setup. For any other client Set the server URL to: https://api.githubcopilot.com/mcp/ Then authenticate when prompted. Validate your connection with a quick check curl -I https://api.githubcopilot.com/mcp/healthz # HTTP/1.1 200 OK If you see 200 OK, you’re good to go. Once installed, the remote server replaces the local one, and you’re ready to roll. That means no more Docker or tokens, just a simple integration. Step 2: Configure access controls Use read-only mode for safe exploration. Working in a sensitive environment? Testing in production? Demoing to stakeholders? Flip the server to read-only mode: { “servers”: { “github”: { “type”: “http”, “url”: “https://api.githubcopilot.com/mcp/”, “mode”: “read-only” } } } The agent can read issues, pull requests, and code but can’t push changes. Perfect for code reviews where you want context without risk. Use case: Pull request viewer Need to review pull requests without modifying anything? This setup gives you safe, read-only access — perfect for browsing changes, leaving comments, or gathering context without risk of altering code. Go to the GitHub MCP server repo. Navigate to the “Remote Server” section. Choose the pull request read-only variant. Click Install Read Only. You’ll now see tools like listPullRequests, getPullRequest, and searchPullRequests, but no write access. And since these tools don’t make changes, VS Code skips the permission prompts for a seamless experience. Limit scope with selective toolsets Keep both developers and agents focused by exposing only the tools you need with the following command: “toolsets”: [“context”, “issues”, “pull_requests”] Add this array next to the mode field to hide everything else. Step 3: Try it out with these three hands-on examples Want to see how Copilot agent mode works in practice? These real-world examples show how the agent can handle everyday developer tasks — like managing pull requests, debugging workflows, and triaging security alerts — without needing local setup or manual digging. Just prompt and go. Example 1: Add a CODEOWNERS file and open a pull request Open your repo ➜ Ask Copilot Agent. Prompt your agent: “Add a CODEOWNERS file for /api/** assigning @backend-team, then open a draft pull request.” The agent will: Use repos.create_file to add the CODEOWNERS file. Call pull_requests.open to create the pull request. Execute pull_requests.request_reviewers to assign reviewers. No local cloning, no manual file creation. Just prompt and ship. Example 2: Debug a failed workflow Prompt: “Why did the release.yml job fail last night?” The agent pulls logs with actions.get_workflow_run_logs, analyzes the stack trace, and suggests fixes. It’s like having a senior engineer review your CI/CD failures. Example 3: Triage security alerts Prompt: “List critical Dependabot alerts across all my repos and create issues for each.”  The server returns alerts via dependabot.list_dependabot_alerts, then the agent creates focused issues only where needed. Step 4: Troubleshooting tips with the GitHub remote MCP server  Symptom Likely cause Fix 401 Unauthorized on install Left‑over GITHUB_TOKEN env var Unset the var and rerun OAuth flow Tools don’t appear Corporate proxy blocks api.githubcopilot.com Add proxy settings or allowlist the domain Model times out Large toolset enabled Restrict to needed toolsets only Step 5: Streamline your workflow with dynamic toolsets The full MCP server includes over 70 tools, and, while