How Model Context Protocol Fixes AI's C++ Tool Problem

AI coding assistants have gotten pretty good at suggesting code. They've gotten decent at understanding context. But ask them to actually use your C++ tools—your compiler settings, your build system, your specific debugging workflow—and things fall apart fast.

Ben McMorran, a principal software engineer at Microsoft who works on AI-powered developer experiences, gave a talk at CppCon 2025 that maps out both the problem and a potential fix. The problem: every AI chat interface has its own way of connecting to tools, which means n chat interfaces times m tool providers equals a lot of wasted engineering effort and a fractured ecosystem. The fix: Model Context Protocol (MCP), an open standard that's trying to do for AI tools what Language Server Protocol did for code editors.

Let me explain why this actually matters.

The evolution nobody asked for but everyone got

McMorran walked through what he calls "a brief incomplete history of large language models and developer tools," starting with ChatGPT's launch in November 2022. Back then, if you wanted AI help fixing a unit test, you copied your code, pasted it into a web interface, got a response, and manually applied whatever changes seemed reasonable.

By early 2023, IDEs started embedding chat directly. Instead of copy-pasting, you could reference files: "Help me fix this test, I have this calculator file." The IDE would grab that context, bundle it into a prompt, and send it off. Better, but you still had to explicitly tell it what to look at.

Mid-2023 brought automatic context collection (RAG, if you want to sound technical about it). The AI could find relevant files on its own. But here's what McMorran pointed out: "What we've ignored so far is the entire rest of the inner loop. All we have is answering questions. The user still has to edit the unit test themselves. They have to build. They have to verify that the fix actually works."

By late 2024, we started seeing actual coding agents—AI that could semi-autonomously handle simple tasks. Edit a file, run a build, see it fail, edit again. The key technology enabling this: tool calling.

Tool calling is weirder than it sounds

Tool calling (also called function calling, depending on which vendor you ask) is how LLMs can actually do things instead of just talking about them. A tool has two parts: metadata (name, description, parameters) and an actual function that implements it.

McMorran showed a toy example—an "add" tool that takes two numbers and adds them. The metadata tells the model what the tool does. When you ask "what is 37 plus 94," the model recognizes it should use the add tool and outputs a special token sequence requesting it. The client runs the actual addition function, gets 131, and feeds that back to the model, which then completes its response.

The critical insight: "LLMs have been trained to understand tool calls. They're able to output special token sequences that indicate they would like to invoke a tool or they are receiving the result of a tool call."

With just two tools—one that edits files and one that runs terminal commands—you have enough to build a feedback loop where the AI can iterate on its own mistakes. Run a build, see an error, fix it, try again. That's genuinely different from chat.

The fragmentation mess

So IDE vendors realized this was powerful and started making their tool interfaces extensible. Great, right? Write your custom tool once, use it everywhere.

Except that's not what happened. VS Code has its way of integrating tools. Visual Studio has its way. Claude has its way. GitHub Copilot has its way. If you want your compiler flags tool to work across all of them, you're writing it four times (at minimum).

This is where Anthropic looked at the landscape in November 2024 and said: we've seen this movie before. McMorran put it directly: "Because this is a DevTools conference, Keen Observers might note that this looks very similar to the problem that LSP is trying to solve, just we would have editors and language servers instead of what we're now calling MCP clients and MCP servers."

MCP aims to be that standardization layer. Write your tool as an MCP server once, connect it to any MCP client. The protocol uses JSON-RPC over stdio (or HTTP if you're hosting in the cloud), which means the client and server can be written in different languages.

Live demo: connecting Compiler Explorer to AI

McMorran's demo was delightfully specific: he had a simple C++ function that triples values in an array, and he wanted to know if MSVC would vectorize it. He asked GitHub Copilot. It gave him... a wall of text with a qualified "I think it probably does. Maybe it doesn't. I'm not really sure."

The AI couldn't actually answer because it didn't have access to the assembly output. But Compiler Explorer could provide that. So McMorran built an MCP server (live, in the talk, which is either brave or reckless) that calls the Compiler Explorer API.

The implementation is remarkably straightforward: define metadata (tool name, description, parameters), write a function that calls the Compiler Explorer API, register the tool. That's it. About 50 lines of C++ using a community-maintained CPPMCP library.

He tested it using Anthropic's MCP Inspector—a debugging tool that lets you interact with MCP servers visually. Sent a trivial function, got back assembly. It worked.

Then he connected it to VS Code via an mcp.json config file, asked the same question about vectorization again, and this time the AI immediately recognized it could use the get_assembly tool. It called Compiler Explorer, got actual assembly output, and gave a real answer based on evidence instead of vibes.

What's actually interesting here

I think there are two things worth sitting with:

First, the barrier to making your tools AI-accessible just dropped significantly. If MCP gets adoption, you write it once. Not once-per-IDE, once-per-AI-vendor—just once. That's meaningful for niche tools, internal tooling, anything that doesn't justify n implementations.

Second, McMorran noted something important: "Before you go write your own MCP servers, check if someone already did it for you." VS Code has a marketplace now. There's a growing registry of official MCP servers. The network effects could be real if this actually takes off.

But (and this is crucial) McMorran also acknowledged: "It is charitably early days for writing MCP servers in C++. Unfortunately there is not an official Anthropic SDK for this. There is one for Rust." The C++ ecosystem is working with community libraries. The protocol isn't that complex—you could write it yourself if needed—but the tooling isn't mature yet.

The other open question: will MCP actually achieve the standardization it's aiming for? LSP succeeded because Microsoft put serious weight behind it and the value proposition was obvious. MCP is an Anthropic initiative, and while other vendors are showing interest, we're still in the "wait and see" phase. The n×m problem is real, but so is the coordination problem of getting everyone to adopt a standard.

McMorran made the technical case clearly. Whether the ecosystem follows is the interesting part we don't know yet.

—Yuki Okonkwo