Taking apart the future
What I learned building MCP servers and watching Claude learn to use them
When I was eight my parents gave me a tape recorder for Christmas. But it wasn’t long before I took it apart to see how it worked. In those mechanical days there was more to see - and more to spring apart. And so, when I finally got it back together, the fast forward button and tape counter no longer worked. A small price to pay for a better understanding of the internal mechanism. And something my parents never needed to know about.
I wasn’t the first - and I won’t be the last. I’m sure many of you reading have done something similar. Understanding how things work is what engineering is all about.
It turns out learning about the internals of MCP servers is similarly fun.
The MCP protocol is delightfully simple. If you’re not familiar with it, then this Claude artefact explains it nicely. With pretty much all protocols there is a detailed specification that explains the data structures and flows. This is all defined up front - and can be pretty complex. Take the T.128 (multipoint application sharing) spec - it spells out how ASN.1 packed encoding rules are used to tightly encode information. I know from personal experience decoding T.128 is hard…
But MCP is different. Sure, the flows between client and server are defined. And so is the discovery mechanism (i.e. list the tools the MCP server provides). But the details of the tools? That’s dynamic. The MCP server tells Claude what tools it has and how to use them. And then Claude learns from those instructions.
Change the server implementation and the client will dynamically adjust. This is cool thing number one.
It’s not perfect, though. I decided to make the file read/write interfaces in my sandboxed file/command MCP server (mdmcp) richer. Adding function for tail/head plus text/binary plus offsets and lengths seemed like a good idea. But the JSON got too complex for Claude. Here’s it trying to set the mode parameter to tail.
Claude is struggling. And looking at the JSON Claude is sending it is indeed failing to see the mode to tail:
And Claude realises that it is failing to set the parameter correctly - but seems powerless to fix it. It was persistent though - it spent a good five minutes struggling before giving up.
The solution leads to my first lesson.
With MCP multiple simple things are better than one complicated thing. Split complicated tools into multiple simple ones.
Another cool thing
So how do you test your MCP server? mdmcp has some familiar types of testing - UTs, FVs E2E testing. But I also got Claude Desktop to test it. Ultimately Claude is the client which matters most.
And it found some bugs:
Not only can Claude Desktop test the command, but it can provide feedback on why it ran into problems. Or what other commands might be useful.
That’s lesson two - get feedback direct from your target audience.
Documentation
In-context learning is a powerful way of teaching a model within a session. Give a model a set of examples and it can spot the patterns - learn - from those examples. This works just the same with MCP models. Providing detailed command help and examples during tool discovery helps Claude use those tools (although Claude Desktop can be remarkably persistent at trying to figure out how to make a tool work).
So mdmcp now caches a set of help for all configured commands. This is generated on install, update or when tools are added. And the information is given to Claude when mdmcp starts up.
I’ve also updated my plugins (which provide access to Slack, Confluence, Outlook email, Outlook calendar and Jira) to provide detailed examples - again to help Claude.
That’s lesson three - don’t skimp on the documentation.
And so?
Giving Claude sandboxed access has been interesting. For the first time I’m willing to let Claude use system analysis tools. It’s used ping to monitor my network. Tasklist to look at running processes. Systeminfo to understand my computer configuration. We’re getting to the point where Claude + MCP could help diagnose configuration problems and suggest solutions. The next time my machine starts crashing, I’ll give Claude the necessary tools and let it loose.
Some things become natural very quickly. Claude is now my interface to my calendar. When I want a summary of overnight email, I turn to Claude. It summarizes long, rambly email trails. It can find the list of emails languishing in my drafts folder and help me work out how to prioritize.
Need a small utility? Claude and mdmcp just build it. For example, try this prompt:
Build a command line tool which can count lines of code in Rust code files. Ensure it has sensible input and output. Include comprehensive UTs. Ensure the code builds cleanly with no compile warnings. And Cargo fmt & clippy are clean.
Claude and mdmcp work together for a few minutes and then return with a working tool:
Interested in retro-computing but struggling to configure your old VAXstation? Put the machine on the network, give mdmcp telnet access, point Claude at the Digital docs and away you go. No more trying to work out how $AUTOGEN configures the number of global pages or quorum votes.
And imagine future products that have MCP servers built in. Want to explore the configuration? Look at logs? Connect dots between different things? A MCP based diagnostic console will be amazing. And a little scary. Perhaps not something for production just yet…
The way we interact with our computers is starting to change. Dealing with email & calendar via text (or voice) is far more natural than wrestling Outlook. Sure, you need to build trust. And the tech isn’t perfect. But the direction of travel is clear.