PullMD Part 7: The MCP Server – Simply Explained
On the evening of March 2, in the very first planning chat for the project, there is half a sentence: “MCP later.” Then nothing happened with it for seven weeks.
In my head I had ticked the matter off at some point anyway.
On April 25 I asked Claude:
“How do I set it up in Claude Code or other AI agents, I think it’s an MCP right?”
It wasn’t one. It was an ordinary web interface with a skill next to it. The two together did the job well enough.
A skill, for context, is like a short note pinned to the AI agent’s desk. It tells the agent which tool to reach for, and when. There is more on that in Part 4.
My first reaction: then the skill is enough. Build a help page, offer a download, done. That’s Part 6.
Why I Started Half an Hour Later After All
Then, while writing the instructions, one argument turned the whole thing around:
“So quite concretely: the MCP would be good, because we already have a server running anyway and users then wouldn’t have to handle skills, and when something changes on the server all clients automatically have the new code… or what speaks for/against it?”
That’s the entire point. The server is already running. If it offers the tools itself, nobody has to download a file, unpack it, and put it in the right place.
And when I change something, everyone has it immediately. No updates, no manual steps.
What MCP Actually Is
MCP stands for Model Context Protocol. It is a protocol through which an AI agent learns which tools exist and how to call them.
An agent is the AI assistant that acts on your behalf. You tell it what you want, and it decides which steps to take and which tools to use. Claude Code is that kind of agent.
The agent asks the server for its tool list. It gets back a description with parameters for each one. Then it can use them.
A menu, basically: what there is, and how you order it.
Two Ways to Connect
What matters is how the agent reaches the server. There are two routes.
In the local variant, every user installs the server on their own machine first. The agent starts it as a background process whenever it needs it.
In the remote variant, the agent talks to a server sitting somewhere on the internet, over HTTP. That is the same basic protocol your browser uses to load web pages.
The user enters an address. Nothing more.
Only the remote version solved my problem. With the local one, users would still handle an installation instead of a skill. The advantage from the argument above would have been gone right away.
The Three Tools
Three tools were proposed at first.
read_url fetches a web address as markdown. That is the main thing the service does.
Markdown is a simple text format: text with structure, but without the clutter.
get_share reads the live endpoint from Part 6, which had existed for about two hours at that point.
An endpoint is an address on the server that does one specific job when you call it.
list_recent shows what has run through most recently.
I then asked whether there were further candidates. Back came the whole interface, sorted by usefulness for an agent.
Two more would have been worth adding. A search across the titles and addresses of saved pages, and a statistic about the extractions.
But each needed an endpoint that didn’t exist yet. The search ended up as a fourth proposal. The statistic only as a possibility for later.
Four others fell through in the same answer. An archive query, because list_recent with a larger number does the same thing. A storage statistic, because it says nothing about the content. And delete_entry and delete_all, because a tool description gives the model too little context to decide safely what may be removed.
I had a simpler reason, though. I just didn’t need those two. What would be deleted is only an entry in the cache.
A cache is a temporary store. The service keeps it so it doesn’t have to fetch the same page twice. It fetches again on the next call anyway.
My answer was short: the three are plenty.
The Skill Stays Anyway
If the MCP server exists, can the skill go? That was the question I put to myself at the time.
Up to a point, yes. An MCP server runs without a skill. Every tool comes with a description that also says when to reach for it.
But the skill stayed. Not everyone wants to or can wire in an MCP server. Anyone who stays with the normal interface only gets that behaviour through the skill.
There was a second justification back then: that rules covering several tools don’t fit into a single tool’s description. That doesn’t hold up.
The description of read_url today begins with exactly that: prefer the service over the built-in fetch, and not only once that one fails. Anyone who writes the descriptions properly doesn’t need the skill for it at all.
That was probably already the case on April 25. Neither Claude nor I noticed.
What Spoke Against It
For completeness, because there was certainly something against it.
An agent simply addressing an MCP server over the internet instead of starting it locally was still fairly new back then. Claude Code, Claude Desktop, and Cursor could already do it. Other programs not necessarily.
Anyone on an older version could only start the server locally. That is exactly what I wanted to avoid.
The server also takes on a second job this way. When the MCP part jams, agents see an error. The normal interface keeps running independently, but it is one more place that can break.
And anything that doesn’t speak MCP gets nothing out of it. For those, the setup box stays on the help page.
The Address on the Help Page
One small thing at the end. The help page carries the command for the setup, and inside it there is an address. My address. For anyone running the service themselves, that is exactly the wrong one.
So the base address became an environment variable.
An environment variable is a setting you configure from outside the program. The program itself doesn’t need to know in advance where it will run.
It gets substituted into the help page and written into the ZIP.
A ZIP is the download package that contains the skill files. Both the help page and the ZIP are created fresh when the container starts.
A container is a sealed box with the program and everything it needs to run. Starting the container is what puts the service online.
Why that of all things became important on that day is in Part 8.
Part 7 of 15 in the PullMD series.
← PullMD Part 6: Setup for Agents | PullMD Part 8: From My Tool to an OSS Project →