Let me tell you how the weekend actually went, because the tidy version people usually post afterwards leaves out the part that mattered.
I'm a business analyst. I don't ship production code, I don't own a repo anyone depends on, and for most of my career the honest division of labor was simple: I work out what needs building and why, and someone who writes software for a living builds it. That arrangement has served me well for years. So the obvious question, the one a colleague actually asked me on Monday, is why on earth I spent a perfectly good weekend fighting with a Model Context Protocol server on my own laptop instead of, you know, resting.
The short answer is that I wanted to stop talking about AI tooling from the outside. The longer answer is what this post is about, and it only makes sense if I walk you through what actually happened, mess included.
Saturday morning: how hard can it be
The plan was modest. Stand up a small local MCP server, the thing that lets an AI assistant reach out and use tools and data you define, and get it talking to a client. FastMCP, Python, my own Windows machine. A weekend project. I'd read enough to understand the concepts and I genuinely thought the building would be the easy part.
The concepts, it turns out, are the easy part.
MCP has a small, clean mental model once it clicks. You expose three kinds of thing to the model. Tools, which are actions it can take. Resources, which are data it can read. And Prompts, which are reusable instructions. What took me a while to properly absorb, and what I'd half-glossed over when I was only reading about it, is who's in control of each one. The application controls the resources, the model decides when to call the tools, and the prompts sit there as user-invoked templates. That distinction sounds academic until you're the one deciding what your server should actually hand over, at which point it stops being a diagram and becomes a series of real choices with consequences.
So far so good. I understood the shape of the thing. Then I tried to make my computer agree with me, and the weekend properly began.
Saturday afternoon: the environment fights back
Here is the part nobody puts in the triumphant LinkedIn post, and it's the part I now think is the most instructive.
I did not spend the weekend building an MCP server. I spent most of the weekend convincing my own machine to let me build an MCP server. The actual server logic, when I finally got to it, took a fraction of the time.
It started with PATH. Python was installed, but the terminal and I disagreed about where it lived, and that disagreement expressed itself as a cheerful little error every time I tried to run anything. Then, once that was sorted, I discovered that installing the base package wasn't enough. I needed the CLI extras, the mcp[cli] variant, and the reason my commands kept failing was that I'd installed the plain version and confidently assumed it included the tooling. It did not. That's an hour of my life I won't recover.
And then, just when I thought I was through it, the Inspector. The MCP Inspector is the little UI that lets you poke at your server and see whether it's actually doing what you think, and I could not get it to launch to save my life. The problem, it turned out, had nothing to do with Python or MCP at all. The Inspector runs on Node, and it wants npx, and my Node setup was its own separate adventure that I hadn't realised I'd signed up for.
I want to dwell on this for a second, because if you've never done this kind of thing, the temptation is to read the above as "he's not technical, of course he struggled." But that's not what this was. This is what building actually is, for everyone. The cascading, unglamorous, half-documented environment problems that stand between you and the interesting work are not a beginner's tax. They're the texture of the whole craft, and the people I've commissioned software from for years have been quietly absorbing exactly this on my behalf the entire time. I just never saw it.
Saturday night: it works, and something shifts
Late on Saturday, later than I'd like to admit, the Inspector came up. Green. Connected. My little server sitting there exposing its handful of tools, and the client reaching in and actually calling them.
I'd be lying if I said it wasn't a genuinely good feeling, the specific satisfaction of a thing that was broken all day suddenly working. But that wasn't the important part. The important part arrived a few minutes later, quietly, while I was testing it.
I found myself understanding, in my hands rather than in the abstract, what these systems can and cannot easily be asked to do. Where the friction lives. What's trivial to expose and what's genuinely awkward. Which of the "simple AI features" I'd cheerfully written into requirements documents over the past year were, in fact, simple, and which ones concealed a whole afternoon of the kind of nonsense I'd just waded through.
That's the thing I couldn't have bought.
What the weekend was actually for
I could have commissioned this. I could have written a crisp little brief, handed it to someone who does this every day, and had a better server built in a fraction of the time. That would have been the efficient choice, and if the goal had been to have a working MCP server, it would have been the right one.
But the goal was never the server. The goal was to no longer be the person who specifies AI capabilities they don't actually understand.
There's a failure mode I've watched play out again and again in this space, and I've been guilty of it myself. A domain expert who deeply understands the business writes requirements for something involving AI, and because they only understand it from the outside, the requirements are subtly wrong in ways nobody catches until much later. They ask for the thing that sounds reasonable rather than the thing that's actually feasible, because they have no felt sense of where the hard edges are. And the engineers, who understand the tooling but not the domain, build exactly what was asked for, which turns out to be not quite what was needed. Everyone did their job. The result is still wrong.
The only real cure I've found for that is to close the gap in yourself. Not to become an engineer, which I am not and don't intend to be, but to build enough, badly, to develop an instinct for the material. A carpenter's sense of the wood. After this weekend, when I write a requirement that touches AI tooling, I will know in my body which parts are a Saturday afternoon and which parts are a whole weekend of PATH errors, and that knowledge changes what I ask for and how I ask for it.
This is the same argument I keep making in different forms, that the domain person who can only describe the thing is quietly losing ground to the one who can also, however roughly, build it. I don't think that's because building is glamorous or because everyone should learn to code. I think it's because commissioning something you don't understand is a bet you place with someone else's expertise, and you can't tell a good bet from a bad one if you've never held the material yourself.
Was it a waste of time
My colleague's question, gently implied, was whether a BA fighting with npx on a Saturday night was a good use of a scarce weekend.
Here's my honest answer. As a way to acquire a working MCP server, it was wildly inefficient and I'd never recommend it. As a way to stop being fluent-sounding and start being actually fluent, it was the most useful thing I've done for my work in months. The server I built is trivial and I may never run it again. The instinct I built while building it, I'll use in every requirements conversation I have from now on.
The weekend wasn't about the server. It was about earning the right to have an opinion.
If you work in a domain and you keep specifying things you've never built, I'd gently suggest you find your own version of this weekend. Pick something small and current and slightly beyond you, and go and struggle with it until it works. Not to add "developer" to your title. Just to feel the material with your own hands, so the next time you write down what someone else should build, you're writing from knowledge instead of from a diagram.
The PATH errors are annoying. The understanding on the other side of them is not for sale.