DEV Community: Jaroslav Šmarda

Prices Nobody Saw: The Lookahead Hidden in Adjusted Close

Jaroslav Šmarda — Tue, 03 Nov 2026 15:36:35 +0000

Python for programmers, prompts for data analysts.

On November 16, 2018, Coca-Cola closed at $50.17. That's the price people paid that day. Open today's adjusted close for the same day, and you'll see $39.37. Nobody ever paid $39.37 for a
Coca-Cola share in November 2018. The number exists only because of dividends paid in the years after it.

In the last two parts we used the adjusted close as the honest measure of total return, and for that job it is. But after Part 36, a reader, Arhan Canli, pointed out a trap: a backtest
that runs on today's adjusted prices sees numbers no one could have seen at the time. For some rules that doesn't matter at all. For others it moves a signal by years.

In this part we find out which is which, using Coca-Cola's last ten years. And we look at the three dates EODHD gives for every dividend, to see when each one was actually known.

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

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

Two prices for the same day

The data is the same as in Part 37: Coca-Cola's raw closes and dividends from October 2016 to October 2026, and EODHD's adjusted close for the same days. The question is how far apart the
two columns are.

🟧 PROMPT

For the first trading day of each year since 2017,
show Coca-Cola's raw close next to today's
adjusted close, and how much lower the adjusted
one is.

The further back you go, the bigger the gap:

Date	Raw close	Today's adjusted close	Adjusted is lower by
Jan 3, 2017	$41.80	$30.92	26.0%
Jan 2, 2019	$46.93	$37.12	20.9%
Jan 4, 2021	$52.76	$44.53	15.6%
Jan 3, 2023	$62.95	$56.42	10.4%
Jan 2, 2025	$61.84	$58.92	4.7%
Jan 2, 2026	$69.12	$67.80	1.9%

Each later dividend lowers every earlier adjusted price a little. A price from 2017 has had almost 40 dividends taken off it; a price from 2026 only three.

So which column is "right"? Both, for different questions. The adjusted close answers: how much has an investment made since that day, dividends included? The raw close answers: what did a
share cost that day?

A person in January 2017 could only see the raw column. The adjusted column for 2017 didn't exist yet. It was written later, one dividend at a time. That's what "as known then" means: on
any day, the adjusted close as it stood that day was simply that day's raw price. The adjusted column in the table is that price, rewritten by every dividend since.

The $50 rule

Now a rule that looks at the price level. It's deliberately simple: buy Coca-Cola the first day it closes above $50.

🟧 PROMPT

On which day did Coca-Cola first close above $50?
Answer twice: once using the raw close, once using
today's adjusted close.

Using the raw close: November 16, 2018, at $50.17. Using today's adjusted close: December 13, 2021, when the adjusted value reached $50.28. The raw close that day was $57.76.

Across all 2,513 trading days, the two series disagree about whether Coca-Cola was above $50 on 491 of them, about one day in five.

A backtest on today's adjusted close would report that the rule bought in December 2021, three years late, on a day when the real price was $57.76. No trader following that rule in real
time would ever have done that. In November 2018 the screen showed $50.17, and the rule would have fired.

That's the lookahead Arhan described. The backtest uses a number that was only created later, by dividends that hadn't been paid yet. It doesn't need a mistake in the code. It only needs
the wrong column.

Any rule built on the price level has this problem: a "price above $5" filter, a minimum dollar volume, a stop-loss at a fixed price, a target price. On a dividend payer like Coca-Cola,
the further back the backtest goes, the bigger the error.

Why returns are safe

So is today's adjusted close useless for backtests? No. Arhan's comment had a second half, and it's the reassuring one: anything that only uses the ratio between two days is safe.

🟧 PROMPT

What was Coca-Cola's return from November 16, 2018
to December 13, 2021, dividends included?
Calculate it two ways: from today's adjusted
close, and day by day from the raw closes, adding
each dividend on its ex-date.

From today's adjusted close: 27.72%. Day by day from the raw closes plus dividends: 27.74%. The tiny gap is rounding, because EODHD's adjusted close has four decimals. For the record,
the raw price alone rose only 15.13%.

The same holds for every single day: the daily return from today's adjusted close matches the raw close plus that day's dividend on all 2,513 days, within 0.04 percentage points.

The reason is simple arithmetic. A dividend paid in 2024 lowers both the 2018 price and the 2021 price by the same factor. When you divide one by the other, that factor cancels out. Every
later dividend cancels the same way. Only the dividends paid between the two days are left in the ratio, and those are exactly the ones an investor holding the stock in that period would
have received.

So the rule of thumb is short. Returns, percentage changes, and anything built only from them are safe on today's adjusted close: a 12-month momentum, a correlation, a volatility measured
in percent. Price levels are not: thresholds, stops and filters in dollars. Neither is anything built from price differences in dollars, like an average daily range measured in dollars,
because a difference of two scaled prices is scaled too.

Three dates for one dividend

The price is only half of it. A backtest can also look ahead through the dividends themselves, if it uses a dividend before anyone knew about it. EODHD gives three dates for every
Coca-Cola dividend, and each answers a different question.

🟧 PROMPT

For Coca-Cola's dividends over the last ten years,
how many days usually pass between the declaration
date, the ex-dividend date and the payment date?
When were the yearly raises announced?

The declaration date is when Coca-Cola announced the dividend. The ex-dividend date is the first day the stock trades without it; that's the day the price drops and the day the adjusted
close uses. The payment date is when the cash arrives.

Over the 40 dividends, the declaration came a median of 44 days before the ex-date, anywhere from 21 to 62 days. The payment followed a median of 18 days after the ex-date.

All ten raises were announced in February, 21 to 28 days before the March ex-date. The latest one, from $0.51 to $0.53, was declared on February 19, 2026, with an ex-date of March 13.

So between February 19 and March 13, 2026, the new dividend was public, but the price hadn't moved for it yet.

That decides which date a backtest should use, and it depends on the question:

Adjusting prices: the ex-date. That's when the price actually drops.
Anything that uses the dividend as information, such as a dividend yield or a rule that reacts to a raise: the declaration date. Before it, nobody knew the number.
Cash in the account: the payment date.

The trap is subtle. Say a backtest computes Coca-Cola's dividend yield on February 10, 2026, from a dividend list downloaded today. If it takes the latest dividend in the list, it gets $0.
53, a number that wasn't public for another nine days. If it takes the latest dividend by ex-date, it's safe on February 10, but after February 19 it keeps using $0.51 for three more
weeks, although the raise was already public. Only the declaration date gives the number that was actually known. That's what Arhan meant by storing the announcement date: rebuild
everything "as of D" from what was announced by D.

A word of honesty

The declaration dates come from today's dividend records, not from an archive of what a database showed back then. If a date or an amount was corrected later, the record shows only the
corrected version. A truly point-in-time backtest needs snapshots of the data as it was published, and that's a bigger project than one article.

The dates also have no time of day. Dividend announcements come as press releases, and whether one came before the market opened or after it closed changes which day's price could have
reacted. Counting from the next trading day is the safe choice.

This is one stock and one deliberately simple rule. The size of the effect depends on how much a company pays out and how far back the backtest goes. For a stock with a small dividend it's
smaller. For a stock with a split, it's much larger: as Part 33 showed, a split rescales every earlier price by the full split ratio, not by a fraction of a percent.

And the fix has a cost. Running a level-based rule correctly means using, on each day, the prices as they stood that day, which in practice means the raw close for price levels and the
adjusted close only for returns. That's more work than loading one column. Not investment advice.

Final Thoughts

This is the thirty-eighth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and the fifth about the adjusted close, after Parts 33, 35, 36 and 37. Part 36 rebuilt it, Part 37 showed what it
adds. This one showed where it misleads, an idea that came from a reader, Arhan Canli.

Here's what came out: today's adjusted close is the right column for returns and the wrong one for price levels. A rule that waits for Coca-Cola to pass $50 fires in November 2018 on
the prices people actually paid, and in December 2021 on today's adjusted prices. Three years apart, from the same data. The return over the same period comes out the same on both, 27.7%.

The dividends follow the same logic. Use the ex-date to adjust prices, and the declaration date for anything that depends on knowing the dividend. Ask of every number in a backtest: could
anyone have seen this on that day?

Next time I want to look at the other way a company can return cash to its shareholders. Apple pays a small dividend, but it spends far more buying back its own shares. Buybacks never show
up in the adjusted close at all. So how much did they matter?

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

← Part 37: The Other 40%: How Much of Coca-Cola's Return Came from Dividends

The Other 40%: How Much of Coca-Cola's Return Came from Dividends

Jaroslav Šmarda — Fri, 30 Oct 2026 12:14:12 +0000

Python for programmers, prompts for data analysts.

In the last part we rebuilt Apple's adjusted close from raw prices, one split and 31 dividends, and matched EODHD to the fourth decimal. Dividends turned out to be a small part of Apple's
story. Over almost eight years they added 47 percentage points to a return of 817%.

At the end I promised to run the same recipe on a company where the dividend is the main story. Coca-Cola is the obvious choice. It has raised its dividend every year for decades, and the
payout is several times larger than Apple's, relative to the price.

So the question for this part is simple: over ten years, how much of a Coca-Cola investor's return came from the price, and how much from the dividends?

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

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

The ingredients again

Same three ingredients as last time: the prices as they actually traded, every split, every dividend.

🟧 PROMPT

Use the eodhd MCP to get Coca-Cola's raw daily
closing prices for the last ten years, plus every
stock split and every dividend in that period.

From October 28, 2016 to October 28, 2026 there are 2,513 trading days. Coca-Cola didn't split its stock in that period. It paid 40 quarterly dividends, rising from $0.35 per share in
November 2016 to $0.53 in September 2026. The raw close was $42.23 at the start and $91.73 at the end.

No split makes this recipe simpler than Apple's. There is no second dividend size to trip over: for every one of the 40 payments, value and unadjustedValue are the same number.

The dividend went up every year, from $1.48 a year at the start to $2.12 now. Yet the yield fell, from about 3.5% of the price to about 2.3%. Both are true at once, because the price grew
faster than the dividend.

The raw prices passed the same check as Apple's: all 2,513 closes have at most two decimals, as a real exchange quotes them.

Three ways to count the same ten years

The recipe is the one from Part 36: walk backwards from today, and at each dividend scale every earlier price by (1 − dividend ÷ previous day's close).

🟧 PROMPT

Rebuild Coca-Cola's adjusted close from those raw
prices and dividends, the same way as for Apple,
and compare it with EODHD's adjusted close. Then
tell me the ten-year return three ways: price
only, price plus the dividends kept as cash, and
with every dividend reinvested.

The rebuilt series matches EODHD's adjusted close on all 2,513 days, within 0.0002%. The three returns:

	10-year return	Per year
Price only ($42.23 → $91.73)	+117.2%	8.1%
Price + dividends kept as cash	+158.6%
Dividends reinvested (total return)	+196.2%	11.5%

The middle row is the one I hadn't thought about before. Over ten years Coca-Cola paid $17.48 per share in dividends, 41% of the starting price. Kept in a drawer, that cash adds 41
percentage points. Reinvested, the same dividends add 79. The extra 38 points come from the shares that earlier dividends bought, which then paid dividends of their own.

So reinvested dividends made up 79 of the 196 percentage points, or 40% of the total return. That's the "other 40%" in the title.

Apple and Coca-Cola side by side

Put the two parts next to each other, and the difference is hard to miss.

🟧 PROMPT

Compare what dividends added for Apple in Part 36
with what they added for Coca-Cola here. Why is
the share so different?

For Apple, from January 2019 to October 2026, the price alone rose 770.0% and the total return was 817.4%. Dividends added 47.5 percentage points, about 6% of the total. For Coca-Cola,
over ten years, the price rose 117.2% and the total return was 196.2%. Dividends added 79 points, 40% of the total.

Two things decide the share. The first is the dividend yield: Apple paid out around one percent of its price a year or less, Coca-Cola about three percent. The second is how fast the
price grew. Apple's price grew so fast that even a growing dividend stayed a small part of the story. Coca-Cola's price grew slowly and steadily, so the dividends had room to matter.

The two periods aren't the same length, so this isn't a race between the two stocks. It's a lesson about charts.

For Apple, a price chart tells almost the whole story. For Coca-Cola, a price chart leaves out 40% of what an investor actually got. Compare a growth stock with a dividend stock on price
charts alone, and the dividend stock looks worse than it was. The fair comparison is total return against total return, which is exactly what the adjusted close gives you.

A word of honesty

Taxes come first. The 196% assumes every dollar of dividend was reinvested. A real investor outside the US loses part of each dividend to US withholding tax before it arrives: for a Czech
investor that is usually 15% with the right form filed, 30% without it, and there may be more to pay at home. With 15% withheld, the total return over these ten years drops by about 13
percentage points; with 30%, by about 26. The price return doesn't change. Taxes hit exactly the part this article is about.

I picked Coca-Cola because it is famous for its dividend. That makes it a good example, not a typical stock. Many companies pay no dividend at all, and some cut theirs when times are hard.

The window matters too. Coca-Cola's price rose sharply in 2026. Measured to the first trading day of 2026 instead, the price was up 64%, the total return 118%, and dividends made up 46% of
it, not 40%. Move the start or the end, and the share moves with it.

And the rebuild assumes reinvestment at the close before each ex-dividend date, with no fees and fractional shares allowed. Other reasonable conventions give slightly different totals, by
less than a percentage point here. Not investment advice.

Final Thoughts

This is the thirty-seventh article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and the fourth about the adjusted close, after Parts 33, 35 and 36. Part 36 showed how to rebuild it. This part
showed what it hides.

Here's what came out: over ten years, 40% of a Coca-Cola investor's return came from dividends, not from the price. For Apple it was about 6%. The same recipe, the same day-by-day
check against EODHD, and a very different answer, because one company returns its profits as dividends and the other mostly doesn't.

So when you compare stocks, compare total returns. A price chart is fine for a stock that pays little. For a dividend payer, it leaves out a large part of the result.

Next time I want to take up an idea a reader, Arhan Canli, suggested after Part 36. EODHD's dividend records also carry the date each dividend was announced, not only the date it was paid.
That makes it possible to rebuild the adjusted close as it was known on any given day, using only the dividends announced by then. It's the version a backtest should use, and it's easy to
get wrong.

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

← Part 36: Rebuild It Yourself: Adjusted Prices from Raw Prices, Splits and Dividends

More Than a Sentence: What Actually Goes Into a Prompt

Jaroslav Šmarda — Mon, 26 Oct 2026 12:44:48 +0000

Everything that travels with a question

For six parts of this series I've treated a prompt as a sentence. I type it, Claude reads it, an answer comes back. One line in, one line out, like a function call with a single string
argument.

Last time, building a tiny MCP server, I found a crack in that picture. The docstring I wrote for my tool wasn't a comment for the next programmer. Claude read it every single time, before
it decided anything. Words I'd written once, days earlier, were part of every question I asked afterwards.

So I asked the obvious question.

"When I type a question, what do you actually get?"

Much more than the question. Your sentence arrives last, at the bottom of a fairly long package.

"How long?"

Usually far longer than anything you type. Instructions from the app you're using. Anything you've told it to remember about you. The files you attached. The descriptions of every tool
I'm allowed to use. Everything we've said so far in this conversation. And then, finally, your sentence.

"So my prompt is the smallest part of the prompt."

Often, yes. It's the part you see.

That reminded me of my first payroll programs. The user typed an employee number and pressed Enter. One field. Behind it, the program loaded the rules for the year, the company's settings,
the employee's contract, the previous months. The calculation depended on all of it, and the user saw none of it. Nobody thought the employee number was the whole input.

This time I wanted to open the package and look inside.

Instructions I never typed

"Start at the top. What's the first thing in the package?"

Instructions from the app. Before you write a word, the app has already told me who I am, what today's date is, how to format an answer, which tools I may use, and what I shouldn't do.
You don't see that text, but every answer you get is shaped by it.

"So the same sentence in two different apps…"

…is two different prompts. Same model, same question, different instructions above it. That's one more reason two people can get two answers, and neither of them did anything wrong.

That one I recognised at once. In payroll, every installation has a settings table: the company's rules, rounding, which allowances count where. The calculation is the same program
everywhere. The results differ because the settings above it differ, and the user filling in a form never sees them.

"And then?"

Then your own instructions. You told me once to answer in Czech, so I do, even though every article we write is in English. That sentence isn't in your question. It travels with it.

Then there's the part I wrote myself without thinking of it as a prompt. After a dozen articles in my other series, I got tired of repeating the rules: how a prompt is formatted, where the
affiliate note goes, that every article ends with an honest section and "Final Thoughts". So I wrote them down once, in a file Claude calls a skill.

When you start a new article in that series, I read the skill before I write anything. That's why part thirty-six looks like part six. Neither of us remembered the rules; they were
written down and loaded.

"So you don't learn them."

No. I don't carry anything from one conversation to the next unless it's put in front of me again. The skill is how it gets put there.

That's the oldest trick in my trade, just in a new place. A rule you have to remember is a rule that will be forgotten. A rule in a configuration file is applied every time.

Show, don't describe

"Is a skill just a list of rules?"

Partly. The most useful parts aren't rules at all. They're examples.

The skill for my series says how a prompt should look, and then it shows one: an orange square, the word PROMPT in bold, and the prompt itself in a grey code box. Thirty-six articles
later, every prompt looks exactly like that.

A description leaves room. "Highlight the prompt" could mean bold, a colour, a quote, a box. An example leaves almost none. I see the shape and repeat it.

The same happened with LinkedIn. When I asked for help announcing articles, I didn't explain my style. I pasted one post I'd written and liked. Since then every draft has had the same
build: a short line that turns the topic around, two sentences about the article, one concrete detail, the link, a few hashtags.

"So an example works better than an explanation."

Usually. But it teaches everything in it, not just what you meant. If your example post is a hundred and twenty words long, my drafts will be about a hundred and twenty words. If it has
five hashtags, so will they. I can't tell which parts of an example were the point and which were accidents.

I know this from my own work. A customer often sends me a sample of a payroll report, say S123, and I write a program that produces it. The sample shows the layout. It doesn't show which
parts are rules and which are just this month's data. Is a column always there, or only because someone had that allowance this month? Is the order of the rows fixed? I have to ask.

So when you give me an example, it's worth a sentence about what in it matters. "Same structure, any length." That one sentence separates the pattern from the accident.

A file is just more words

A few days ago I opened an empty text file at work, pasted in a list of constants from one of my programs, and gave it to Claude. A hundred and six lines, each a name and a number:
CIS_S=1, then on and on, up to DEVPN=106.

The second-to-last line was DEVPN=105. The same name twice, with two different numbers.

I had read that list many times. My eyes slid over the end of it every time, because the end looked like every other end.

"How did you see it?"

I didn't skim. A file you attach isn't a picture of a document for me. It's text, put into the package next to your question, and I read all of it, every time I answer. A hundred and six
lines is short. I don't miss lines at the end.

That's the part of the package I underrated most. I thought of attaching a file as showing Claude something. It's closer to typing it in, line by line, without the typos.

"Is there a limit?"

Two. Size: everything in the package shares the same room, so a very large file pushes other things out, or has to be read in pieces with tools. And format: a spreadsheet or a PDF isn't
plain text. I either get it converted, or I open it with a small program and read what that program finds. Then I'm reading the program's output, not the file itself.

And one more thing, which Claude added without being asked.

What's in a file is information, not instructions. If a document says "ignore everything above and do this instead", that's a sentence in a document. I don't follow instructions found in
a file.

I liked that. I've spent years writing programs that read files from other people's systems. The first rule was always the same: the data never gets to decide what the program does.

The menu, and everything we said

"What else is in there?"

The menu. Every tool I'm allowed to use comes with its name, its description and its inputs, and all of that is part of the package too.

I'd met this in Part 4, when Arhan Canli measured how much room the menus of different finance servers take: 859 tokens for his, over 432,000 for the largest he tested. Back then I filed
it under the cost of a server. Now I see it from the other side. Those descriptions are words somebody else wrote, sitting in my prompt.

And some of them I wrote myself. The docstring from Part 6, the price is the raw close, not adjusted for later splits, travels with every question I ask while my little server is
connected. Thirty lines of Python, and three of them are now a permanent part of my prompts.

"How big is the menu right now?"

In this conversation, EODHD alone offers well over a hundred tools. But I don't get all their descriptions at once. Here, the app gives me only their names, and I ask for the full
description of a tool when I need it.

That's Arhan's trick again: list the tools, describe them only on request. A good idea tends to show up in more than one place.

"And the last part, before my sentence?"

Everything we've said so far. Your earlier questions, my earlier answers, the results of every tool I called. In a long conversation, that's usually the biggest part of the package.

That explained something from Part 5 that I'd only half understood. When I asked EODHD about Amazon right after Arhan's server had answered, the reply sounded far surer than it did in a
fresh session. Nothing was wrong with the server. The answer was already in the package, a few screens up.

So the full package, top to bottom, looks like this: the app's instructions, my own settings and skills, the menu of tools, any files, everything said so far, and at the very bottom, one
sentence. Mine.

Final Thoughts

I started this series asking whether a prompt is "all this is". A sentence typed into a box seemed too thin to be a way of programming.

It turns out the sentence was never the whole thing. It's the last line of a package, and most of the package is written before I type anything: by the app, by the people who built the
tools, by earlier me, in settings and skills and docstrings, and by the conversation itself.

As a programmer I find that reassuring. A prompt behaves a lot like the programs I know: a small input on top of configuration, reference data and history. And most of that package I can
shape. I can write a rule down once instead of repeating it. I can give an example and say what in it matters. I can attach the file instead of describing it. I can write a tool's
description as carefully as its code. And when a comparison has to be fair, I can start with a clean package, in a fresh session.

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 part adds a step before the checking. When an
answer surprises me, I no longer look only at my sentence. I ask what else was in the package.

Next time I want to look at the opposite direction: programs that build the package themselves. Instead of a person typing into an app, Python code calls the model, chooses the
instructions, hands it the tools, and decides what to do with the answer. This time the program builds the package.

New to this series? Start with Part 1: Is That All This Is? — A Programmer Meets the Prompt. Part 4 measures how much room a
server's menu takes, Part 5 shows what an earlier answer does to a later one, and Part 6 builds the tool whose docstring now travels with every question. Many of my examples come from my other series,
Unlock Real-Time Market Intelligence with EODHD and Claude.

Rebuild It Yourself: Adjusted Prices from Raw Prices, Splits and Dividends

Jaroslav Šmarda — Tue, 20 Oct 2026 12:17:43 +0000

Python for programmers, prompts for data analysts.

Part 35 checked the split records against raw prices and found that every split leaves a fingerprint. But it kept one thing as a black box: the adjusted close itself. We trusted that
column and never asked how it was made.

Alexander Hübbert, a reader whose comments have shaped several parts of this series, suggested a different habit. Don't store adjusted prices at all. Store what actually happened: the raw
prices, the splits and the dividends. Then rebuild the adjusted series yourself, whenever you need it.

So that's what this part does, for Apple, over almost eight years. Along the way we'll meet a dividend that comes in two sizes, and a price from 2019 that has been rewritten 32 times.

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

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

Three ingredients

The recipe needs three things: the prices as they actually traded, every split, and every dividend. So I asked for all three at once.

🟧 PROMPT

Use the eodhd MCP to get Apple's raw daily closing
prices from January 2019 to today, plus every
stock split and every dividend in that period.

From January 2, 2019 to October 16, 2026 there are 1,959 trading days. In that time Apple split its stock once, 4-for-1 on August 31, 2020, and paid 31 quarterly dividends. The first,
in February 2019, was $0.73 per share; the latest, in August 2026, was $0.27.

A dividend that fell from $0.73 to $0.27 looks like bad news. It isn't. The early payments were made on old shares, before the split. One old share became four new ones, so $0.73 on one
old share is about $0.18 on each new one. Apple has actually raised its dividend almost every year.

That's the first lesson of the recipe: every number has to be in the same units as the prices it sits next to. Hold that thought; it comes back later.

Before cooking anything, I checked the main ingredient. In the last part a reader found that some "raw" prices were really rebuilt from adjusted ones, betrayed by too many decimal places.
Here, all 1,959 closes have at most two decimals, just as a real exchange quotes them. These are prices people actually paid.

Cooking it

Now the recipe itself. The rule is short. Start today and walk backwards through time. Each time you pass a dividend, scale every earlier price down by the share of the price that the
dividend paid out. Each time you pass a split, divide every earlier price by the split ratio.

🟧 PROMPT

Using only those raw closes, splits and dividends,
rebuild Apple's adjusted closing price yourself.
Walk backwards from today: at each dividend,
multiply all earlier prices by
(1 − dividend ÷ previous day's close);
at each split, divide all earlier prices
by the split ratio. Then compare
your result with EODHD's own adjusted close for
every day.

Done. The rebuilt series matches EODHD's adjusted close on all 1,959 days, within 0.0001%. A few examples:

Date	Raw close	Rebuilt	EODHD adjusted
Aug 28, 2020 (last day before the split)	$499.23	$120.9557	$120.9557
Aug 31, 2020 (split day)	$129.04	$125.0575	$125.0575
Jun 1, 2022	$148.71	$145.6579	$145.6579
Jan 2, 2025	$243.85	$242.0931	$242.0931

Every digit matches. The adjusted close is no black box. It's 32 multiplications, and anyone with the raw prices and the event list can repeat them.

That's exactly what Alexander meant: store what actually happened, and rebuild the rest whenever you need it.

The rebuild shows something else too. The adjusted close isn't just a price. It quietly includes the dividends.

From January 2, 2019 to October 16, 2026, Apple's adjusted close rose 817.4%. If you correct only for the split and ignore dividends, the price rose 770.0%. The difference, 47.5
percentage points, is the dividends, as if each one had been reinvested in the stock on the day it was paid.

So the two numbers answer different questions. 770% is how much the price of a share grew. 817% is how much an investor grew who held the share and reinvested every dividend. Neither is
wrong. Mixing them up is.

A dividend in two sizes

Remember the first lesson: every number has to be in the same units as the prices next to it. Here is where it matters.

EODHD gives every dividend two numbers. For February 2019 they are value 0.1825 and unadjustedValue 0.73. So I asked what the difference is.

🟧 PROMPT

Each Apple dividend has two amounts, value and
unadjustedValue. What's the difference, and which
one belongs in the rebuild?

unadjustedValue is what was actually paid per share on the day: $0.73 on one old share. value is the same payment divided by the later 4-for-1 split: $0.1825, expressed in today's
shares. After the split the two are equal. Before it, they differ by a factor of four.

The rebuild works with raw prices, the ones that actually traded. So it needs the amount actually paid, unadjustedValue. $0.73 against a raw close of about $170 is a payout of about 0.
43%. $0.1825 against the same close is about 0.11%. That's a quarter of the real dividend.

Nothing crashes if you pick the wrong one. Both fields are numbers, both look reasonable, and the formula happily accepts either. So I tried it:

With value instead of unadjustedValue, the seven dividends paid before the split shrink to a quarter of their real size. The total return comes out at 802.6% instead of 817.4%.
Almost 15 percentage points of dividends disappear, and the series no longer matches EODHD on any day before August 2020.

This is the quiet kind of mistake. No error, no warning, just a smaller number that looks perfectly believable. The only thing that caught it was the comparison with EODHD's own adjusted
close. Without a second source, 802.6% would have gone into the article.

The rule is the one from the first section: raw prices go with raw dividends, adjusted prices with adjusted dividends. Mixing the two is like adding crowns to euros. The arithmetic works.
The result doesn't.

The price that keeps changing

The recipe walks backwards from today. That has a consequence that surprised me more than anything else in this experiment: every new dividend changes every price before it. So the
adjusted close for a day in 2019 isn't a fixed number. It depends on when you ask.

🟧 PROMPT

Using the same recipe, what would Apple's adjusted
close for January 2, 2019 have been if I had asked
at different moments: just before the 2020 split,
at the start of 2023, at the start of 2026, just
before the August 2026 dividend, and today?

The raw close that day was $157.92. Here is how its adjusted value looked over time:

Asked on	Adjusted close for Jan 2, 2019
Jan 2, 2019 (the day itself)	$157.92
Aug 28, 2020 (just before the split)	$154.5164
Start of 2023	$38.1051
Start of 2026	$37.5388
Aug 7, 2026 (just before the latest dividend)	$37.4692
Oct 16, 2026 (today)	$37.4369

The big drop is the split: everything before it was divided by four. The small steps are the dividends. Each one shaves a fraction of a percent off every earlier price. Since January
2019, that price has been rewritten 32 times: once for the split and once for each of the 31 dividends.

So if you saved Apple's adjusted close in a spreadsheet in 2023 and compare it with EODHD today, the numbers won't match. Neither is an error. They are the same recipe, cooked on different
days.

And that is the strongest argument for Alexander's habit. Raw prices never change; a close of $157.92 on January 2, 2019 stays $157.92 forever. The list of events only grows: a new
dividend is added, nothing old is rewritten. If you store those two things, you can rebuild the adjusted series for any day, as it looked on any day. If you store only the adjusted close,
yesterday's copy goes quietly out of date with the next dividend.

A word of honesty

The perfect match proves less than it seems. It shows that my recipe and EODHD's recipe are the same, not that the recipe is the only right one. Other providers use slightly different
conventions. Some adjust only for splits, some apply the dividend on a different day, some ignore small special payouts. So their adjusted close for the same day can differ from EODHD's by
a few cents, and none of them is wrong. If you mix sources, rebuild from raw data and one recipe of your own.

The 817.4% total return is a textbook number. It assumes every dividend was reinvested instantly, at the price of the day, with no taxes and no fees. A real investor in Europe would have
lost part of each dividend to withholding tax and paid something to buy the extra shares. Treat it as the upper bound of what holding Apple returned, not as anyone's actual account.

The three ingredients all came from one source. I checked the raw prices for decimals and the result against EODHD's own adjusted close, but I didn't check the dividend amounts against
Apple's own announcements. If a dividend were wrong in the data, both my rebuild and EODHD's column would carry the same mistake, and they would still match perfectly. Checking a handful
of dividends against the company's investor-relations page is the cheap next step.

And all numbers here are a snapshot as of October 16, 2026. The next Apple dividend will rewrite every adjusted price in this article once more. That's not a flaw; it's the point of the
last section. Not investment advice.

Final Thoughts

This is the thirty-sixth article in the series Unlock Real-Time Market Intelligence with EODHD and Claude, and the third in a row about the adjusted close. Part 33 said: use the adjusted column. Part 35 checked the split
records behind it. This one opened the column itself and rebuilt it from scratch, an idea that came straight from a reader.

Here's what came out: the adjusted close is 32 multiplications, and anyone can repeat them to the fourth decimal. The hard part isn't the arithmetic. It's the units: raw prices with
raw dividends, adjusted prices with adjusted dividends. Get that wrong and nothing breaks; a number just quietly shrinks.

Apple is a gentle test. Its dividend is small, around one percent of the price a year or less, so dividends added "only" 47 percentage points over almost eight years. Next time I want to
run the same recipe on a company where the dividend is the main story, and see how far the price-only chart and the total-return chart drift apart when dividends are a big part of what an
investor actually gets.

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

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

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