MCP Is Dead Simple. And That's Exactly the Problem - DEV Community

Production gaps like safety and idempotency
What exactly is MCP? Is it some mysterious technology that requires secret knowledge to implement? Sometimes, when I read tutorials, I get that impression! Meanwhile, the basic concept is ridiculously easy to understand, and you can get a simple implementation running in minutes. The complications start later. And oh boy, there are quite a few of them!
This article is a follow-up to my previous post, The Dirty Secret Behind AI Agents (Demo). Back then, I promised you I'd write another part about MCP soon. And look, it only took me four months! 😂 If you're interested in building an agent, feel free to go back to that article. But if you only care about MCP, you can happily keep reading.
I won't pretend that the upcoming AI Coding Summit in Berlin, where I'll be speaking about this very topic, didn't motivate me to finally finish it. I'll leave a link to my speaker badge at the bottom of the article. Apparently, it gets you some discounts or even access to free videos!
In the previous post, I explained that an AI agent is such a simple concept that you can build one in about 80 lines of code. MCP isn't all that different. My handful of tools takes around 150 lines of repetitive code, and the client side adds another hundred or so. ;)
But let's start at the beginning!!!
MCP stands for Model Context Protocol. And as the name suggests, it's... a protocol. Just like diplomatic protocol or HTTP. In other words, we've agreed on a common way for AI applications to communicate with external tools and services.
More specifically, MCP defines how compatible clients can discover available capabilities, understand their input schemas, and call them without every application inventing its own integration format. MCP also supports things like resources and prompts, but today we're focusing on tools.
Sounds pretty straightforward, right? Let's see what it looks like in practice. And for that, we need to bring back an old friend.
You may or may not remember that in the previous part, I built an agent named Steve. Steve is a grumpy senior developer with 15 years of experience and a true master of code review.
He never takes anything on faith and always checks whether the code produced by a junior developer is about to cause some serious damage. @gramli and I briefly considered renaming him Grzegorz — a beautiful Polish name — but let's stick with Steve.
Now, one day, a new directive comes from above: HR wants more control over developers. Experienced seniors must regularly evaluate employees and, when necessary, file complaints against them or nominate them for promotion.
Our Steve, however, is lazy and has absolutely no intention of filling out any paperwork. Besides, he wouldn't even know how. He's an AI agent, after all, and before he can do something, he needs to know how to do it.
And that's where MCP comes in.
But first things first!
Repo: https://github.com/sylwia-lask/code-review-agent/tree/feat/steve-mcp-hr
As you can see, the MCP integration currently lives on a separate branch. If you like it, leave me a star! ☺️ And by the way, if you'd like to contribute to any of my GitHub repositories, please feel free to jump in! Especially the pinned ones. @nyaomaru has already started the trend, and I'd love to see more people join in! 😊 I think these projects could be a nice, beginner-friendly way to get started with open source. There's plenty to do, from fixing typos and improving documentation to adding entirely new features. All contributions are welcome!
In this case, our HR department is a simple little server with an SQLite database where we store complaints and requests to promote employees. The MCP server exposes four tools: get_employee_record, file_complaint, nominate_for_promotion, and get_hr_stats.
Oh, and take a look at how one of these tools is implemented on the server side. It talks directly to the database, so you can feel like you're back in a university programming lab. 😂 All that's left is to convince the teacher that the code actually works! 😅
That's it. We register a tool, describe what it does, define its input schema, and provide a handler. Nothing particularly mysterious here.
Of course, this is just a demo. In a production HR system, I'd be a little more careful about letting an AI agent write directly to the database. But where's the fun in that?
Steve, meanwhile, is a shining example of a modern self-healing agent architecture xD: he reviews himself — or, more precisely, his own repository.
That doesn't mean he wrote the code himself, though! In our .env file, we have the following variables:
And as you can see, we immediately know that the code was written by someone called Sylwia. Unfortunately, she isn't a particularly good developer and created this file:
As you can see, there's a whole collection of offenses here: SQL injection, any everywhere, and plenty of other sins.
Not exactly the kind of code you'd want to see in production. But perfect for a grumpy senior developer who desperately needs something to complain about.
Here's what happened when we ran our agent with the MCP server connected:
Well. That escalated quickly. 😂
Steve absolutely tore developer Sylwia to pieces and immediately reported her to HR. He didn't just identify the problems and suggest fixes. He actually called an external tool and created a new record in our database.
Let's see what that database looks like now:
Sylwia has officially made it onto HR's list of offenses! Everything works exactly as planned!
But before we celebrate our brilliant HR automation system, there's an obvious question we should probably address.
Some of you might be wondering: how is this actually different from calling an API? And that's a perfectly fair question. In this particular example, a regular REST API would have been enough!
The point is that MCP isn't a replacement for REST. REST is one way to design an application's API; MCP defines a standard interface through which AI