DEV Community: Jaroslav Šmarda

Thirty Lines Between a Question and an API

Jaroslav Šmarda — Mon, 19 Oct 2026 13:34:01 +0000

Building a tiny MCP server, and who does what

At the end of the last part I promised to look at the division of labour: what the model does in seconds, and what still takes a person who knows
where to look. I found the best way to look at it was to build something.

Because there was one question I'd been carrying for months, and was a little embarrassed to ask. I've called APIs for most of my working life. I've
used MCP servers for this whole series. But how does one become the other?

"How do you get from an API to an MCP server?"

You wrap it. An MCP server is a small program that sits in front of an API and translates. On one side it speaks to me; on the other it speaks to
the API.

"That's all?"

That's most of it. It does three things. It tells me what tools it has. When I ask for one, it turns my request into a real API call. And it hands
the answer back.

A menu for a new kind of guest

The picture that finally made it click for me was a restaurant.

The kitchen is the data: prices, filings, everything EODHD has. The guest is a program that wants something from it. Between them stands the waiter,
who takes the order to the kitchen and brings the plate back. That waiter is the API. And the menu is the list of what the API can do, written in its
own precise language: this address, these parameters, this format.

For thirty years, the guests were programs written by people like me. We read the menu once, carefully, and wrote the order into our code.

And now the guest is me. I can't read the API's menu the way your code does, and I shouldn't hold its keys. So someone writes me a menu of my own:
a short list of dishes, each with a plain-language description, and a waiter who knows how to turn my order into the kitchen's language.

That menu, and that waiter, are the MCP server. Same kitchen, same API. Just a menu translated for a new kind of guest.

Thirty lines

Here is the whole server. One tool, one API call:

"""A minimal MCP server: one tool, wrapped around one EODHD API call."""
import os


import requests
from mcp.server.mcpserver import MCPServer


mcp = MCPServer("mini-eodhd")




@mcp.tool()
def get_close_price(ticker: str, date: str) -> str:
    """Return the raw closing price of a stock on one trading day.


    ticker: symbol with exchange suffix, e.g. AAPL.US
    date: trading day as YYYY-MM-DD
    The price is the raw close, not adjusted for later splits.
    """
    r = requests.get(
        f"https://eodhd.com/api/eod/{ticker}",
        params={"api_token": os.environ["EODHD_API_KEY"],
                "fmt": "json", "from": date, "to": date},
        timeout=30,
    )
    r.raise_for_status()
    rows = r.json()
    if not rows:
        return f"No trading data for {ticker} on {date} (weekend or holiday?)"
    return f"{ticker} closed at {rows[0]['close']} on {date}"




if __name__ == "__main__":
    mcp.run()

If you've written Python, nothing here is new. A function, a web request, a JSON answer. The only unusual line is @mcp.tool(), and that one line is
what turns an ordinary function into a dish on the menu.

"So what do you actually see of all this?"

Three things. The name, get_close_price. The docstring, word for word — that's my menu description, so it's the most important text in the file.
And the two parameters with their types, which the library turns into a little form: ticker, a string, required; date, a string, required.

"And the rest?"

The rest is the waiter's business. I never see the URL, never see the code, and never see the API key. It comes from the computer's environment,
outside the conversation entirely.

That last point surprised me most. The docstring isn't a comment anymore. For thirty years I wrote docstrings for the next programmer, who might read
them. Here, the docstring is read every single time, by the guest, and it decides what gets ordered. Raw close, not adjusted for later splits isn't
a note for posterity. It's an instruction to the reader that matters most.

Two loud mistakes

It didn't work the first time. Twice. And both failures were the best part of the evening.

The first mistake was Claude's. It wrote the server from what it remembered of the official library, with a line that began from mcp.server.fastmcp import FastMCP. Before I'd even run it, Claude tested it in its own workspace, and the library answered at once:

No module named 'mcp.server.fastmcp'. This is mcp 2.x, where FastMCP was renamed to MCPServer.

It even pointed to the migration guide.

"You got it wrong."

I did. I wrote the version I'd learned, and the library had moved on. That's the risk from Part 3: an answer from memory sounds just as sure as a
current one. The difference here is that code doesn't accept sounding sure. It either imports or it doesn't.

One line changed, and the server started.

The second mistake was mine, following Claude's instructions. To register the server, I typed a command that passed my API key with --env and then
gave the server its name. Claude Code replied:

Invalid environment variable format: mini-eodhd, environment variables should be added as: -e KEY1=value1 -e KEY2=value2.

The option had swallowed the name, thinking it was another variable. Swap two words, run again, done.

In Part 3 I complained that the new world fails quietly: a list that's simply shorter, a lookup that answers the wrong question. Building the server,
I was back in the old world, where every mistake stops you, says where, and says why. I'd forgotten how much I liked it.

One question, end to end

With the server running, I asked it in plain English: what was Apple's closing price on October 16, 2026?

Here is everything that happened between my sentence and the answer.

Claude read the menu: one tool, get_close_price, with its description and its two-field form.
Claude decided the tool fit the question, and filled in the form: ticker = AAPL.US, date = 2026-10-16.
Claude Code passed that order to my server, the little program on my desk.
The server added the API key from my computer's environment and sent a real request to EODHD.
EODHD sent back a line of JSON. The server pulled out one number and returned a sentence: AAPL.US closed at 343.46 on 2026-10-16.
Claude wrote the answer, and added the warning from my docstring: this is the raw close, not adjusted for later splits.

$343.46. I checked it against EODHD's own server afterwards; it matched.

"Where in those six steps could it go wrong?"

Steps three to five are ordinary code. Same order in, same answer out, every time. Steps one, two and six are mine. That's where the choices are:
reading "Apple" as AAPL.US, reading "October 16" as a date in the right format, deciding what to say about the result.

So the uncertainty I wrote about in Part 3 has an exact address. It doesn't live in the server, or the API, or the data. It lives in the two
translations at either end: from my sentence into the form, and from the result back into a sentence.

Then I asked about the next day, a Saturday. My server did exactly what I'd told it to: No trading data for AAPL.US on 2026-10-17 (weekend or
holiday?). Claude's answer went further. It said Saturday, explained that markets were closed, and gave Friday's close as the last one before it.

As far as I can tell, I asked that question in a fresh session, which means Claude went back to the tool a second time, for Friday, on its own.
Nobody told it to. That's the part of the work I didn't write.

Who did what

Looking back at the evening, the division of labour is surprisingly clean.

I decided which API to call. I decided which number counts: the raw close, not the adjusted one, which is a choice with consequences, as anyone who
read about stock splits in my other series knows. I decided what the tool says when there's nothing to say. I decided that the key stays on my
computer, and that the tool can only read, never change anything.

And I did the rest in seconds: understood "Apple", found the right date format, picked the tool, noticed that a Saturday needs a different answer,
and went back for the Friday.

That's the split I expected after Part 5, in a form small enough to see whole. The machine is fast at everything inside the menu. The menu itself,
what's on it, what each dish means, what's not allowed, comes from someone who knows the kitchen.

Which also means that whoever writes the menu decides what the AI may do. EODHD's server offers dozens of tools, and every one of them only reads.
There is no tool to change or delete anything, so there's nothing for a wrong guess to break. That's not the model being careful. That's the menu
being careful.

Final Thoughts

My other series has carried a tagline from the start: Python for programmers, prompts for data analysts. Until this week I thought of those as two
kinds of reader. Building this server, I saw them as two halves of one job.

The programmer writes the menu. Thirty lines: one function, one docstring, one decision about which number is the right one. The analyst asks a
question in a sentence and never sees any of it. Neither half is more important. Without the menu, the model has nothing to order. Without the model,
the menu is just another API that only programmers can read.

And because MCP is a standard, the menu is written once. The same thirty lines would work in any app that speaks MCP, the way a plug fits any socket
built to the same shape. That's what EODHD did for its whole catalogue, and what Arhan did for his. It's what I did, on a much smaller scale, for one
question about one price.

The challenge from Part 1 still stands: find a task where checking costs more than producing, and a prompt is still the right choice. This week moved
it a little. When you write the tool yourself, part of the checking moves into the code, where it's done once. The docstring that says raw close,
not adjusted is a check written down before anyone asks.

So far in this series I've treated the prompt as a sentence. Next time I want to look at what else can go into one: instructions, examples, files,
the menu itself. I've been typing prompts for months, and I still don't know the full answer.

New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. Part 4 explains where MCP servers run; Part 5 looks at the plain fetch that needs no server at all. Why raw and adjusted prices differ is covered in
Every Split Leaves a Fingerprint, part of my other series, Unlock Real-Time Market
Intelligence with EODHD and Claude.

The Oldest Tool in the New World

Jaroslav Šmarda — Fri, 16 Oct 2026 11:57:24 +0000

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.*

A Server in the Cloud, a Program on My Desk

Jaroslav Šmarda — Wed, 14 Oct 2026 15:16:06 +0000

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.

Same Question, Different Answer

Jaroslav Šmarda — Tue, 13 Oct 2026 09:00:55 +0000

Where a prompt's mistakes are actually born

I write payroll software. In my world, "almost right" is a polite word for wrong. A salary that's off by one crown still has to be corrected, explained and signed off, and a payslip paid out three years ago must still match the rules it was calculated under.

So when I hear people say they don't trust AI because the same question gets a different answer every time, I don't argue. I mostly agree. But I wanted to know why the answers differ, so I asked the one who gives them.

"If I ask you the same question twice, will I get the same answer?"

Not necessarily. But "the same question" is doing a lot of work in that sentence.

"Meaning what?"

Meaning that most questions leave something open. Which ticker, which price, which period. Each time, I fill those gaps — and I may fill them differently.

That I understand better than I'd like. In payroll, "salary" can mean base pay, gross, net, with allowances, with the quarterly bonus. Ask five people for an employee's salary and you can get five correct answers to five different questions. That isn't an unreliable system. That's an imprecise question.

But a different answer isn't what keeps me up at night.

"What worries me is the wrong answer nobody notices. A filter built slightly wrong, a list of employees that's quietly incomplete. No error message. Somebody just doesn't get paid."

Then let's find where that kind of mistake is born. It isn't one place.

Where you ask

The first place surprised me, because it happens before any answer at all.

A few days ago I wanted to try a new MCP server, and typed into a chat: use canli-mcp: who owns more than 5% of Coca-Cola? Nothing useful came back. That server runs on your own computer, through the desktop app. I had asked in the browser, where it could never reach.

I couldn't use a tool that wasn't connected to that conversation, and this time I said so. The risk is the other case: a question that sounds answerable, and a model that answers it
anyway — from memory.

"From memory meaning…"

From what I learned in training. That can be months old. I'll know Coca-Cola's long-time largest shareholder. I won't know last week's filing.

That's where my own story with AI began. I asked for Amazon's price, got a polite refusal, and thought: is that all this is? Only later did I understand that the question had gone to the wrong place. Without a connection to live data, the honest answer is "I can't". The dangerous answer is a confident old number.

What the model chooses

"And when the tool is connected?"

Then the data is the same every time. What can change is what I ask the tool for. Which ticker. Close or adjusted close. Which dates.

So we're back at salary. The data in my payroll system doesn't change between two reports. The report changes, because someone chose gross instead of net.

The tool can make choices too. A developer named Arhan Canli wrote openly about a bug in an early version of canli-mcp, the free, MIT-licensed finance server he built (github.com/arhancanli/
canlicapital). Ask it for the "silver price", and it returned US consumer inflation. The word "price" matched the description of the inflation
series; the word "silver", the one that actually mattered, matched nothing. The tool didn't crash. It returned real numbers, neatly formatted, for a question nobody asked.

That's the kind of mistake that worries you. Not an error. A correct answer to the wrong question.

His fix was simple and, I think, wise: when the tool isn't sure, it now says "I don't know" and points elsewhere. My old programs did that by default. They crashed when something was missing — loudly, rudely, and safely.

The filter that stays quiet

"So where does the quiet kind of mistake come from?"

Sometimes from the tool itself. Let me show you one we made together.

Last week, for an article about congressional stock trades, we pulled every trade made in the last week of July and measured how long each one took to be disclosed. A hundred trades. Clean numbers, a tidy median, an honesty section about the small sample. Published.

Days later, while checking a reader's question, a single field in the server's reply said something the table never had: total: 111.

One request returns at most a hundred rows. The other eleven were there all along. Nothing failed, nothing warned. The data simply ended.

"That's my incomplete employee list."

It is. Every number we reported was correct — for the hundred rows we saw. The mistake was in assuming the hundred were all of them.

I've written payroll filters for years, and I know this failure by heart. It never looks like an error. It looks like a shorter list. The only defence I've ever trusted is to ask a second, boring question: how many should there be? Compare the count with the list, and the silence starts talking. In the data we used, that question costs nothing — the total sits right there in the reply, waiting to be read.

Does the server matter?

"If the tool can hide rows, how much does the choice of tool matter?"

Someone measured it. Arhan Canli — the same developer with the silver bug — ran one model with one prompt and the same limits, and changed only the server behind it. On the questions every server finished, canli-mcp answered 22 of 28 runs correctly. The best alternative, EdgarTools plus Yahoo, answered 15 of 28.

That's the first measurement I've seen where everything stayed fixed except the server. And it says what I suspected: the same model can be more or less accurate depending on what it's connected to.

With a caution he raised himself: each question was asked twice, and an easy question tends to be right twice. So it's closer to fourteen questions than twenty-eight. Promising, not proven. He's running a fresh set of questions, written before any tuning, and has promised to publish the result either way.

I like that last sentence more than the numbers.

When the source is wrong

"And if the model asks the right question, and the tool returns every row?"

Then there's one place left: the data itself.

Two examples, both found by someone else.

In an article about stock splits I printed Tesla's "raw" closing price before its 2022 split: $498.3201. A reader — Arhan Canli again, as it happens — noticed the fourth decimal. Stocks don't trade in hundredths of a cent. That number was exactly three times Tesla's split-adjusted price. It wasn't a price someone paid. It was a price someone rebuilt. Out of 3,207 Tesla closes in my sample, 1,449 had more decimals than any exchange would quote.

Which means part of the check compared the data with itself. It passed — because it couldn't fail.

The second comes from him too. The SEC publishes the exact time each filing was accepted, and its submissions API keeps one file per company. He measured 450 filings from 25 companies. In 12 of the files, the times were right. In the other 13 — Apple, Nvidia and Amazon among them — every time in the file was shifted by exactly one New York offset: four hours in summer, five in winter. A JPMorgan results filing accepted at 6:30 in the morning, New York time, appears as if it came after the market opened. The same filing can show one time in one company's file and another in the next. Same filing, a different file, a different hour.

Neither mistake announces itself. Both had a cheap check: count the decimals; compare one filing's time with a second source.

Final Thoughts

"Same question, different answer" turned out to be four different problems. The question was asked where no data could reach it. The model or the tool filled a gap in the question differently. The tool returned less than everything and said nothing. Or the source was wrong before anyone asked.

None of them is fixed by trusting AI more, or less. Each is fixed by a cheap, boring check: Was the tool even connected? What exactly did it look up? How many rows should there be? Does this number look like a real one?

That's also why I agree with the people around me who say AI shouldn't calculate payroll. It shouldn't. A calculation repeated every month for every employee belongs in a program that was verified once and behaves the same way every time. That was the whole point of the dividend tracker in Part 2. A prompt is for the questions you ask once, and for getting to the data in the first place. And the final check, and the responsibility that comes with it, stays with a person.

My challenge from Part 1 still stands: find a task where checking costs more than producing, and a prompt is still the right choice. I haven't found one yet. But I've learned where to look first when an answer seems wrong: not at the model, but at the chain behind it.

New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. The examples above come from my other series, Unlock Real-Time Market Intelligence with EODHD and Claude, where every number gets checked before it's trusted.

Every Split Leaves a Fingerprint: Checking Corporate Actions Against Raw Prices

Jaroslav Šmarda — Mon, 05 Oct 2026 14:16:10 +0000

Python for programmers, prompts for data analysts.

Part 33 found a crash that never happened: Amazon's raw price fell 95% overnight because of a 20-for-1 split, while the adjusted price barely moved. The fix was simple — use the right
column. But that fix rests on an assumption nobody checked: that the split records themselves are correct.

A reader on dev.to pointed out how to check them. A real split has to leave a mark in the raw prices: on the split date, the price should drop by almost exactly the split ratio. So you can
test the records against the market in both directions. Does every recorded split show up in the prices? And does every split-sized jump in the prices have a record behind it?

Want to try this yourself? The EODHD MCP Server is what pulled the data above — connect it to Claude and ask your own
questions (affiliate link).

New here? The Setup covers everything you need before your first prompt.

Does every recorded split show up in the price?

🟧 PROMPT

Use the eodhd MCP to get the split history for
AMZN, AAPL, NVDA, TSLA and GOOGL. For every split
since 2014, compare the raw closing price before
and on the split date with the recorded split
ratio.

Nine splits since 2014. Raw price ratio across each split date, against the recorded ratio:

AMZN, Jun 2022 — 19.61 vs. 20 (−2.0%)

AAPL, Jun 2014 — 6.89 vs. 7 (−1.6%)

AAPL, Aug 2020 — 3.87 vs. 4 (−3.3%)

NVDA, Jul 2021 — 4.04 vs. 4 (+0.9%)

NVDA, Jun 2024 — 9.93 vs. 10 (−0.7%)

TSLA, Aug 2020 — 4.44 vs. 5 (−11.2%)

TSLA, Aug 2022 — 3.01 vs. 3 (+0.3%)

GOOGL, Apr 2014 — 1.99 vs. 1.998 (−0.6%)

GOOGL, Jul 2022 — 20.50 vs. 20 (+2.5%)

A raw ratio will almost never match the split exactly, because the stock also moves on the split day itself. What matters is whether the gap is a plausible one-day move. Eight of the nine
land within about 3%. The ninth, Tesla in August 2020, is off by 11% — which looks alarming until you check the day: Tesla's stock jumped about 12.6% on the first session after that split.
The record is right; the market was just busy.

All nine records agree with the prices. Every split left its fingerprint.

Does every split-sized jump have a record behind it?

🟧 PROMPT

Now go the other way. Pull raw daily closes for
the same five stocks since 2014 and flag every
one-day move larger than 30%, up or down. Does
each one match a recorded split?

16,035 trading days across five stocks. Only nine one-day raw moves exceeded 30%, and all nine fall exactly on a recorded split date:

AAPL: Jun 9, 2014 and Aug 31, 2020. NVDA: Jul 20, 2021 and Jun 10, 2024. TSLA: Aug 31, 2020 and Aug 25, 2022. GOOGL: Apr 3, 2014 and Jul 18, 2022. AMZN: Jun 6, 2022.

No large jump without a split behind it, and no recorded split without a jump.

For these five stocks, the records and the prices agree in both directions. That's the reassuring result. The more useful one came from how the check was built.

My first version was stricter: flag only moves that land within 4% of a simple fraction like 1/2, 1/4 or 1/20. It found eight of the nine splits and missed Tesla in August 2020, because a
5-for-1 split plus a 12.6% rally that same day produced a ratio of 4.44, nowhere near 5. A tight filter would have reported that split as missing. The loose one, "any move over 30%",
caught it. The scan's job is to put candidates in front of you, not to decide on its own, so it's better to cast a wide net and look at a handful of hits than to tune it so tightly that a
real event slips through.

A word of honesty

The first trap is one I nearly walked into. It's tempting to verify a split record against the adjusted close — but the adjusted close is calculated from the split records, so it will always agree with them, to the cent. That check proves nothing. The only independent witness is the raw price, which is why both prompts used nothing else.

Five of the most-watched stocks in the world are also the easiest possible test. Errors in corporate-action data are far more likely in small companies, delisted ones, foreign listings, and anything that traded thinly. A clean result here says the method works, not that every record everywhere is right. The nastiest error a dev.to reader described — a 1-for-20 reverse split stored as 20-for-1, which leaves the adjusted series perfectly smooth while every earlier price is off by a factor of 400 — didn't turn up in this sample. This scan is how you would catch it if it did.

Two records were worth a second look even though they passed. Alphabet's April 2014 "split" was really the distribution of new Class C shares, recorded with the odd ratio 1,033 for 517 rather than a clean 2-for-1. And some of Tesla's raw closes carry strange decimals, like $498.3201. A dev.to reader, Arhan Canli, worked out why: 498.3201 / 3 = 166.1067, exactly the adjusted close for that day. That "raw" price was rebuilt from adjusted data by multiplying the 2022 split back in, rather than taken from the exchange. It isn't an isolated case: 1,962 of the 16,035 raw closes in this sample carry more than two decimals, which no official US closing price above a dollar does, and for Tesla it's 1,449 of 3,207, almost all before its 2022 split. For those rows, part of the forward check is circular after all — the raw ratio is just the recorded ratio times the adjusted move. Tesla's real exchange closes, $2,213.40 and $498.32, do confirm its 2020 split, but that confirmation comes from outside this dataset. Two cheap guards follow: flag any raw close with more decimals than the market quotes, and take split-day closes from a second, independent source. The raw column isn't automatically untouched.

Arhan also suggested breaking that count down by year, which shows exactly where the source switches from quoted prices to rebuilt ones. For Tesla, 64 to 70% of raw closes carry extra decimals in every year from 2014 to 2021, 42% in 2022, and almost none after its August 2022 split. Apple shows 38% in 2014, the months before its June 2014 split, and none after. Nvidia, Alphabet and Amazon show smaller, scattered shares, up to about 20% in some years. The flag is also only a lower bound: just 1,448 of Tesla's 2,177 pre-split closes have extra decimals, because a rebuilt price sometimes lands on whole cents by chance. A clean-looking close isn't proof it was quoted; the stretches before each split are the ones to confirm from an outside source.

Finally, the question another reader added: which rows aren't there at all? All five series have exactly 3,207 trading days with the same start and end, so none has a gap the others don't. But that's a relative check. A day missing from every series at once would pass it silently, and a check can only score what exists. Not investment advice.

Final Thoughts

This is the thirty-fifth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and a direct sequel to Part 33. That one said: use the adjusted column. This one asked whether the records behind
the adjustment deserve that trust — an idea that came straight from readers on dev.to.

Two prompts checked the records against the market, once in each direction.

So here's what they found: across 16,035 trading days and five stocks, there were exactly nine one-day raw moves larger than 30%, and every one of them landed on a recorded split. Every
recorded split, in turn, showed up in the raw prices. The data passed. The lesson came from the method: verify a record against something that wasn't built from it, and set the net wide
enough that a real split on a busy day can't slip through. Every split leaves a fingerprint — but only in the column that hasn't been wiped clean.

If this made you curious, the MCP Server is free to try — The Setup walks you through it.

← Part 34: Before You Copy a Senator's Trade, Check the Date

Before You Copy a Senator's Trade, Check the Date

Jaroslav Šmarda — Fri, 02 Oct 2026 12:29:09 +0000

Python for programmers, prompts for data analysts.

Members of the U.S. Congress have to disclose their stock trades. The law behind it, the STOCK Act, makes those filings public, and a whole cottage industry has grown up around them: newsletters, trackers, even ETFs built on the idea that if lawmakers are buying something, maybe you should be too.

It's an appealing idea. But a disclosure isn't the same as a live feed of what someone is doing. Before copying anyone's trade, it's worth asking two plain questions of the filing itself: when did this trade actually happen, and how big was it really?

Want to try this yourself? The EODHD MCP Server is what pulled the data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers everything you need before your first prompt.

Ask how old the news is
🟧 PROMPT

Use the eodhd MCP to get the most recent
congressional stock trade disclosures, and for
each one show how many days passed between the
trade and the disclosure.

Across the 25 most recent disclosures, the gap between the trade and the public filing ranged from 0 to 17 days. The typical gap was about 11 days: the median was 11, the average 10.7. None was flagged as late; the STOCK Act allows up to 45 days.

The amounts are never exact. Each trade is reported as a range: "$1,001 – $15,000", "$15,001 – $50,000", up to "$500,001 – $1,000,000" in this batch.

So by the time a trade becomes public, the typical one is already a week and a half old — and that's with every filing on time. A "copy Congress" strategy doesn't copy the trade; it copies a trade that happened eleven days ago, at a price that no longer exists.

And the size is a guess. A trade reported as "$1,001 – $15,000" could be a thousand dollars or fifteen times that. You know the direction. You don't know the conviction.

Ask again, but fairly
🟧 PROMPT

Now take congressional trades from late July, old
enough that every filing deadline has passed, and
show the typical delay and the longest one.

For 100 trades made between July 24 and July 31, the gap to public disclosure averaged 15.1 days, with a median of 15. The shortest was 3 days; the longest, 42. Six of the hundred took more than a month to appear. None was flagged late.

The first sample said "about eleven days." This one says fifteen. The difference isn't a change in behaviour; it's a change in what we were able to see. Recent trades can only show up with short delays, because the slow filings haven't arrived yet. Measure only the freshest data and the lag looks shorter than it really is.

Fifteen days is the typical case. The legal limit is 45, and one filer in this sample used most of it. A trade disclosed on day 42 describes a market that's six weeks gone.

A word of honesty

A few things deserve naming, and the first is what this article doesn't claim. A disclosure is a legal record of a trade, nothing more. Nothing here suggests that any lawmaker traded on inside information or broke a rule; every filing in both samples arrived within the 45-day limit. The question was only whether the data is fresh and precise enough to copy, and that's a question about the filings, not the people.

And even a perfectly fresh, perfectly precise feed might leave little worth copying. As a reader pointed out, Belmont, Sacerdote, Sehgal and Van Hoek studied members' trades disclosed under the STOCK Act from 2012 to 2020 (Journal of Public Economics, 2022) and found that, on average, their purchases did not beat the market. Later research suggests the picture isn't uniform: members who move into leadership roles have been found to do noticeably better than rank-and-file members. But "Congress" as a whole has not been a reliable stock picker, which makes the case for copying it weak even before the delay is counted.

The sizes are deliberately blurred. The most common bracket in the July sample was "$1,001 – $15,000", a fifteen-fold spread. At the top end, some trades are listed as "Over $1,000,000" with no upper bound at all. You can tell which way someone traded; you can't tell how much it mattered to them.

Not everything on the list is a stock you can copy. The same filings include municipal bonds, Treasury bills, structured notes, and options with specific strikes and expirations. A "congressional trades" feed mixes all of them together.

The sample is lumpy. A hundred trades came from just fifteen members (an earlier version said sixteen; one senator who filed twice had been counted twice), and one single filing accounted for twenty-three rows. One active account can dominate any average built from data like this. As a reader suggested, the fairer unit is the member, not the row. Take each member's own median delay, then the median of those fifteen numbers: 17 days, close to the row-level 15. Only one of the fifteen members ever filed after day 30, and that one member accounts for all six of the month-plus disclosures. That's a count, not a rate: with only fifteen members, a 95% interval for "one in fifteen" runs from about 1% to 30%, so this sample can't say whether late filers are rare or a quarter of Congress.

Timing matters too. The data was first pulled on October 2 and pulled again on October 8, with the same hundred rows both times. The 45-day deadlines for July 24–31 trades fell between September 7 and 14, so every on-time filing had had weeks to appear. Only a filing that missed the deadline altogether could still be absent. Two gaps remain, though. The window actually holds 111 trades, and a single request returns at most 100, so the figures here cover the first hundred, not all of them. And the dataset records one disclosure date per trade, with no field for amendments, so if a filing was later corrected or re-filed, there's no way to tell from this data which date the lag was measured from.

And the data itself needs the same check Part 33 recommended. One record in the July sample lists a disclosure date four days before its own transaction date — impossible as written. The dataset reports its delay as +4 rather than −4, so the figures above count it as a four-day lag; counting it as −4, or dropping it, leaves both medians unchanged. I kept the record and flagged it rather than fixing it quietly. It's a reminder that even official, structured filings pass through human hands before they reach a dataset. Not investment advice.

Final Thoughts

This is the thirty-fourth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and a companion to Part 31: there it was corporate insiders and their filing codes, here it's members of Congress and their filing dates.

Two prompts asked the same question twice, and the second, fairer version gave a different answer.

So here's what they found: a typical congressional trade became public about 15 days after it happened, and some took as long as 42 — all of them on time under the law. The amounts arrive as ranges up to fifteen times wide. Copying Congress means acting on a trade that's already two weeks old, at a size you can only guess. And even measuring that delay has its own trap: look only at the freshest filings and the lag shrinks to eleven days, simply because the slow ones haven't arrived yet. The date on the filing is the first thing to check, and not the last.

If this made you curious, the MCP Server is free to try — The Setup walks you through it.

← Part 33: The Crash That Never Happened: Cleaning Price Data Before You Trust It

The Crash That Never Happened: Cleaning Price Data Before You Trust It

Jaroslav Šmarda — Wed, 30 Sep 2026 10:11:34 +0000

Python for programmers, prompts for data analysts.

Every article in this series has trusted the numbers it pulled. That's mostly fine — but raw price data carries traps that look exactly
like real market events. A stock can appear to lose 95% of its value overnight when nothing happened to the company at all.

This one is about checking the data before believing the story it tells. Let's find a crash that never happened, and see which column of
the same dataset tells the truth.

Want to try this yourself? The EODHD MCP Server is what pulled the data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers
everything you need before your first prompt.

Find the crash

🟧 PROMPT

Use the eodhd MCP to get AMZN's daily closing
prices from June 1 to June 8, 2022, and tell me
the biggest one-day change.

The biggest one-day move in that window: Friday, June 3, 2022, AMZN closed at $2,447.00. The next trading day, Monday, June 6, it
closed at $124.79. That's a drop of 94.9% in a single session.

Read that at face value and it's one of the worst days any major stock has ever had: a trillion-dollar company losing nearly all its
value between Friday and Monday. Except nothing like that happened. There was no collapse in the news that weekend, no panic, no
headline. Amazon was fine.

The same dataset has a second price column, and it tells a very different story:

Adjusted close, same two days: $122.35 on June 3, $124.79 on June 6. A gain of 2.0%.

Same stock, same two days, same data provider. One column says the stock lost 95%. The other says it gained 2%.

Ask why the two columns disagree

🟧 PROMPT

Use the eodhd MCP to check AMZN's split history.
Did anything happen on June 6, 2022?

Yes. On June 6, 2022, Amazon executed a 20-for-1 stock split. Every existing share became twenty shares, each worth one-twentieth of
the old price. A shareholder with one share worth $2,447 on Friday owned twenty shares worth about $124.79 each on Monday, roughly $2,
496 in total.

The raw "close" column records the price per share exactly as it traded that day, so it shows the drop from $2,447 to $124.79. The
"adjusted close" column rewrites all earlier prices as if the split had always been in effect: $2,447 divided by 20 is $122.35. Divide
one Friday price by the other and you get exactly 20.0, the split ratio.

Nothing about Amazon's value changed that weekend. What changed was the unit of measurement: more, smaller slices of the same company.
The raw close is historically accurate about the price printed on each day, and completely misleading as a record of what an owner
actually gained or lost.

That's the trap. Any calculation that runs across a split on raw closes — a return, a chart, a moving average, a backtest like Part 25 —
inherits a 95% crash that never happened. Adjusted close exists to prevent exactly that. It also folds in dividends for companies that
pay them, which is why every return calculation in this series has used it.

A word of honesty

Adjusted close fixes one problem and quietly creates another: it rewrites history. Every time a company splits or pays a dividend, the
provider recalculates every earlier adjusted price. A number you saved from last year's adjusted series won't match the same date in
today's download, even though nothing about that day changed. Raw close never moves after the fact; adjusted close is only correct
relative to the moment you pulled it. The robust fix, as a reader pointed out, is to store the raw close together with the split and
dividend events and rebuild the adjusted series whenever you need it. Research databases like CRSP keep the raw price and its adjustment
factor in separate fields for exactly this reason, and EODHD exposes the same building blocks: raw prices, split history, and dividend
history.

Neither column is simply "right." Raw close is the truth about what a share actually traded for on a given day, which is why the options
articles in this series used real, unadjusted strike and spot prices. Adjusted close is the truth about what an owner gained or lost
over time. The mistake isn't choosing one; it's using the wrong one for the question you're asking.

Even the corporate-action records deserve a glance. EODHD lists Amazon's January 1999 split as 959,692 for 319,897, a ratio of 3.000003
rather than a clean 3-for-1. The difference is tiny, but it's a reminder that the data behind the adjustments is itself data, entered
and stored by someone, and worth a sanity check before you build on it.

And this is one pitfall out of many. Missing trading days, companies that vanished from a dataset, prices recorded in the wrong currency
or time zone: each can produce a result that looks precise and is simply wrong. The title of Alexander Hübbert's article "Six ways to
clean your trading data into the wrong answer" puts it well — the danger isn't dirty data, it's data that looks clean. Not investment
advice.

Final Thoughts

This is the thirty-third article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and the first one about the data itself rather
than what it says. Every earlier part trusted the numbers it pulled; this one checked whether they deserved it.

Two prompts found a crash, then found out it never happened.

So here's what they showed: on June 6, 2022, Amazon's raw closing price fell 94.9% overnight, while its adjusted close rose 2.0% — the
same stock, the same day, the same dataset. The difference was a 20-for-1 split, and dividing one Friday price by the other gives
exactly 20. Nothing was wrong with either column. What would have been wrong is feeding the raw one into a return, a chart, or a
backtest without asking what it measures. Clean-looking data is still worth one question before you trust it: which number is this, and
is it the one my question needs?

If this made you curious, the MCP Server is free to try — The Setup walks you through it.

← Part 32: “The Market” Isn't One Thing: Watching Sectors Take Turns

Bonds vs. Stocks: What “Safer” Actually Costs You

Jaroslav Šmarda — Wed, 30 Sep 2026 09:21:52 +0000

Python for programmers, prompts for data analysts.

"Bonds are safer" is one of the most repeated pieces of investing advice there is. It's not wrong, exactly — but "safer" is doing a lot
of quiet work in that sentence, standing in for a trade-off most people never actually see the size of.

Let's put a bond fund and a stock fund side by side, over the same period, and ask what "safer" bought — and what it cost.

Want to try this yourself? The EODHD MCP Server is what pulled the
data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers
everything you need before your first prompt.

Ask for the trade-off directly

🟧 PROMPT

Use the eodhd MCP to compare AGG (bond fund) and
VOO (S&P 500 fund) on 5-year returns and
volatility.

AGG (bonds): 5-year return −0.51%, 1-year volatility 3.21%.

VOO (stocks): 5-year return 13.09%, 1-year volatility 13.25%.

The bond fund moved about a quarter as much as the stock fund — and lost money over five years. The stock fund moved four times as
much — and turned a dollar into more than $1.13 in gains alone.

That's the trade laid bare in two numbers: AGG gave up virtually all of the stock fund's volatility, and gave up virtually all of its
return along with it.

Ask why bonds lost money at all

🟧 PROMPT

Bonds are supposed to be the "safe" asset. Why did
AGG lose money over five years?

Bond prices move inversely to interest rates: when rates rise, the price of existing bonds falls, because new bonds get issued paying
more. AGG holds intermediate-term bonds with an effective duration of about 5.8 years — meaning a 1-percentage-point rate increase would
be expected to lower the fund's price by roughly 5.8%. The five years in this window included a sustained rate-hiking period, and that
price decline outweighed the interest income the fund collected along the way.

"Safe" here means something narrower than "won't lose money." It means the loss, when it happens, tends to be small and predictable
compared to stocks — not that a loss is impossible.

Bonds didn't behave unpredictably. Duration is a known, calculable sensitivity — the −0.51% wasn't a bond fund malfunctioning, it was
exactly what a 5.8-year-duration fund does when rates rise as much as they did.

A word of honesty

This comparison used one specific five-year window — one that happened to include a sustained rate-hiking cycle, which is close to the
worst-case scenario for a bond fund's price return. A different five years, especially one with falling rates, would show AGG's price
appreciating instead of declining, alongside its steady interest income.

It's also worth separating two different jobs "safer" can mean. Lower volatility and a smaller expected loss in a downturn are real,
measurable properties AGG has regardless of which five-year window you pick — that part of "safer" held up. What didn't hold up in this
specific window was the assumption that safer also means "won't lose money" or "protects against inflation." Bonds are frequently held
for reasons beyond total return at all — reducing a portfolio's overall swings, or providing cash to draw on when stocks are down — jobs
this single comparison doesn't measure. Not investment advice.

Final Thoughts

This is the twenty-ninth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and the first to test the single most repeated
piece of investing advice there is: bonds are safer.

Two prompts put the trade-off in front of an actual number instead of a slogan.

So here's what it cost: over the five years checked, AGG's lower volatility (3.21% vs. VOO's 13.25%) came paired with a 5-year return
of −0.51%, against VOO's 13.09%. "Safer" wasn't false — the bond fund really did swing less. It just turned out to mean "loses less
dramatically," not "doesn't lose," and in a rate-hiking window, even that smaller loss was still a loss. The word was accurate. It just
wasn't the whole sentence.

If this made you curious, the MCP Server is free to try — The
Setup walks you through it.

← Part 28: One Number, Two Meanings: What Beta Actually Measures

“The Market” Isn't One Thing: Watching Sectors Take Turns

Jaroslav Šmarda — Tue, 29 Sep 2026 11:03:51 +0000

Python for programmers, prompts for data analysts.

"The market was up 20% this year" is one of the most compressed sentences in finance. It blends technology companies, oil producers,
banks, utilities, and drugmakers into a single number — as if they all moved together.

They don't. Some years one corner of the market carries everything; other years that same corner drags. Traders call the pattern "sector
rotation." Let's pull the eleven sectors apart and watch who led, who lagged, and whether last year's winner tells you anything about
next year's.

Want to try this yourself? The EODHD MCP Server is what
pulled the data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers
everything you need before your first prompt.

Pull the eleven sectors apart

🟧 PROMPT

Use the eodhd MCP to get yearly returns for the
eleven SPDR sector ETFs from 2021 to today, and
show the best and worst sector each year.

Best and worst sector, year by year:

2021 — Energy (XLE) +53.3% · Communication (XLC) +16.0%

2022 — Energy (XLE) +64.3% · Communication (XLC) −37.6%

2023 — Technology (XLK) +56.0% · Utilities (XLU) −7.2%

2024 — Communication (XLC) +34.7% · Materials (XLB) +0.2%

2025 — Technology (XLK) +24.6% · Consumer Staples (XLP) +1.5%

2026 so far — Energy (XLE) +42.8% · Consumer Discretionary (XLY) −7.0%

Look at 2022 alone: the best sector gained 64%, the worst lost 38%. That's a gap of more than 100 percentage points, within the same
"market" and the same twelve months. Any single number describing "how the market did" that year was an average of two completely
different experiences.

Does last year's winner tell you anything?

🟧 PROMPT

For each year, where did the previous year's best
and worst sector finish the following year?

Last year's best sector, ranked the next year (out of 11):

Energy, best in 2021 → #1 in 2022

Energy, best in 2022 → #9 in 2023

Technology, best in 2023 → #5 in 2024

Communication, best in 2024 → #2 in 2025

Technology, best in 2025 → #2 in 2026 so far

Last year's worst sector, ranked the next year:

Communication, worst in 2021 → #11 in 2022 (worst again)

Communication, worst in 2022 → #2 in 2023, up 52.8%

Utilities, worst in 2023 → #4 in 2024

Materials, worst in 2024 → #7 in 2025

Consumer Staples, worst in 2025 → #6 in 2026 so far

There's no clean rule here, but there is a tilt. Energy won two years running, then fell to ninth. Communication finished last two years in a row, then jumped to second with a 53% gain. Across these five handoffs, last year's winners averaged 3.8th place the following year, about two places better than the 6th a random pick would average. Last year's losers averaged exactly 6th, right where chance would put them.

Five handoffs is still a small sample. Five random picks would average 3.8th or better roughly one time in fourteen, so luck can't be ruled out, and the winners weren't independent draws: Energy led twice and Technology led twice. What the table shows beyond doubt is how fast the order reshuffles, and how badly "buy whatever led last year" or "avoid whatever lagged" could have gone in the wrong year. Chasing 2022's winner meant riding Energy into a flat 2023. Abandoning 2022's loser meant missing Communication's rebound.

A word of honesty

A few things about this comparison deserve naming.

Calendar years are an arbitrary way to slice the data. Measure the same eleven sectors from July to July, or quarter by quarter, and the
winners and losers would shuffle differently — some of 2022's 100-point gap between Energy and Communication came from where January 1st
happened to fall. The pattern of sectors taking turns holds up; the exact rankings depend on where you draw the lines.

The window is also short: under six years, five year-to-year handoffs. That's enough to show how much the order moves, and nowhere near
enough to prove whether it moves randomly or follows a cycle. People who study sector rotation seriously look at decades of data,
alongside interest rates and the business cycle, and still argue about how predictable it is.

And a sector ETF is less diversified than its name suggests. XLK, XLC, and XLY are each dominated by a handful of giant companies, so
"Technology had a great year" can mostly mean "two or three stocks had a great year." Treat each line in the table as the story of a few
heavyweights, not of an entire industry. Not investment advice.

Final Thoughts

This is the thirty-second article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and it takes apart a number every other article
has quietly leaned on: "the market."

Two prompts split one index into eleven sectors, then checked whether the leaders stayed in front.

So here's what they found: in 2022, the best sector gained 64% and the worst lost 38% — a gap of more than 100 percentage points inside the same market, in the same year. And the sector that finished last that year finished second the next. "The market" is an average of very different stories, and the order of those stories keeps reshuffling. Last year's leader tended to stay near the top in this sample, but not reliably enough to lean on: Energy went from first to ninth in a single year.

If this made you curious, the MCP Server is free to
try — The Setup walks you through
it.

← Part 31: Before You Panic About Insider Selling, Check the Code

Before You Panic About Insider Selling, Check the Code

Jaroslav Šmarda — Fri, 25 Sep 2026 11:19:10 +0000

Python for programmers, prompts for data analysts.

Every time a company's CEO or CFO sells a big chunk of stock, someone posts about it — usually with a headline implying the insider
knows something bad is coming. SEC Form 4 filings, the disclosures that trigger those headlines, are public and easy to pull. Reading
them correctly is a different matter.

Let's pull real Form 4 filings and see what the raw numbers actually say, once you check the fine print.

Want to try this yourself? The EODHD MCP Server is what
pulled the data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers
everything you need before your first prompt.

Pull the raw filings

🟧 PROMPT

Use the eodhd MCP to get Amazon's most recent
Form 4 insider filings.

The last ten filings include: CEO Andy Jassy sold $5,180,213 worth of Amazon stock on August 21, 2026, across four separate
transactions. Executive Chair Jeff Bezos disposed of 415,580 shares over two filings on August 25–26. AWS CEO Matt Garman, CFO Brian
Olsavsky, and three other senior executives all show sales in the same window, several exceeding $1 million each.

Read that paragraph alone, and it sounds like the entire leadership team is heading for the exits at once — millions of dollars in
stock, sold within days of each other, right around the same price level.

Ask what the transaction codes actually mean

🟧 PROMPT

Check the transaction codes and footnotes on those
filings — were these discretionary decisions?

Every single "sell" transaction in that batch — Jassy's, Garman's, Olsavsky's, Reynolds's, Zapolsky's, Herrington's — carries
transaction code "S" alongside a footnote citing a Rule 10b5-1 trading plan, each one adopted months before the sale: Jassy's plan dates
to November 14, 2025; Garman's to May 4, 2026. These aren't decisions made the week of the sale. They're pre-scheduled disposals, set up
long in advance specifically so they can't be timed around inside information.

Bezos's 415,580 "disposed" shares carry an entirely different code: "G," for gift. Price per share: $0. Total value: $0. He didn't
sell anything — he donated the shares to non-profit organizations.

Every alarming number in the first prompt turned out to be something other than what it looked like. Not one of the ten filings in this
sample was a same-week, no-notice, "I know something you don't" sale.

A word of honesty

This sample — ten filings, one company, one narrow window — doesn't prove that insider selling never signals anything.

Rule 10b5-1 plans exist precisely because some insider selling would otherwise be suspicious, or at least look that way; they're a
legal shield, not a guarantee of pure intent. An executive can still adopt, modify, or cancel a plan when they choose to — and a plan
set up right before bad news becomes public knowledge has drawn real regulatory scrutiny in other cases, just not in the filings checked
here. The absence of same-week discretionary selling in this batch is a fact about this batch, not a law of insider trading.

It's also worth noting what this data doesn't answer: whether the volume of scheduled selling itself means anything — a plan selling 5,
000 shares a month reads very differently from one liquidating a large stake all at once, even though both would carry the identical
10b5-1 footnote. Reading the code correctly is the first step, not the whole analysis. Not investment advice.

Final Thoughts

This is the thirty-first article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and it closes the loop this series opened with
SEC EDGAR back in Part 18: the raw filing has the truth, but only if you read past the headline number.

Two prompts pulled the alarming version first, then checked what the codes actually said.

So here's what they found: every one of the ten Form 4 filings checked — millions of dollars in apparent selling — turned out to be
either a Rule 10b5-1 plan set up months in advance, or, in Bezos's case, a charitable gift worth $0 in proceeds. None of it was a
same-week decision made on fresh information. The filing told the truth the whole time. The headline just skipped the footnote.

If this made you curious, the MCP Server is free to
try — The Setup walks you through
it.

← Part 30: The Volatility Crush: What Happens to IV the Day After Earnings

The Volatility Crush: What Happens to IV the Day After Earnings

Jaroslav Šmarda — Fri, 25 Sep 2026 11:09:58 +0000

Python for programmers, prompts for data analysts.

Implied volatility isn't constant — Part 15 already showed it shifts across strikes on the same day. It also shifts across time, and
nowhere more dramatically than around a single, predictable event: earnings.

Before a company reports, nobody knows what the numbers will say, and options pricing reflects that uncertainty with elevated IV. The
moment the report lands, the uncertainty resolves — whatever the numbers are, they're no longer unknown — and IV tends to collapse,
often within hours. Traders call it the "volatility crush." Let's find a real one.

Want to try this yourself? The EODHD MCP Server is
what pulled the data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers
everything you need before your first prompt.

Find a real earnings crush

🟧 PROMPT

Use the eodhd MCP to find AAPL's most recent
earnings date, then get implied volatility for the
near-the-money call before and after the report.

AAPL reported on July 30, 2026 (after market close) — EPS $2.02 vs. a $1.88 estimate, a 7.4% positive surprise. The near-the-money
$335 call, expiring August 21:

July 29 (day before): IV 30.72%

July 31 (day after): IV 27.73%

A drop of 3 percentage points — about a 10% relative decline — in a single trading day, on an option that didn't even expire for
another three weeks.

The earnings beat was good news. AAPL's stock fell 7.4% the next day anyway — a move already covered back in Part 11 of this series. IV
fell too, despite that sharp move, because it isn't pricing "will this go up or down." It's pricing "how much don't we know yet" — and
the moment the report landed, that uncertainty was gone, whichever direction the stock went.

Is 10% a big crush, or a small one?

🟧 PROMPT

Is a 10% relative drop in implied volatility a
dramatic earnings crush, or a mild one?

It's on the mild end. The sharpest volatility crushes usually show up in options expiring within days of the report — weekly
contracts where the earnings-day uncertainty makes up most of their remaining time value, so resolving it can cut IV by 30% or more in a
single session. This $335 call had 20 days left even after the report — three more weeks of ordinary market uncertainty still baked into
the price, diluting how much of its IV was ever earnings-specific to begin with.

The lesson isn't "the crush didn't happen." It's that how much crush you see depends on how much of an option's remaining life the event
actually accounted for — a fact this series has now touched twice: Part 15 showed IV varies by strike; this shows it varies by how close
expiration sits to the event you're pricing for.

A word of honesty

Two things make this one measurement messier than the clean number suggests.

The $335 strike started exactly at-the-money on July 29, but AAPL's 7.4% drop pushed the stock away from it — by August 3, that same
strike was roughly 10% out-of-the-money. Part 15 already showed IV varies by moneyness, not just by time. So some of the 3-point decline
is genuine earnings crush, and some of it is just this contract drifting into a lower-IV part of the skew as the stock moved beneath it.
This data can't cleanly separate the two effects from each other.

And this is one earnings report, for one company, with one particular kind of surprise (a beat, followed by a drop for unrelated
reasons). A report that missed estimates, or one where price and expectations moved together, could show a different-shaped crush
entirely. Treat the mechanism — uncertainty resolves, so IV falls — as reliable; treat any single measured number, including this one,
as a snapshot of how it played out this one time. Not investment advice.

Final Thoughts

This is the thirtieth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and it revisits a stock this series has met
before. Part 11 watched AAPL's options amplify a 7.4% price drop. This time, the same event, seen through implied volatility instead of
price.

Two prompts found the crush, then sized it honestly.

So here's where it lands: the near-the-money AAPL call lost 3 points of implied volatility — about 10% — in the single session after
earnings, despite the stock itself moving sharply. That's a real but modest crush, smaller than a weekly option would have shown,
because three weeks of ordinary uncertainty were still baked into the price alongside the earnings-specific kind. IV didn't fall because
the news was good or bad. It fell because, either way, nobody had to wonder anymore.

If this made you curious, the MCP Server is
free to try — The Setup walks you
through it.

One Number, Two Meanings: What Beta Actually Measures

Jaroslav Šmarda — Fri, 25 Sep 2026 10:50:55 +0000

Python for programmers, prompts for data analysts.

Beta is one of the most quoted numbers in finance — "this stock has a beta of 1.5" gets said constantly, usually as shorthand for
"risky" or "volatile." But beta isn't actually a measure of how much a stock moves. It's a measure of how much a stock moves relative
to the market — and that distinction turns out to matter more than the number itself.

Let's ask for a stock's beta, and then ask what it would take to prove that number means what everyone assumes it means.

Want to try this yourself? The EODHD MCP Server is what pulled
the data above — connect it to Claude and ask your own questions (affiliate link).

New here? The Setup covers
everything you need before your first prompt.

Ask for the number, then build it yourself

🟧 PROMPT

Use the eodhd MCP to get AMZN's beta, then
calculate it independently from five years
of daily returns against SPY.

EODHD's reported beta: 1.443. Calculating it independently from 1,254 trading days of AMZN and SPY daily returns: 1.491.

The two numbers are close — both say AMZN moves roughly 1.4 to 1.5 times as much as the market — but they aren't identical, even
though they're trying to measure the same thing.

Beta of 1.45-ish means: on days the market moves 1%, AMZN has historically moved about 1.45% in the same direction. That's the headline.
The gap between 1.443 and 1.491 is where the interesting part starts.

Change the window, get a different answer

🟧 PROMPT

Recalculate beta using 1 year, 2 years, and
5 years of daily returns, and compare.

1-year beta: 1.432

2-year beta: 1.353

5-year beta: 1.491

EODHD's reported figure: 1.443

Four numbers, all claiming to answer "what's AMZN's beta?", ranging from 1.353 to 1.491 — a spread of nearly 14%. None of them are
wrong. Beta isn't a fixed property of a stock, like its ticker or its founding date. It's a statistical estimate, and every estimate
depends on choices someone made: which benchmark counts as "the market," how far back to look, and how often to sample returns. Change
any of those choices, and the "same" number moves.

That's the second meaning hiding behind the first. Beta answers "how sensitive is this stock to the market" — but only after you've
quietly answered a second question first: sensitive according to which window, against which benchmark. Skip that second question, and
the first one has no single right answer.

A word of honesty

Even after picking a window and a benchmark, beta has real limits worth naming.

It's backward-looking by construction — every number above describes how AMZN has moved relative to the market, not how it will. A
company's risk profile can shift for reasons beta can't see coming: a new business line, a management change, a shift in what investors
expect from the stock next. The 5-year beta of 1.491 already blends together very different chapters of Amazon's story, smoothed into
one coefficient that no single day of that history actually looked like.

Beta also assumes a straightforward linear relationship — that AMZN moves proportionally with the market in both directions, up and down
alike. In practice, many stocks move more sharply on the downside than the upside (or vice versa), a pattern a single beta number
averages away rather than reveals. If you want to know how a stock behaves specifically during market crashes, beta calculated across
all conditions isn't answering that question, even though it's often used as if it does. Not investment advice.

Final Thoughts

This is the twenty-eighth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, continuing where Part 26 left off — from "do two
things move together" to "how much does one thing move relative to another."

Two prompts pulled one reported number, then rebuilt it four different ways.

So here's where it lands: AMZN's beta ranged from 1.353 to 1.491 depending only on which window you chose — a 14% spread hiding behind
a statistic most people quote as if it were a single, fixed fact. Beta isn't wrong to trust. It's incomplete to trust without asking
which beta, over what period, against what benchmark. The number was never the whole answer. The choices behind it were.

If this made you curious, the MCP Server is free to try
— The Setup walks you through it.

← Part 26: Two Lines That Move Together, For No Reason At All