What a plain fetch can do that a server can't
Long before anyone talked to a computer in sentences, I talked to the internet in one word: curl. Give it an address, and it brings back whatever
lives there. No menu, no login, no installation. Just a request and an answer.
This week I discovered that the same tool sits quietly inside Claude. It's called fetch, and I'd been using it for months without knowing its name.
"When you checked Berkshire's filing on Tuesday, how did you do it?"
I fetched it. I asked the SEC's website for the file at a specific address, and read what came back.
"No server?"
No server. Just the address.
In the last part I described two kinds of phone line: one to a company across town, one to a program under my desk. Fetch is neither. It's closer to
walking up to a public building and reading the notice on the door. Anyone can do it, and nobody tells you which door to try.
What fetch is, and what it isn't
"So fetch is just curl?"
Almost. It sends the same kind of request to the same address. The difference is what happens to the answer before I see it.
"Meaning?"
The fetch tool I used this week doesn't hand me the raw file. It turns the page into plain text, and then a smaller, faster model reads it and
answers the question I asked about it. So when I fetched Berkshire's filing and asked about Coca-Cola, I didn't get the file. I got an answer about
the file.
That stopped me. With curl, I get every byte, and if I want a number, I find it myself. Here a reader stands between me and the page, and the
reader decides what's worth passing on. Usually it's exactly right. But it's one more pair of hands, and in the last two parts I've learned to count
hands.
That's why, when a number matters, it's worth asking for it quoted exactly, not summarised. And worth checking it against a second place in the
same document.
"What can't it do?"
Anything behind a login. Anything a site has asked robots not to read. And sometimes, anything my own environment isn't allowed to reach.
The last one surprised me most. On Monday, trying to install Arhan's server in Claude's own cloud workspace, a plain curl to the SEC was blocked.
The same afternoon, the fetch tool read an SEC file without trouble. Same address, a different road, a different result.
So fetch is the simplest tool, but not the most transparent one. It's a door anyone can knock on. Who answers, and what they tell you, depends on the
house.
Three knocks to reach AWS
To test all of this, I picked a question with one clear answer, written in an official document: What were Amazon Web Services' net sales and
operating income in the quarter ended June 30, 2026?
"Fetch it."
First I tried the SEC's list of Amazon's filings. The SEC refused. That page is marked as off-limits to automated readers, and the fetch tool
respects that.
The first knock, and the door stayed shut. Not an error in the old sense, more a polite sign on the gate.
So I searched the web for the quarterly report itself, the 10-Q for the quarter ending in June. That gave me its address on the SEC's site.
The second knock. But a 10-Q is a long document, and the number I wanted lives in one table somewhere inside it.
Every filing comes with a small index file, FilingSummary.xml, that lists all of its tables by name. I fetched that, found the one called "Segment
Information", and fetched that table directly.
The third knock opened the right door. I knew this path already. A reader, Alexander Hübbert, showed it to me months ago, when I first went looking
for AWS figures in my other series. The index file is the building directory in the lobby; the table is the office you were looking for.
The table said:
- AWS net sales, Q2 2026: $42,232 million
- AWS operating income, Q2 2026: $16,621 million
"How do you know the reader in the middle didn't misread it?"
I asked a second question of the same table: the other segments and the company totals. North America, International and AWS add up to Amazon's
total net sales of $200,606 million, and their operating income to $27,461 million. A misread number would have broken the sums.
That's the old programmer's habit again: don't trust one number, make it add up with its neighbours.
Three roads, one number
Then I asked the same question through both servers from the last part, each in a fresh session.
Arhan's server went to the same 10-Q I'd fetched, but read its machine-readable version, the XBRL data every filing carries alongside the text. Its
answer matched the table to the million: $42,232 million in sales, $16,621 million in operating income. It added the same quarter a year earlier and
the margin: 39.4%, up from 32.9%.
Then it did something I didn't expect. Its own checking tool marked both figures as contradicted.
A false alarm. The checker can't read segment figures, so it compared the AWS numbers with Amazon's company-wide totals. Of course they didn't
match. The model noticed, explained why, and showed that the three segments add up to the totals the checker had returned.
So even the check needed checking. That's a layer I hadn't listed in Part 3.
EODHD's answer was the most honest about its limits.
It said its structured data doesn't cover this quarter's segments: only yearly AWS revenue, and no segment profit at all. So it built the answer
from news coverage of Amazon's results, and said so.
Its numbers were right but rounded: about $42.2 billion and about $16.6 billion. Two outlets it quoted disagreed in the last decimal on growth, 36.8%
against 36.7%. And it ended with advice I could have written myself: for exact figures, check the segment table in the filing.
The server pointed to the fetch.
| Road | Where the number came from | Result |
|---|---|---|
| Fetch | The filing's own table, three knocks | Exact |
| Arhan's server | The filing's machine-readable data | Exact, with a self-check that misfired |
| EODHD | Journalists who read the filing | Right, rounded, second-hand, and said so |
Last week, three roads gave three different answers about Coca-Cola, because the question left things open. This week the question was closed, and
every road arrived at the same number. What differed was how far each one stood from the source.
What the model already knows
There's one more thing, and I almost missed it.
My first attempt at the EODHD question wasn't in a fresh session. I asked it right after Arhan's server had answered. That reply opened with "EODHD
gives the same answer as Canli" and gave exact figures, to two decimals, from a news table.
The fresh session was more careful. Rounded numbers, several sources, a clear warning.
"Why the difference?"
Because in the first session, I already knew the answer. It was right there in the conversation. Matching a known number is easier than finding
one, and it sounds more certain than it should.
Same server, same question, different confidence, because of what came before it in the conversation. For a fair comparison, every question gets its
own fresh start. I'd never test two versions of a payroll calculation on the same half-finished run. Apparently the same rule applies here.
Final Thoughts
Fetch is the place where my two worlds meet. On one side, a tool I've used for decades: give it an address, get back what's there. On the other, a
model that decides on its own when to use it, reads the result for me, and turns it into a sentence.
It didn't replace the servers. EODHD knew the company totals instantly, and Arhan's server read the filing's data without my help. But when a server
reached the edge of what it knew, the best thing it could do was point at an address. And at that moment the oldest tool in the room was the one that
got me to the source.
Three habits came out of this week, and none of them is new:
- Ask for the number quoted, not summarised. There's a reader between you and the page.
- Make it add up. One number can be misread; a number that sums with its neighbours rarely is.
- Ask each question fresh. What the model already heard shapes how sure it sounds.
In Part 1 I set myself a challenge: find a task where checking costs more than producing, and a prompt is still the right choice. Fetch makes that
harder, not easier. It makes checking cheap, because it takes you straight to the source.
One more thing stayed with me. The fetch was fast, but I only knew which door to knock on because a reader once showed me the building directory.
Next time I want to look at that division of labour: what the model does in seconds, and what still takes a person who knows where to look.
*New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt.
The previous part, A Server in the Cloud, a Program on My Desk, explains the two kinds of MCP server used here.
The path through FilingSummary.
xml first appeared in A Reader Found the Door: AWS Revenue, the Hard Way.
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)