GitHub MCP in Practice: New Protocol, Elicitation, and Stateless Servers

At a technical talk focused on MCP (Model Context Protocol), a GitHub engineer wearing three hats simultaneously — GitHub MCP Server developer, Copilot Agent Harness maintainer, and MCP protocol maintainer — shared his firsthand experience pushing MCP forward on three fronts at once: server, client, and protocol spec. These overlapping perspectives reveal where the real difficulties lie as MCP moves from experimentation to scale.

Three Hats: From Server to Protocol Spec

The speaker has been working on GitHub MCP Server for over a year and a half, while also responsible for Copilot's Agent Harness, CLI, and other infrastructure powering various Copilot Agents — and has become one of the MCP protocol maintainers. This cross-cutting experience spanning server, client, and spec gives him a perspective that no single role could provide.

He emphasized that working on the client side is precisely what makes extending GitHub MCP Server more interesting — the design trade-offs on the server side only become clear when you see how they play out in real client call scenarios.

To give client developers something to test against, he and his team shipped support for the new MCP spec on GitHub MCP Server about three weeks before the spec officially launched. The early release went smoothly and helped pave the way for ecosystem-wide migration.

Supporting the New Protocol Is Easy — the Hard Part Is How Wild Servers Fail

Pushing new protocol support into the Agent Runtime was not without its stumbles. He was candid: supporting the new protocol itself is straightforward, and the official SDKs are excellent. The real headache is the undefined behavior found in a large number of wild MCP servers.

Different servers fail in wildly different ways, with wildly different error messages. Their core strategy was simple: when in doubt, degrade and fall back quickly — avoiding a situation where users are stuck waiting because someone else hasn't finished migrating to the new spec. He was explicit that you can't expect the entire ecosystem to upgrade overnight.

The numbers suggest the fallback-and-migrate strategy is working: a few weeks ago, requests using the new protocol sat at around 3%; now that figure has climbed to roughly 20%, with traffic trending steadily upward and without causing many issues.

Practice Feeds Back into Spec: Skills over MCP and Server Cards

His real-world experience on the server and client sides feeds directly back into his third role as a protocol maintainer. He deliberately collects the problems and challenges that arise in production, treats them as opportunities to bring to the working group, and incorporates community input. Community-raised issues span authenticated servers and clients that haven't implemented specific features.

He believes that having practical experience running servers at scale — and actually shipping features in a client — is critical to understanding where things are genuinely hard. A few recent developments have him particularly excited:

• Skills over MCP was voted in as an official extension;
• Server Cards have been published and will enable native web discoverability for MCP.

He expects native web discovery to dramatically change how MCP is distributed and consumed.

---

Server Cards are a standardized document format in the MCP ecosystem that describes a given MCP Server's capabilities and metadata — similar to an OpenAPI spec for an API, or a listing page in an app store. They contain structured information such as the server's tool list, authentication methods, and applicable use cases, allowing clients or platforms to discover and filter servers before connecting. Native Web Discovery means that users or Agents can automatically locate an MCP Server deployed under a given domain via standardized web mechanisms (such as a Well-Known URL), without manually configuring a server address. This has far-reaching implications for how MCP is distributed: developers simply publish a Server Card to a standard path, and any client that supports the spec can connect automatically — similar to how a website exposes itself to crawlers via robots.txt or sitemap.xml.

Skills over MCP is an extension spec that standardizes the exposure of Agent capabilities as MCP tools, allowing Agents across different platforms to invoke each other's skills through a unified interface, promoting cross-system Agent interoperability.

Live Demo: From Native UI to Confirming Repository Deletion

During the talk, he ran a live demo using Copilot's auto model. When calling GitHub MCP, the server returned an MCP native UI that rendered his GitHub user card directly — not plain text.

He then had Copilot create a brand-new repository, pausing to note that even practitioners need to stop and rediscover their excitement when an Agent can spin up a whole new project in an instant.

The most compelling moment was the repository deletion demo. The confirmation dialog that appeared during deletion is exactly what MCP calls elicitation — the server initiating a question to the user. He had long wanted to replicate the github.com experience of requiring a user to type the repository name to confirm deletion, given how irreversible that operation is. This time, he finally achieved that same confirmation flow at the MCP layer using elicitation.

MRTR: Enabling Elicitation on Stateless Servers

The real technical core is the Multi-Round Trip Request (MRTR) introduced in the new protocol. Under the old spec, GitHub MCP and many other distributed MCP servers couldn't support elicitation, because doing so required cross-server communication to coordinate state and MCP sessions.

The elegance of the new mechanism is that the two requests in a single elicitation round trip can be handled by entirely different servers. The nonce and sealed portions are the key — the server can encrypt a piece of data that even the user cannot read, and have it travel alongside the metadata across multiple request rounds. This means:

• Sensitive values remain confidential and secure;
• The server can still be deployed in a completely stateless fashion across a large number of machines.

In plain terms: a tool can ask a follow-up question before completing. The Agent triggers a tool, the backend says "I need one more thing," asks the user, receives the answer, and then returns the final result. That "continuation" is actually the same tool being called again with extra metadata carrying the answer.

For those who haven't done server-side scaling, this change might seem unremarkable — but it's precisely what allowed the speaker to ship elicitation for his server without needing any cross-server state coordination on the backend.

---

Stateless Servers are a foundational design pattern in distributed systems: the server retains no context between requests, and every request is fully self-contained. The advantage is the ability to scale horizontally across any number of machines — simply add nodes to increase throughput, and no single node failure affects overall availability. Platforms like GitHub typically deploy MCP Servers behind a load balancer in front of many stateless instances, meaning two requests from the same session may land on completely different physical machines.

Traditional Elicitation (the server asking the user a follow-up question) requires subsequent requests in the same session to return to the same server to restore intermediate state — inherently at odds with stateless deployment. MRTR sidesteps this by encrypting state and externalizing it into metadata passed by the client: the server doesn't need to "remember" the previous state; it simply decrypts the sealed data sent along with the request to restore context. In essence, this moves "session state" from server memory into an encrypted, secure request payload — achieving both security and scalability.

The More Exciting Part Is the Ecosystem Spillover

His broader hope for MCP is that these more interesting features will gradually spread across the entire ecosystem: more people running servers at scale, more people actually delivering interactive Agent experiences at scale. In his view, these developments have the potential to push MCP further into the mainstream.

This talk makes clear that the key breakthrough for MCP right now isn't whether the protocol is technically impressive — it's whether it can run stably in real production environments that are stateless and horizontally scalable. The combination of MRTR, Server Cards, and the Skills extension is filling in the missing pieces toward that goal.