If you haven’t heard already, Model Context Protocol (MCP) is a new, standardised way that LLMs and AI agents can communicate with external tools. Lots of people in the AI community have been calling it a “USB-C for AI” because you only need one connector for many tools.

Today, however, I’m not going to go deep into the weeds about MCP particulars or what a typed JSON-RPC envelope is. Instead, I’m taking you on an adventure I embarked on a few weeks ago. It involved me talking to ZAP in plain English, going to get a cup of coffee, and coming back to a report on a vulnerable web application.

But before I embarked on my quest, I needed some equipment:

• An LLM: I went with Claude Sonnet 4, from Anthropic’s family of foundational models and the creator of MCP. 
• A way to interact with an LLM that can also use MCP servers: Conveniently, Claude has a wonderful desktop app that lets you do this easily.
• Some MCP servers: Most importantly, the Filesystem MCP server for the ultimate budget-friendly Claude Code imitation.
• An SDK to write my own ZAP MCP server, to avoid re-inventing the MCP wheel. The Python MCP SDK did nicely.

With these tools in hand, it was time to see how far I could take this idea, based purely on vibe coding.

Andrej Kaparthy, co-founder of OpenAI (the creators of ChatGPT) and coiner of the term, explains:

“There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists”.

Vibing responsibly

While it’s tempting to be allured by the simplicity of telling an LLM to “code me a ZAP MCP server” and have it produce lines of code, it’s generally in your long-term interests to have some understanding of what you’re trying to achieve.

Then, you can ask the AI to either expand on that understanding or formulate a plan before it attempts to execute. Don’t just take it from me; this is Anthropic’s first recommended workflow for using Agentic AI.

With responsible vibing in mind, I crafted a fairly simple exploratory prompt.

I want to create an MCP server for the open-source proxy tool ZAP. I know it already has a comprehensive Python SDK for interacting with it in an automated fashion. How could I leverage the existing SDK to create a ZAP MCP server easily?

Putting the code into vibe coding

I enabled Claude to read and write files using the Filesystem MCP to create the ZAP MCP server project.

In the long run, this saved a lot of time copying and pasting code back and forth between VSCode and Claude Desktop.

To do this, I just had to write a small bit of JSON to configure the Filesystem MCP so it knew what directories it could access.

Once I’d set that, I restarted Claude Desktop for it to take effect.

The next prompt was as simple as telling Claude where it should create the Python project, which version to use, and what configuration file to use for dependencies:

Use the fileserver MCP to create the necessary project and code files for this ZAP MCP project in the directory ~/Development/mcp/zap-mcp which you have access to. The project should use Python 3.12 and dependencies set up with a pyproject.toml.

And just like that, the AI is using one MCP to write another.

Vibe check

I love a YOLO code execution as much as anyone, but I decided to take a look at the project code it created, since I was running this directly on my personal computer.

The main file is 1200 lines of code! But why should I care if I don’t have to write or maintain any of it myself?

# Initialize MCP server
self.server = Server(“zap-mcp-server”)

I’m more interested in where the MCP stuff is actually happening. Here, the code initializes an MCP server, which makes sense, since I was trying to build one.

On line 4, you can see a decorator @self.server.call_tool() is used to handle when the function is called by an MCP client, such as Claude Desktop.

Interestingly, it chose to skip the higher-level @server.tool() function that handles all the boilerplate.

But again, why should I care if I’m not writing it?

The only other particularly interesting part is that the actual code to perform an action in ZAP is about three lines long. That’s because it’s leveraging the wonderful ZAP SDK, just like I planned in the first prompt.

Then there’s another decorator on line 4 of this code snippet. Again, the code used the lower-level decorator function list_tools() because it used call_tool() to explicitly list what tools were available from the ZAP MCP server to the MCP client.

Ultimately, this gave me more control over the input data – which was useful when interfacing with another SDK that was expecting certain types and structures like the ZAP one I was working with.

I quickly checked the code, and then I was almost ready to take this MCP server for a spin! There was just one last bit of JSON configuration to do. I had to specify how to run the server, and from what directory.

After one last restart of Claude Desktop, I was ready to make ZAP get to work, through the magic of plain English and MCP servers. Right…?

WRONG! Turns out the vibes weren’t checked well enough, and they went from being immaculate to immensely painful.

A fair few errors popped up before I could successfully get this to even run one ZAP command. So I manually fixed this code like a responsible developer kept feeding the errors into Claude until it fixed them. Which eventually gave me the ability to get the MCP tool working! 

Vibe code victory!

Key takeaways

I’ll leave you with a few lessons I took away from this project:

Vibe coding is more than just a meme. It has genuine uses, especially for prototyping.

• That doesn’t mean it’s capable of autonomously creating projects from start to finish that are ready for enterprise deployment (yet).
• “Context engineering” is just as important as a good prompt. Use tools such as Claude’s Project Knowledge to improve an LLM's domain knowledge.
  
  

MCP can be an incredibly powerful tool, but it doesn’t come without risks.

• You’re potentially giving information to parties that don’t have the same data privacy policies as the LLM you’re using.
• You’re authorizing actions on your behalf that you may not be aware of.

MCPs aren’t particularly different or difficult to build than to a normal client server architecture.

If you have a tool with an API, you’ll be surprised at how quickly you can turn it into an MCP server.

That’s it! Thanks for coming on this adventure with me. I hope you get inspired to start writing and using your own MCP servers.