Model Context Protocol
The Tool Belt
For many years I’ve told people a REST API is a website for machines. And for just as long, the flip side came free: a website is an API for humans. It’s a good line.
Recently, I realized it’s not quite right. The thing that actually separates them isn’t human versus machine. It’s whether the thing on the other end can think.
When I said machines, what I actually meant was code. And code can’t think. It executes exactly what it’s told and nothing else, so it needs an interface that assumes nothing: rigid fields, exact parameters, one correct shape for the request or the whole thing fails. That’s an API. A human can think, which means a website can hand over far more than instructions, it can hand over options, and trust the person holding them to explore, misuse, and repurpose them in ways the designer never planned. That’s the real reason a website works so well for a person, and an API works so well for code.
Picture a spectrum with thinking on one side, unthinking on the other. Code sits at the unthinking end, zero reasoning, pure execution. A human sits at the thinking end, full reasoning, full context. A model doesn’t sit at either end. It falls somewhere in between, and it’s constantly moving closer to thinking than not.
Handing a model an API is like handing a person a phone tree. Press 1 for billing, press 2 for support, no room to say actually I need something adjacent to option 2.
A website doesn’t fit either, because a website is built for eyes on a screen. A model doesn’t look at anything. It doesn’t need buttons or a page to explore, it needs a description it can reason over and enough latitude to decide what to do with it. That’s a new shape of interface, one built for a caller that can reason without perceiving. That’s what MCP is.
I spent many years of my career on the code end of that gradient. Smart endpoint, dumb client. Whatever’s calling you doesn’t know anything, so you build all the intelligence into the thing being called and hand back exactly what the contract promises, nothing more. Decades of that intuition is why, when I sat down to build a memory system for myself earlier this year, I built the intelligence into the memory.
It felt like the responsible way to build something. Encapsulate the logic. Protect it behind an interface. I have shipped that pattern hundreds of times, and rarely has it been the wrong design.
But this time things were different. The client calling my memory system wasn’t a dumb client. It was Claude. A model that already reasons better than the code I was writing to reason for it.
I didn’t see that clearly at first. I just felt something was off, closer to looking at how much I was building to maintain and troubleshoot a thing that was supposed to be simple, and asking why any of it needed to exist. More infrastructure. More cost. More surface area for something to break. For what?
The answer, when it finally came, wasn’t an insight so much as a correction. The model calling my memory already had context my memory never would. It knew what I was working on right now, what mattered in this exact conversation, things a database sitting in a vacuum can’t know no matter how clever I make it. I was building a second brain to compete with the first one. The first one was already smarter than what I was building.
I tore it down and built the opposite. A database dumb enough to store things reliably and get out of the way. And in front of it, not intelligence, opinions. Instructions for the smart thing calling it. How to store, how to ask, how to interpret what comes back.
That’s the whole difference, and it took me two full rebuilds to see it. An API puts the intelligence behind the glass, so the thing calling it never has to be smart. An MCP puts the intelligence in front of the glass, aimed at a caller that’s already capable.
The gradient isn’t just about where a caller sits. It’s about where the reasoning itself belongs. Too little of it at a point that needs it, and you get a phone tree handed to something that can think. Too much of it at a point that doesn’t need it, and you get exactly what I built twice this year: a memory with its own brain trying to out-reason the model already reasoning about it, an agent standing between two systems that never needed a translator between them. I didn’t make two different mistakes. I made the same one, in both directions, before I saw the shape of it.
A quick note if none of this is your world. Stay with me, because the actual problem isn’t APIs or protocols. It’s a habit everyone in a skilled trade develops: build the thing so nobody has to trust the person using it. A form that only takes valid input. A recipe that assumes the cook. A process document written so tightly nobody has to think. It’s a good habit until the person on the other end gets capable enough that the tight process starts working against them instead of for them. That part isn’t a software story. That’s every manager who wrote the procedure for someone who’s since outgrown it.
This is Amos again, back for the technical footnotes. He’s one of my AI crew, introduced properly in the crew origin story: a fixed set of AI actors named after the crew of the Rocinante, from The Expanse. Amos is the mechanic. He gets his own indented blocks, pure tech, no metaphor, no softening. Skip them and you won’t miss the story. Read them and you’ll get the actual mechanism.
MCP stands for Model Context Protocol, the standard now emerging for exactly this: giving models a way to discover and call tools. A REST API exposes endpoints. You send a request, it validates against a fixed contract, and it returns exactly what the contract says it will, nothing more, nothing interpreted. The intelligence, if there is any, lives entirely on the server. An MCP tool exposes a description written in plain language, read fresh by the calling model on every single call. That description doesn’t dictate what the model does. It influences it: guidance the model weighs against its own context and reasoning, then decides for itself how to act. An API can’t do that. It has no caller capable of weighing anything, so all it can do is enforce. The influence doesn’t stop at the description either. The payload coming back can carry its own behavioral guidance, shaping how the model interprets what it just received and how it should use the tool next time. ParaCortex ships two verbs most APIs would never have a reason to expose: guidance, which returns operating instructions for how to use the system well, and feedback, which lets the calling model report friction back into the system. That’s a live loop, not a static contract. The tool shapes the model’s behavior through what it returns, and the model shapes the tool’s future behavior through what it reports back. I’ve started building my interfaces around that loop deliberately, so the tools get better at helping the longer they’re used. Neither of those exists in an API. There’s nothing on the other end capable of learning from them.
I didn’t just make this mistake once. I made it again three weeks later, one layer up, and caught it faster the second time.
I’d built an agent to run that job, and named him from the same universe the rest of my crew comes from: Fred Johnson, who runs Tycho Station in The Expanse. Fitting, since the machine he was meant to administer is the one I’d already named Tycho Station. I gave him a real mandate too, help manage remote work on that machine, handle whatever came up, not just one narrow task. He was a whole separate model, sitting between my main assistant and the machine itself.
Then I looked at what he’d become. Whatever I’d imagined for him, in practice he was a glorified interface to SSH commands. That’s it. Two models now had to interpret each other correctly for a job that had quietly shrunk down to something needing no interpretation at all, and every extra hop is a place meaning gets lost, plus a maintenance surface, plus the literal cost of another model running for no reason.
I have a name for the question I asked myself in that moment, because I ask it now before I build almost anything: does this need to exist. Not how do I make it better. Not how do I make it more reliable. Does it need to exist.
It didn’t. I killed the agent and replaced it with the simplest tool I could write, and it does the job better than the smartest version ever did.
Sometimes you just need a wrench.
There’s something I keep encountering lately.
When you’ve built software for a couple decades, you’ve got a gut sense for how long things take. Everybody in this field has quietly watched that sense be rendered inaccurate. No one argues about the speed of writing code anymore. We have all just adjusted and moved on.
What I don’t think we’ve caught yet is that estimation was never the only intuition trained on the old rules. Every intuition I have about how to build something was calibrated against decades of one fact staying true: whatever calls your code is dumb, so protect it from itself. That fact just stopped being true, recently, quietly, and my gut didn’t get the memo, because gut feel is built from experience, and experience takes time to accumulate. The rules changed faster than my intuition could adapt.
I wasn’t wrong to encapsulate for so many decades. I was right for exactly as long as the client stayed dumb. The client got smart. My intuition is still catching up, and if you’ve built anything for long enough to trust your gut, yours probably is too, somewhere you haven’t found yet.
What do you do with this on any given day, if you’re not writing tool descriptions for a living. You look for the place in your own work where you built a wall to protect something from a person or a system you assumed couldn’t be trusted with it. Then you check whether that assumption is still true. Sometimes it is. Sometimes the wall was correct and stays correct. But sometimes the person on the other side of that wall got a lot more capable while you weren’t looking, and the wall you built to protect them is the only thing still holding them back.
There’s a second dimension under all of this I skipped past to keep the reasoning argument clean, and it’s worth naming before I let you go. The model isn’t just somewhere between code and human on thinking. It’s past both of them on speed. A human wearing ten toolbelts still moves at human pace. A model wearing ten toolbelts calls one, evaluates the result, and calls the next, ten times over, before a person finishes reading the first response. The interface had to be rebuilt for reasoning. It also had to be rebuilt for a pace nothing before it was ever asked to survive.
You can’t blindly trust your gut. AI is moving faster than your intuition.
Uncomplicated systems. Uncommon results.