MCP Protocol: a new AI dev tools building block
👋 Hi, this is Gergely with a subscriber-only issue of the Pragmatic Engineer Newsletter. In every issue, I cover challenges at Big Tech and startups through the lens of engineering managers and senior engineers. If you’ve been forwarded this email, you can subscribe here. MCP Protocol: a new AI dev tools building blockThe Model Context Protocol that extends IDEs’ AI capabilities. It’s gaining rapid popularity – why is this, and why should us developers pay attention to it?
Before we start: this is the last week of the “What’s in your tech stack?” survey. If you’ve not yet done so, please fill out this survey and tell us about it. If you take part and fill out the survey, you will receive the full results early, plus some extra, exclusive analysis from myself and Elin. (Full results, minus the exclusive analysis will be published in The Pragmatic Engineer). It takes as little as 5 minutes to fill — thank you for your help! One hot topic at the intersection of AI coding tools and developer tooling has been the MCP Protocol (Model Context Protocol), introduced in November 2024 by Anthropic. It has exploded in popularity, with AI models and developer tools keen to add support for it. An analogy for MCP is that it’s a “USB-C port of AI applications”, in that it creates a universal extension point for LLMs and dev tools to connect to each other with; databases, ticketing systems, etc. The concept is becoming popular in other areas, but MCP began as a way to extend the capabilities of developer IDEs like Claude Desktop, Claude Code, VS Code, Cursor, Windsurf and others. Today, we focus on this area, covering:
For this piece, I talked with MCP co-creator, David Soria Parra, software engineer at Anthropic. Thank you for the input! The bottom of this article could be cut off in some email clients. Read the full article uninterrupted, online. 1. What is MCP? A practical exampleI have an API that powers this microsite where annual paid members can request a promo code for 12 months of complimentary access to Perplexity and 3 months of Kagi. The site runs on Node.js, using TypeScript, and uses PostgreSQL as its database. Whenever I tweak the back or frontends and modify data, I have two things open:
IDEs are getting ever smarter with LLM functionality; Windsurf and Cursor have agentic capabilities, so can suggest edits to multiple files at once. However, they cannot connect to my PostgreSQL database to query data. But with MCP, they can – and so can I. MCP stands for Model Context Protocol, and is a bridge to allow LLM tools such as AI-enhanced IDEs like Cursor, Windsurf and others, to access additional tools. Here’s how I use LLM prompts to make my database accessible inside of my IDE. For this example, I used Windsurf, but the same can be done in Cursor, Zed, and VS Code. Adding a PostgreSQL MCP Server to my IDETo start, in Settings, under Cascade (Windsurf’s agentic capability), I select “Add MCP Server.” Here, a dropdown with pre-built ones are shown:
Adding it means configuring the connection string to your database, which can be to a local Postgres database running on your machine, or remotely. I used a remote connection string to connect to the one on my server. Once added, the connected database shows up as an MCP Server, ready to use:
Going forward, for any command inputted to the Cascade interface, the LLM can decide to use this server. Let me start with a question about promotional codes:
The LLM tries to generate an SQL server to get the answer, but hallucinates the table name (which is typical-enough for LLMs):
However, this is where the “magic” begins, thanks to the LLM iterating more — using this new database tool it can utilize. The LLM turns to my PostgreSQL instance to find the correct table name:
It then makes another query:
D’oh! – the column names are wrong, again! But it queries the table definition and corrects it rapidly:
Finally, it gets it right:
What’s so impressive is that the process took a few seconds, and I never had to add any input. The LLM “figured out” the correct table and column names by having access to the database. LLM layer above PostgreSQLNow I’ve added my database as an MCP server, I can “talk” to my data using natural language, and the LLM does the conversion to SQL, and then re-converts to my question. This is not limited to simple questions with a simple SQL query, but also to more ambiguous ones. Other questions I’ve asked:
Being able to converse with dev tools through my IDE feels like “the future”. It’s not that I couldn’t find answers to the questions above without it; I could have written SQL commands, or a series of them, or a small program to loop commands, and summarized them. However, I probably wouldn’t bother because it takes time to type out SQL. But because I can easily type questions, I did! Think about what happens when you can “talk” to your developer tools via the IDE. For example, using natural language to interact with:
It makes work easier to be able to use these tools from the IDE. Also, if we can use them, then so can AI agents, meaning they can do more complex tasks. It feels to me that the MCP concept could be another step forward for developer productivity. It will likely also boost AI agents’ capabilities because they have extra tools for more complex tasks. It’s hard to foresee commercial vendors not scrambling to add MCP servers, which will let customers use tools more easily from IDEs. As developers, we’ll be able to experiment with tools to make us more productive. A caveat is that the MCP is still early-stage and lacks vetted marketplaces, support in IDEs for MCP is barely a few months old, and also MCP implementations have many worrying security gaps – covered in “Security threats” below. 2. Origin of MCPThe MCP protocol was conceived and built by two software engineers at Anthropic, David Soria Parra and Justin Spahr-Summers. David shared the origin story in a Latent Space podcast episode:
While mulling this problem, I was working on a Language Server Protocol (LSP) project internally – and this project did not go anywhere. But put these ideas together; an LSP, plus frustration with IDE integrations, let it cook for a few weeks, and out comes the idea of ‘let’s build some protocol to solve for it.’” Open sourcing the MCP protocolDavid teamed up with fellow engineer, Justin, and they built early prototypes, kept iterating, and six weeks later had the first working MCP integration for Claude Desktop. They shared the prototype internally, and engineering colleagues at Anthropic were excited. While preparing to open source the protocol, people built a variety of interesting applications at an internal Anthropic hackathon, including an MCP server controlling a 3D printer. It confirmed David and Justin’s sense that MCP could be very useful in the real world. They did more polishing and announced the open sourcing of the MCP Protocol on 25 November, last year. At that time, MCP protocol was:
Rapid industry adoptionIn just four months, MCP went from being a neat protocol that Claude Desktop used, and which was open sourced, and to all major IDEs, with AI tools adding MCP support, including OpenAI:
The only notable IDE currently absent is JetBrains IDEs, which is set to introduce MCP support in the next IDE release, expected soon. It’s rare to see such fast adoption across all major IDEs. Clearly, MCP is providing a big benefit for developers using AI tools, so IDEs want to add it. Coincidentally, the top IDEs that engineers most frequently mentioned as IDEs with AI functionality they love – Cursor, VS Code, Windsurf, Zed, Neovim and Cline – have all been amongst the first to ship MCP support! But how do they work? 3. Understand LSP to understand MCPLet’s take a diversion into the world of Language Server Protocols because this is the solution that inspired MCP. A common problem that IDEs had for decades was that they wanted to add support for as many programming languages as possible, which also meant adding support for things like:
Assuming there are M IDEs out there, and N programming languages, this is an MxN problem. The naive solution was for each M IDE to build manual support for each N language, as best as possible. For IDE vendors, this was a lot of work, and work that must be repeated whenever a new programming language starts to spread:
For us developers, this meant IDEs only supported only a limited number of languages well. For example, good luck trying to code using C# in Android Studio! Extensions / plugins are a workaround for an IDE to do the heavy lifting: IDEs supporting extension/plugin frameworks could have third-party developers build plugins like syntax highlighting for a specific language. This is better than nothing, but is a lot of work for devs. Also, many IDEs don’t provide extension capabilities that offer a pleasant developer experience for things like autocompletion and syntax highlighting. In 2016, Microsoft released the Language Server Protocol (LSP) specification, a protocol originally developed for Visual Studio Code. The idea is that for each language, an LSP server implementation can provide language features. Editors could now use the LSP server – an existing implementation that’s often open source – not build their own:
This transformed how many IDEs are developed:
Today, IDEs that support LSP include:
Notable absentees include:
4. MCP architectureWhat David and Justin took from the success of LSP was that the protocol allowed:... Subscribe to The Pragmatic Engineer to unlock the rest.Become a paying subscriber of The Pragmatic Engineer to get access to this post and other subscriber-only content. A subscription gets you:
|
Comments
Post a Comment