What an MCP server actually is
In the first part of this series I promised to explain the word nobody explains: MCP. I called an MCP server a phone line into a locked room, a way for Claude to reach data it can't see on its own. It was a good picture. It was also as far as my understanding went.
This week I found out how far that was. I wanted to try a new MCP server a reader had built. I opened Claude in my browser, typed my question, and got nothing. The server was fine. The question was fine. I had simply picked up a phone that wasn't connected to that line.
"Why didn't it work?"
Because that server doesn't live on the internet. It lives on your computer — or it would, once you install it. A browser tab can't start a program on your machine.
"Then where does EODHD live?"
On EODHD's computers. That's why it works from anywhere you can sign in.
Two phone lines, then. One runs to a building across town. The other runs to a box under my own desk. They look the same from the handset. They are not the same.
What a server actually does
"So what is an MCP server? Not the metaphor. The thing."
A program that offers me a list of tools. Each tool has a name, a short description, and a list of the inputs it expects. That's all I see of it.
"And then?"
When you ask a question, I read the descriptions and decide whether one of the tools would help. If it would, I ask for it by name, with the inputs filled in. The app you're using — the desktop app, Claude Code, the browser — passes the request to the server. The server does the actual work: calls an API, reads a filing, queries a database. Then it hands the result back, and I write the answer from it.
So the model never touches the data directly. It reads a menu, orders a dish, and the app carries the plate. MCP, Model Context Protocol, is just the agreed format for that menu and that order, so that any app and any server can talk to each other.
As a programmer, I recognise it immediately. A tool is a function signature with a docstring. The difference is who reads the docstring. In my code it's me, once, while I write the call.
Here it's the model, every single time, deciding on the spot.
"Does the menu cost anything?"
It does. Every tool description travels with every question, and it takes up room in what I can hold at once. Arhan Canli measured it for several finance servers: his sends 859 tokens of descriptions with each request; the largest he tested sends over 432,000.
His trick is worth noting. Instead of putting all of his 306 tools on the menu, he lists three: one to find a tool, one to describe it, one to run it. The model looks things up only when it needs them. It's the difference between handing a guest the full recipe book and telling them to ask the chef.
And a shorter menu also means fewer wrong orders. The more similar tools I see at once, the easier it is to pick the wrong one.
Which brings us back to "silver price" returning inflation. Picking the right tool isn't only my job as the person asking. It's also the job of whoever writes the menu.
The line across town
"Start with EODHD. Where does it actually run?"
On EODHD's own computers. Your app connects to it over the internet, the same way a browser opens a web page. To use it, you sign in with your EODHD account once, and the app keeps the connection.
That's why it worked everywhere I tried it: in the browser, in the desktop app, and later in the terminal, where all I had to do was sign in again. Nothing was installed on my machine. The server was already running; I only got permission to call it.
"What am I trusting, then?"
EODHD. Your questions go to their servers, under your account. They decide what data is there, how fresh it is, and how much each request costs. Some of their tools cost ten API calls a request.
And they can change the server without asking me. A new tool appears, an old one behaves differently. Usually that's an improvement. It's also why an answer I got in July might not come back word for word in October.
The box under my desk
"And Arhan's server?"
That one is a program. It runs on your own computer, and only while the app needs it. The app starts it, talks to it, and stops it.
Installing it took a single line: npx -y canli-mcp. In plain words: fetch this package from npm, the public shelf of JavaScript programs, and run it. The app and the program then talk through a pipe on my own machine, not over the internet. The program itself goes out to fetch public data from the SEC and other official sources, and needs no account at all.
That explains my failed attempt. A browser tab is not allowed to start programs on your computer, for very good reasons. The desktop app and Claude Code are. The phone was fine; it just
couldn't reach a box under someone's desk.
"And what am I trusting here?"
Code written by someone you've never met, running with your permissions. That's why Claude Code asked whether you trusted the folder before it started.
I answered that question carefully. I made an empty folder just for the test, and only then said yes. Arhan publishes his code openly, under the MIT licence, so anyone can read what it does. That's a good sign. It's not a guarantee. For a work computer I'd ask first.
So: the line across town asks me to trust a company. The box under my desk asks me to trust code. Neither is free of trust. They just ask for it in different places.
An evening with the old world
Installing the box under my desk felt like coming home.
First Node.js, because npx belongs to it. Then Claude Code, the version of Claude that lives in a terminal window, because that's where local servers are easiest to add. The installer was one line in PowerShell. It finished without a word. I typed claude and got the reply every programmer knows by heart:
The term 'claude' is not recognized as the name of a cmdlet.
I almost smiled. Then I ran the installer again, and this time it told me exactly what was wrong: the program was installed, but the folder it lived in wasn't on my PATH, the list of
places Windows looks for commands. One line to add the folder, a new terminal window, and claude --version printed a number.
"You seem happy about an error message."
I think you're happy about a good error message.
That's it. It failed loudly, it said where, and it said why. In the last part I complained that the new tools fail quietly: a list that's simply shorter, a lookup that answers the wrong question. The installation was the opposite. Every step that went wrong said so.
The rest was short. One line added Arhan's server:
claude mcp add canli -- npx -y canli-mcp
Another listed what Claude Code could now reach:
claude mcp list
Two lines came back. Arhan's server: Connected. EODHD, which Claude Code had picked up from my account: Needs authentication. The box under my desk was ready at once; the line across town wanted me to sign in first. The two kinds of server, side by side, in two lines of output.
Then two more small hurdles. Claude Code asked whether I trusted the folder I'd started it in. It was my whole user folder, so I said no, made an empty one, and said yes there. Then it told me my login had expired. /login, a browser window, done.
Total time: about an hour, most of it spent learning where things live. Which, I suppose, was the point.
Same question, two lines
With both servers connected, I asked each the same question: who owns more than 5% of Coca-Cola?
| Holder | Arhan's server | EODHD |
|---|---|---|
| Berkshire Hathaway | 400.0M shares, ~9.3% (13F, June 30, 2026) | 400.0M shares, 9.30% (13F, June 30, 2026) |
| BlackRock | 313.2M, 7.2% (13G, Dec 31, 2023) | 322.7M, 7.50% (13F, June 30, 2026) |
| Vanguard | 276.8M, 6.43% (13G, March 31, 2026) | 238.8M, 5.55% — about 7.9% with a second Vanguard entity |
"Which one is right?"
Berkshire is the same in both, to the share, and it matches Berkshire's own filing with the SEC. For the other two, both answers are correct readings of different documents.
That's the whole lesson of the last part, live on my screen. "Who owns more than 5%" leaves three things open. Which filing: the 13G, a stake report filed only when something changes, or
the 13F, a portfolio snapshot filed every quarter? As of when? And who counts as the holder: one legal entity, or the whole group? Arhan's server answered with the latest stake reports and told me, row by row, how old each one was. BlackRock's was almost three years old, and it said so. EODHD answered with the latest quarter for everyone and added context I hadn't asked for:
that Vanguard reports under two names.
One gap I can't close yet: Vanguard's two figures don't reconcile even after allowing for the different dates. It may be how the two filings count shares. I'd want to read both filings before saying more.
So would I. It's the salary question again: base, gross or net. Two servers, two honest answers, one imprecise question.
Final Thoughts
I started this series with a phone line into a locked room. I'd now draw it as two lines.
One runs across town, to a company's server. It works from any app you can sign in to, and it asks you to trust the company: its data, its prices, its changes. The other runs to a box under your desk, a program on your own computer. It works only where an app is allowed to start programs, and it asks you to trust the code.
What the two have in common matters more than how they differ. Both hand the model a menu of tools. Both shape the answer before the model writes a word: which documents count, how fresh they are, what "a holder" means. Choosing a server is choosing a source, with all its definitions.
Arhan's server and EODHD aren't rivals in this story. They're two honest witnesses who read different documents. The work is the same as it was in Part 3: ask what each one looked at, and check the one number you can check.
Next time I want to look at the simplest tool of all, the one that needs no server: a plain fetch of a public web page, the same thing curl has done for decades.
New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. The previous part, Same Question, Different Answer, maps where a prompt's mistakes come from. Arhan Canli's server is canli-mcp, free and
MIT-licensed. Many of my examples come from my other series, Unlock Real-Time Market Intelligence with EODHD and Claude.
Top comments (0)