For GitHub, our MCP journey started well, at least in public in April last year. And we actually open-sourced our local MCP in April last year. And we've just turned 1 year's old. Back then, there was a tremendous buzz. We were the most starred repo on GitHub of the particular week. And the exposure meant we got a high volume of public contributions, rapidly filling gaps in platform coverage.

After a month or so of new features, agents in some ways were getting worse at using GitHub and context windows were getting blown out quicker. And we picked, I think, over 100 tools. And certainly at the time, that was just too many. LangChain had already produced research that more tools don't make better agents, you know, they get confused and forgetful. Well, I say more tools like more context and more tools shoved directly into the context to be precise. GitHub's a really expansive platform. And we provided tools for repos, issues, PRs, actions, projects, like even more things.

To try and fix some of this, I quickly added this thing tool sets, which was a kind of grouping concept of related product tools. And users could pick which ones they wanted and configure it. I also added a dynamic tool selection thing where agents could discover sets of tools and then turn on in chunks. And we never released it, but I made a kind of rag version of the same for semantic tool search and discovery.

Everyone used the default settings. It was really annoying because we had all these elegant solutions. All they did was require users to actually configure the JSON a little bit. And most users just don't. We needed to find better solutions to context reduction. Initially, we cut the amount of context used by focusing the tools more specifically to the general case, leading to about 49% reduction of the initial load. And then we subsequently also grouped CRUD tools and brought that down even more. We've also recently had a massive push to reduce output tokens of a lot of tools. In this example, just by tailoring exactly what comes with the list pull requests, it's actually lost more than 75% of the tokens used in the output.

We made a big push to reduce tool failures as well. And the success rate is roughly, I think, over 95% at this point. Not all failure is preventable cuz agents don't necessarily know which repos they have write permission on. They still hallucinate. But we've been able to identify significant numbers of areas that could be overcome, mostly by encoding a sort of agent intent into our tool surface. You might have to make five API calls to make it more robust. But we do that in the server side to reduce round trips cuz that saves context, saves time, and makes a massively better experience.

One of the gists is instead of micro-optimizing individual tool descriptions, you try to test them against each other to try and make sure that they're called at the right times and not called at the wrong times. The perfect tool description that makes the agent call it all the time is terrible as is the reverse of that.

Security is a kind of constant menace in all of this. We've a lot of people using plain text access tokens for MCP in the wild. They're frequently long-lived. They're often over-privileged. And they're kind of sat there just waiting to be abused. Our remote server supports OAuth 2.1. And my team even helped add the proof key for code exchange support (PKCE) to GitHub's authorization server to improve the security posture.

On OAuth, we support step-up OAuth. We could return a scope challenge and then it will interactively ask the user if they want to allow the scope. And if you do, then you can continue the tool call. It doesn't fail. If you log into GitHub MCP with a PAT token, we immediately filter the tools down by the scopes that the token has. By removing those, we're just removing kind of constant sources of failure and wasted context at the same time.

We run a completely stateless server setup and we have been using Redis for session storage. One of the fun things we did is we actually make a brand new in the SDK sense a brand new server instance on every single request and we add the tools to it at the start. So, whatever your configuration is, it just builds this and then you get what you've asked for. We serve around 7 million tool calls a week. We don't have session affinity.

We have this thing that's a Insiders mode. An example of something that we haven't released generally yet is our MCP apps. It's quite nice when you're talking to the agent to have the opportunity to kind of edit the AI-generated issue especially if you're working heavily in professional open source stuff and you want to make sure that it's you posting and it's not going to get closed as a bot-generated thing. This is a nice human in the loop thing that MCP enables.

I think a near future, server discovery will hopefully be automatic and tool use will probably become more compositional like bash or piping tools into other tools, streaming data through them. I fully expect that like thousands of tools will be normal very soon. I'll probably reverse many of the fewer tools decisions. And users hopefully won't even have to know what MCP is. They'll just convey what it is they want to do and the OAuth setup and the tool selection things will become truly autonomous.

GitHub itself has got over 11 million Docker downloads of our standard IO server. We've got almost 4,000 forks which blows my mind. Nearly 30,000 stars and we're fast approaching 8 million tool calls a week. This is really intense, right? And it shows no sign of slowing down. I would encourage people to experiment with crazy clients. You never know, you could publish something that goes so viral it totally changes the agentic game.