DEV Community: Arhan Canli

1,285 strategy sleeves, frozen before the test: the year-by-year table is the warning

Arhan Canli — Fri, 16 Oct 2026 10:59:46 +0000

Most backtest write-ups report one number for the whole test window. I want to show what happens when you split the same test by year.

The protocol

We built 1,285 small strategies ("sleeves") in two blocks:

1,026 stock sleeves: 27 signals, each run inside every industry with at least 10 names, long the best-ranked and short the worst.
259 crypto sleeves: cash-and-carry per coin, long spot and short the same coin's perpetual, switched on while funding pays.

Everything was chosen on search years (stocks 1998 to 2017, crypto 2020 to 2022). The selection was written to a file, frozen_selection.json, and its SHA-256 (8d1803de7e04d3ee...) was pushed before the test ran. Then the frozen list was tested once on years the search never saw.

The headline

Block	Test years	Sharpe after costs	Before costs	Worst drawdown
Stocks, 1,026 sleeves	2018-01 to 2026-06	0.73 (t 2.12)	0.85	-14.8%
Crypto, 259 coins	2023-01 to 2026-09	4.19 (t 8.03)	8.03	-6.1%
Both at equal risk	2023-01 to 2026-06	3.42 (t 6.35)		-17.2%

The two blocks' correlation was 0.02. The stock block earned about half its search-year Sharpe (1.43), which is the usual decay. Read alone, the last row is the kind of number that gets posted.

The same test, by year

Year	Stocks	Crypto	Both
2023	1.54	7.12	4.59
2024	2.13	11.99	8.05
2025	0.31	0.42	0.41
2026 to date	-0.05	-3.01	-2.05

Since January 2025 the combined book's Sharpe is -0.44 (t -0.53, 366 days). The strong overall figure comes from 2023 and 2024.

The crypto side shows why. The average daily funding collected while a position was on was 0.0449% in 2024, 0.0095% in 2025 and about zero in 2026 (-0.0003%). The carry lives on that income. With it gone, switching coins on and off around zero funding costs more than it earns: before costs the 2026 crypto Sharpe is +0.98, after costs -3.01.

Two other things the search taught

Costs do not diversify. Every sleeve's costs add up while its noise cancels. Holding overlapping portfolios and trading through a no-trade band cut the stock book's costs to about 1.2% a year (0.0118 in the result file).
One bug, published. The first test run left out the frozen no-trade band (a runner bug). Its result (stocks 0.52, combined 3.16) is kept in the repo as test_result_run1_without_frozen_band.json. The corrected run applies the band the frozen file already named; nothing in the frozen file changed.

What this does not show

No sleeve is admitted to a live book. The forward record is the only clean test left, and the yearly table says the edge may be thinner now than the window average. A freeze and a single test protect you from fooling yourself during the search; they do not make the market keep paying.

Try it

The protocol, the frozen file and both result files are in the research/breadth-lab branch of github.com/arhancanli/alphac. The validation tools (deflated Sharpe, placebo tests) live in github.com/arhancanli/canlicapital, and canli-mcp is a free MCP server (MIT, no API key, runs locally): npx -y canli-mcp.

How do you report a test window whose last two years disagree with the first two: the average, the split, or both?

If this was useful to you, a star on the canlicapital repo is appreciated, and so is sending this to someone who'd use it.

Written with AI assistance. Every number is from test_result.json and RESULTS.md in research/breadth_lab on the alphac repo (saved in drafts/data on 2026-10-16).

Central banks' own policy rates against the BIS's copy: 9 of 9, and one convention to know

Arhan Canli — Fri, 16 Oct 2026 04:58:10 +0000

If you need policy rates for several countries, the Bank for International Settlements is the obvious place: its WS_CBPOL dataset has about forty central banks' policy rates as daily series, behind one free API. But it is a copy. I wanted to know whether it matches what the central banks publish themselves before using it in a tool.

The check

On three quarter-ends of 2026 I compared the BIS series with each central bank's own source:

the ECB's deposit facility rate, from the ECB's data portal;
the Bank of England's Bank Rate, from its statistical database;
the Fed's target range for the federal funds rate, from the New York Fed's daily data.

Date	ECB deposit rate	BIS euro area	Bank Rate	BIS UK	Fed target range	BIS US
31 Mar 2026	2.00	2.00	3.75	3.75	3.50 to 3.75	3.625
30 Jun 2026	2.25	2.25	3.75	3.75	3.50 to 3.75	3.625
30 Sep 2026	2.50	2.50	3.75	3.75	3.75 to 4.00	3.875

All nine agreed.

The convention: a range becomes its midpoint

The Fed doesn't set one rate, it sets a range. The BIS series has one number a day, and for the US that number is the midpoint of the range: 3.625 for 3.50 to 3.75. Compare it with the upper bound, as many headlines quote the Fed, and it looks 12.5 basis points wrong. The check above counts the BIS figure as agreeing when it sits inside the New York Fed's range, which it does on every date.

Two smaller things

The ECB publishes change dates, not a daily series. Its policy-rate series has one row per decision: the date the new rate took effect. To get the rate on a given day you need the last change on or before it, including changes from before your window (the deposit rate in force on 1 January 2026 was set on 11 June 2025). The tool returns the rate in effect on the first day you ask for, then each change.

The BIS can lag the announcement by a few days. For a decision made this week, read the central bank's own series first.

Try it

reference_rates in canli-mcp, a free MCP server (MIT, no API key), reads all of these: SOFR, the effective fed funds rate with the Fed's range, and other New York Fed rates; the euro short-term rate and the ECB's three policy rates; SONIA and Bank Rate; and the BIS series for about forty central banks.

npx -y canli-mcp

Two rates in one run_tool call:

{ "calls": [
  { "name": "reference_rates", "arguments": { "rate": "ecb_deposit", "start": "2026-01-01" } },
  { "name": "reference_rates", "arguments": { "rate": "policy:JP" } }
] }

The comparison script is mcp-markets/bench/global/crosscheck.mjs, with its saved results:

arhancanli/canlicapital: every MCP server, the check and its results.
arhancanli/alphac: the strategy research engine.

If this was useful to you, a star on the canlicapital repo helps a small project get found.

Which central bank's data have you found hardest to get at? I'd like to add it.

Written with AI assistance. The figures are from the check's saved results of 15 October 2026.

Europe's tagged annual reports against the same companies' SEC filings: 12 of 12

Arhan Canli — Thu, 15 Oct 2026 15:03:53 +0000

Companies listed on EU and EEA regulated markets file their annual reports in ESEF, the European Single Electronic Format, and UK-listed companies follow the UK's version of the same rule: an XHTML report with the figures tagged in XBRL. XBRL International collects the filings at filings.xbrl.org and serves each one as xBRL-JSON. That makes about 7,400 European filers' tagged figures free to read, with no API key.

I added a tool for them to canli-mcp (european_filings) and wanted an independent check that it reads the right facts. Some European companies also file an annual report with the SEC on Form 20-F, tagged in the same IFRS taxonomy. That is a second filing, to a different regulator, of the same figures, so the two should agree.

The check

Three companies, two years, two measures each. The ESEF side comes from european_filings; the SEC side comes straight from SEC's companyfacts API (the ifrs-full facts on 20-F filings), which the tool never reads.

Company	Year	Revenue (ESEF = 20-F)	Profit for the year (ESEF = 20-F)
TotalEnergies	2024	USD 214,550,000,000	USD 16,031,000,000
TotalEnergies	2025	USD 201,196,000,000	USD 13,357,000,000
Novo Nordisk	2024	DKK 290,403,000,000	DKK 100,988,000,000
Novo Nordisk	2025	DKK 309,064,000,000	DKK 102,434,000,000
Shell	2024	USD 284,312,000,000	USD 16,521,000,000
Shell	2025	USD 266,886,000,000	USD 18,119,000,000

All 12 matched to the unit. "Profit for the year" is IFRS ProfitLoss, which includes non-controlling interests, so it is not the same line as "income attributable to shareholders".

Three traps on the way

1. Periods end at midnight of the next day. In xBRL-JSON a duration is written like 2025-01-01T00:00:00/2026-01-01T00:00:00. That is calendar 2025, not a period that reaches into 2026. A balance-sheet instant written 2026-01-01T00:00:00 is the position at the end of 31 December 2025. Read the dates naively and every year-end balance lands in the wrong year.

2. "Revenue" has more than one tag. Novo Nordisk and Shell tag revenue as ifrs-full:Revenue. TotalEnergies uses ifrs-full:RevenueFromContractsWithCustomers, and so does ASML. A tool that reads one concept quietly reports "no revenue" for half the companies. It needs a list per measure, and it should say which concept each figure came from.

3. Names match more than one filer. "Novo Nordisk" also matches Novo Nordisk Fonden, the foundation that controls the company and files its own report. Legal forms ("A/S", "N.V.", "SE", "plc") have to be ignored, and the company has to rank above near-namesakes, or the first answer is the wrong entity. The tool lists the other matches, so a mismatch is visible.

What this does and doesn't show

It shows that the tool reads the totals the companies tagged, on the right periods and in their own currencies. It does not show that ESEF data is clean in general: these are three large, careful filers, and only two measures in two years. Smaller filers are another matter, and segment figures aren't read from these reports at all.

Try it

canli-mcp is a free MCP server (MIT, no API key):

npx -y canli-mcp

Then ask for a European company's annual report, or call run_tool with:

{ "name": "european_filings", "arguments": { "company": "Novo Nordisk", "year": 2025 } }

It returns the report's period, links to the report and its viewer, and the tagged totals with their concept, period, value, unit and precision. words finds any other tagged figure, such as "words": "net system sales" for ASML.

The cross-check script is mcp-markets/bench/global/crosscheck.mjs, with its results in results-2026-10-15.json next to it:

arhancanli/canlicapital: every MCP server, the check and its results.
arhancanli/alphac: the strategy research engine.

If this was useful to you, a star on the canlicapital repo helps a small project get found.

Have you used ESEF data? I'd like to hear where it disagreed with the PDF report.

Written with AI assistance. The figures are from the check's saved results of 15 October 2026.

Polymarket and Kalshi priced the Fed's October decision 4 points apart

Arhan Canli — Thu, 15 Oct 2026 10:00:46 +0000

Prediction markets usually get quoted as one number: "markets see a 75% chance the Fed holds". There are two big US venues for Fed decisions, Polymarket and Kalshi, and they don't always say the same thing.

At 07:46 UTC on 15 October 2026 I pulled every open market on the Fed's next decisions from both venues' public APIs, with the prediction_markets tool in canli-mcp. The raw output is saved with that timestamp, so every number below can be checked against it.

The October meeting (27 and 28 October)

Outcome	Polymarket	Kalshi
No change	75.5%	71.5%
Hike 25 bp	24.5%	27.5%
Anything else (cuts, bigger hikes)	under 1% each	under 1% each

"Probability" here is the middle of the best bid and the best ask, so it is a price, not a forecast. The quotes behind it: Polymarket "No change" 0.75 bid / 0.76 ask and "25 bps increase" 0.24 / 0.25; Kalshi "Fed maintains rate" 0.71 / 0.72 and "Hike 25bps" 0.26 / 0.29.

Three things I noticed

1. Four points apart on the same question. Both books are deep. Polymarket's October event has traded about $40.5 million, and Kalshi's about 11.1 million contracts (each pays $1 if its outcome happens). The spreads are one to three cents, so the gap is bigger than the spread. The two venues differ in fees, in who is allowed to trade on them, and in their exact resolution rules, and any of those can keep prices apart. If you quote "the market", say which one.

2. Kalshi disagrees with itself a little. Kalshi also runs "Fed funds rate after October meeting?" as a ladder of thresholds. "Above 4.00%" traded at 0.22 bid / 0.25 ask (23.5%). The target range is 3.75% to 4.00% today, so getting above 4.00% needs a hike, and the hike outcomes in the other market add up to 28% (27.5% for 25 bp plus 0.5% for more). The two quotes don't even overlap: the best ask for "Above 4.00%" (0.25) is below the best bid for "Hike 25bps" (0.26). The ladder is a much thinner market, about 0.37 million contracts traded against 11.1 million for the main October one, and I haven't checked the two contracts' exact settlement rules, so there may be a reason. If you trade these, I'd like to know what it is.

3. Further out, thinner books. Polymarket's December market has traded about $3.5 million and January's about $0.5 million. At those sizes a single trade can move the price, so read the volume before reading the percentage.

Pull it yourself

canli-mcp is a free MCP server (MIT, no API key). In any MCP client:

npx -y canli-mcp
# Claude Code
claude mcp add canli -- npx -y canli-mcp

Then ask for "prediction markets on the fed decision", or call the tool directly through run_tool:

{ "name": "prediction_markets", "arguments": { "query": "fed decision", "limit": 3 } }

Each row gives the venue, event, market, outcome, probability, bid, ask, last trade, volume and closing date. Polymarket's events also come with their resolution rules, which is where differences like the one in point 2 usually start.

These are traders' prices before fees and the spread, not forecasts and not investment advice, and access to each venue depends on where you live.

The code is on GitHub:

arhancanli/canlicapital: every MCP server, including prediction_markets in mcp-markets/src/predictions.mjs.
arhancanli/alphac: the strategy research engine.

If this was useful to you, a star on the canlicapital repo helps a small project get found.

Do you watch both venues, or trust one? I'm curious which one people treat as the reference price.

Written with AI assistance. Every number is from the tool output saved at 07:46 UTC on 15 October 2026.

The same SEC filing has two acceptance times, depending on which EDGAR file you read

Arhan Canli — Mon, 12 Oct 2026 05:00:23 +0000

If you pull filings from SEC's submissions API (data.sec.gov/submissions/CIK##########.json), each one comes with an acceptanceDateTime like 2026-07-14T14:30:38.000Z. The Z says UTC. For a large share of companies that is not true, and which companies depends on the file you read, not on the filing.

That matters whenever the time of day matters: whether results came out before the open or after the close, which trading day an insider purchase belongs to, or an event study's day 0.

What I measured

On 2026-10-11 I took 25 companies' submissions files: the 12 newest filings in each, plus 6 from December to February to cover standard time. That is 450 filings across 34 form types, 98 filing agents and three years.

For each one I compared acceptanceDateTime with the "Accepted" time printed on the filing's index page (.../{accession}-index.htm). That page is in US Eastern time and matches the filing's own SGML header.

What I found

Every file was either right for all its filings, or off by exactly one Eastern offset for all of them: +4 hours for filings accepted in daylight time, +5 hours in standard time. No other offset appeared, whatever the form, filing agent or time of day.

Right	Off by one Eastern offset
MSFT, GOOGL, XOM, PFE, KO, TSLA, NFLX, INTC, GE, F, O, SPY	AAPL, NVDA, AMZN, META, JPM, BAC, WMT, BRK, TSM, GME, PLTR, MRNA, Vanguard

So JPMorgan's results 8-K, accepted at 06:30 Eastern (10:30 UTC), shows up as 14:30Z: after the open instead of before it.

The same filing reads differently in two files. A Form 4 sits in both the company's file and the insider's own file. Apple's director Form 4s from 26 February:

Accession	Apple's file	Director's file	Index page (Eastern)
0001059235-26-000004	2026-02-27T04:34:19Z	2026-02-26T23:34:19Z	2026-02-26 18:34:19
0001216519-26-000004	2026-02-27T04:33:49Z	2026-02-26T23:33:49Z	2026-02-26 18:33:49

The director's files are right; Apple's file is five hours late (February is standard time). You can check it yourself with the standard library:

import json, re, urllib.request
UA = {"User-Agent": "Your Name you@example.com"}  # SEC asks for a contact
get = lambda u: urllib.request.urlopen(urllib.request.Request(u, headers=UA)).read().decode()
acc = "0001059235-26-000004"
for cik in (320193, 1059235):  # Apple's file, then the director's
    r = json.loads(get(f"https://data.sec.gov/submissions/CIK{cik:010d}.json"))["filings"]["recent"]
    print(cik, r["acceptanceDateTime"][r["accessionNumber"].index(acc)])
html = get(f"https://www.sec.gov/Archives/edgar/data/320193/{acc.replace('-', '')}/{acc}-index.htm")
print("index:", re.search(r'Accepted</div>\s*<div class="info">([^<]+)', html).group(1))

These are the values on 11 October. The files change, which is the next point.

The split follows each file's newest filing. Every file whose newest filing was accepted on or before 2 October was right. Every file whose newest filing was accepted on or after 5 October was off, including its filings from February. My guess is that files rebuilt since early October are written with the extra offset. I can't see rebuild times (the API sends no Last-Modified header), so that is a hypothesis, not a finding.

I wasn't the first to notice. An edgartools issue (dgunning/edgartools#1501) reported Apple four hours late on 8 October, and on 7 October some files that gave Eastern time labelled as UTC. I added the data above there.

What to do about it

Read the time from the index page or the SGML header when it matters. That costs one request per filing.

Because a file is uniform, one request per file is enough. Measure the file's error on one filing, then correct the rest:

from datetime import datetime, timedelta
from zoneinfo import ZoneInfo

ET = ZoneInfo("America/New_York")

def file_shift(api_iso, accepted_et):
    """A submissions file's error in Eastern offsets (-1, 0 or 1), from one filing's index-page time."""
    api = datetime.fromisoformat(api_iso.replace("Z", "+00:00"))
    true = datetime.strptime(accepted_et, "%Y-%m-%d %H:%M:%S").replace(tzinfo=ET)
    k = (api - true) / -true.utcoffset()  # the offset is 4 h (EDT) or 5 h (EST)
    if k not in (-1, 0, 1):
        raise ValueError(f"unexpected shift {k}")
    return int(k)

def corrected(api_iso, k):
    """The true acceptance time of any filing in a file whose shift is k."""
    api = datetime.fromisoformat(api_iso.replace("Z", "+00:00"))
    if k == 0:
        return api
    for h in (4, 5):
        t = api - k * timedelta(hours=h)
        if -t.astimezone(ET).utcoffset() == timedelta(hours=h):
            return t

k = file_shift("2026-02-27T04:34:19.000Z", "2026-02-26 18:34:19")  # Apple's file: 1
corrected("2026-07-14T14:30:38.000Z", k)  # a 06:30 ET filing: 10:30:38 UTC

Calibrate on two filings from different seasons, and read every filing from its own index page if they disagree. Recalibrate whenever you re-download the file, because a rebuild can change it.

Where it bit me

canli-mcp's earnings_calendar already read times from the index pages. Its event_study did not: it took acceptanceDateTime to decide whether a filing came before or after the 16:00 close.

With today's files the damage is small. Only afternoon filings move to the next day: 1 of 31 JPMorgan 8-Ks since 2025, and none of 55 NVIDIA insider sales. A file that gives Eastern time labelled UTC would be worse: every results release after the close would land on its own day. event_study now calibrates each file this way, with two extra requests, and says in its result which it did.

Try it

canli-mcp is a free, MIT-licensed MCP server for finance: 306 tools behind three, reading SEC filings, insider trades, 13F and 13D/G holdings, options, FOMC and macro data straight from the sources, with no API key for almost everything.

npx -y canli-mcp

# Claude Code
claude mcp add canli -- npx -y canli-mcp

The code is on GitHub:

arhancanli/canlicapital: every MCP server, including the fix (acceptanceTimes in mcp-markets/src/sources.mjs), the benchmarks and the site.
arhancanli/alphac: the strategy research engine.

If you have seen other EDGAR fields that don't mean what they say, I'd like to hear about them.

"silver price" returned US CPI: plain-word lookups that answer the wrong question

Arhan Canli — Sun, 11 Oct 2026 15:00:22 +0000

Agents rarely pass the exact ID a data source wants. They pass words: "10 year treasury yield", "core inflation", "silver price". So most tools that wrap a data source have a small resolver that turns words into an ID. Mine had a bug that never raised an error.

The bug

In canli-markets-mcp 0.1.0 (now one of the packs in canli-mcp), economic_series took a FRED series ID or plain words. The plain-word path scored each of 47 common series by the share of the request's words found in its description, and took the best one if at least half matched:

const words = s.toLowerCase().match(/[a-z0-9&]+/g) ?? [];
const scored = COMMON_SERIES
  .map(([id, text]) => [id, words.filter((w) => text.split(" ").includes(w)).length / words.length])
  .sort((a, b) => b[1] - a[1]);
if (!scored.length || scored[0][1] < 0.5) throw new NotFound(/* ... */);
return { id: scored[0][0] };

A two-word request needs only one shared word to reach half. CPI's description is "cpi consumer price index inflation all items", so "price" alone was enough. Here is the 0.1.0 resolver next to the current one, on the same requests:

Request	0.1.0 returned	Now
silver price	CPIAUCSL (US CPI)	refused, pointing to `price_history`
copper price	CPIAUCSL	refused
bitcoin price	CPIAUCSL	refused
japan inflation	CPIAUCSL	refused, pointing to `world_economy`
uk unemployment rate	UNRATE (US unemployment)	refused
wage growth	A191RL1Q225SBEA (real GDP growth)	CES0500000003 (average hourly earnings)
house prices	refused	CSUSHPINSA (Case-Shiller)
inflation	CPIAUCSL	CPIAUCSL
10 year treasury yield	DGS10	DGS10

Every wrong answer came back as a real series with real numbers. The result did carry the series title, so the mistake was there for anyone who read it. Nothing made an agent read it.

The pattern is the same in every row. The words that decide the question ("silver", "japan", "uk") are the ones that matched nothing. The words that did match ("price", "inflation", "rate") say what kind of number you want, not which one.

The rule that replaced it

One function now serves three resolvers: FRED series, World Bank indicators and OECD outlook measures. The two newer ones had the same flaw before they were released: "wage growth" gave GDP growth, "house prices" gave CPI, and the OECD "exchange rate" gave the unemployment rate.

Each word of a request falls into one of three groups:

Filler is ignored: "what is", "show me", "since", "this year", and years such as 2020.
Kind words say what sort of number: rate, growth, index, level, daily, monthly. They count toward the best match but are never required.
Specific words are everything else, and every one of them must appear in the entry.

export function matchWords(entries, textOf, request, vocab) {
  const asked = split(request).filter((w) => !vocab.filler.has(w) && !/^(1[89]|20)\d\d$/.test(w) && !/^[a-z]$/.test(w));
  const specific = asked.filter((w) => !vocab.kind.has(w));
  if (!specific.length) return null;
  let best = null, most = 0;
  for (const entry of entries) {
    const has = new Set(split(textOf(entry)));
    if (!specific.every((w) => has.has(w))) continue;
    const shared = asked.filter((w) => has.has(w)).length;
    if (shared > most) { best = entry; most = shared; }
  }
  return best;
}

split lowercases, keeps letters, digits and &, and folds plurals ("wages" becomes "wage"). Ties go to list order, so the more common series sits first. Each resolver adds its own words: the FRED series are all US series, so "us" and "fred" are filler there, and "interest" is a kind word.

When nothing qualifies, the tool says so and says where to look:

No common series matches "silver price". These are US series: for another country's economy use world_economy or economic_outlook, and for the price of a commodity, currency, crypto or stock use price_history ("gold" is COMEX gold futures). Or pass a FRED series id (find it at fred.stlouisfed.org).

An agent that gets this refusal can call price_history next. An agent that gets CPI has nothing telling it to.

Test the refusals first

The old tests checked that good requests found their series, and they all passed. None of them asked whether a request for something we don't have gets refused. The test file now starts with exactly that:

test("economic_series: a request naming something no series is refuses, with where to look instead", () => {
  for (const q of ["silver price", "copper price", "bitcoin price", "gold price", "japan inflation",
                   "uk unemployment rate", "euro area gdp", "stock prices", "interest rates"]) {
    assert.throws(() => resolveSeries(q),
      (e) => e instanceof NotFound && /price_history/.test(e.message) && /world_economy/.test(e.message), q);
  }
});

After it come 42 plain requests that must each resolve to one exact series (with filler, plurals and IDs inside the words), and the same two kinds of test for the World Bank and OECD resolvers.

"interest rates" is refused on purpose. There are dozens of interest rates, and picking one would be the same bug in a nicer coat.

What I'd take from it

A resolver from words to IDs is a search engine that returns one result. It needs a way to return none.
Score on the words that tell entries apart, not on the share of words that match. Generic words are the most likely to match and the least likely to matter.
Write the refusal tests before the positive ones. The positive ones pass on day one.

Try it

canli-mcp is free and MIT-licensed, runs on your machine, and needs no API key for this (FRED, World Bank and OECD data are public):

npx -y canli-mcp

# Claude Code
claude mcp add canli -- npx -y canli-mcp

The code is on GitHub:

arhancanli/canlicapital: every MCP server, including mcp-markets/src/words.mjs and test/words.test.mjs, the benchmarks and the site.
arhancanli/alphac: the strategy research engine.

If you find a request it resolves wrong, open an issue. That is exactly the bug I want to hear about.

[Boost]

Arhan Canli — Sun, 11 Oct 2026 11:08:35 +0000

Arhan Canli

Oct 11

canli-mcp: 306 free finance tools for Claude and any MCP client, measured against OpenBB, EdgarTools and Yahoo

#mcp #ai #opensource #finance

4 min read

canli-mcp: 306 free finance tools for Claude and any MCP client, measured against OpenBB, EdgarTools and Yahoo

Arhan Canli — Sun, 11 Oct 2026 10:24:58 +0000

I've been building canli-mcp: one MCP server that puts 306 finance tools behind three. It is free, MIT-licensed, needs no API key for almost everything, and runs on your own machine.

npx -y canli-mcp

# Claude Code
claude mcp add canli -- npx -y canli-mcp

For Claude Desktop, Cursor or any other MCP client: { "mcpServers": { "canli": { "command": "npx", "args": ["-y", "canli-mcp"] } } }.

What it does

The model sees three tools: find_tool searches all 306 by what you ask for, describe_tool reads one tool's arguments, and run_tool runs any tool, or up to 25 in one round trip. Behind them are seven packs:

Markets (34 tools), read from the sources themselves:
- SEC filings and their sections, and full-text search across every filing;
- ownership: insider trades (Form 4), 13F holdings, 5% holders (13D/13G), fund and ETF portfolios (N-PORT);
- trading: short interest and off-exchange volume (FINRA), fails to deliver, futures positioning (CFTC);
- company detail: executive pay against performance, revenue by segment;
- options: chains with IV and greeks, volatility surfaces and the VIX futures curve (Cboe's delayed data);
- the Fed and macro: decisions, votes and dot plots, the US economic calendar, Treasury yields and auctions, the federal debt, FRED, World Bank and OECD data;
- prices for stocks, currencies, futures, indices and crypto.
Quant (235 tools): performance and risk, options and exotics, fixed income, portfolios, econometrics, indicators, and a library of 399 strategy sleeves. They are checked against QuantLib, statsmodels, arch, TA-Lib, scipy and pandas in 461 reference cases.
Backtest validation (17 tools): deflated Sharpe, the probability of backtest overfitting, data-snooping tests, leakage checks and placebo tests, all run locally.
Also: SEC fundamentals as first reported (point in time), factor backtests that refuse lookahead, Alpaca paper trading behind pre-trade checks, and an open research record.

Data results carry their source URLs, and market data carries hashes of the exact bytes received, so a figure can be checked later.

How it compares

	canli-mcp	OpenBB	EdgarTools	Yahoo Finance MCP
Finance question types with a keyless tool (of 53)	49	39	11	13
Tool definitions sent with every request	859 tokens	432,001 (2,171 in its discovery mode)	3,801	2,205

The coverage map checks each server's own tool list (bench/rivals/COVERAGE.md in the repo). Having a tool doesn't mean answering correctly, so there is also a head-to-head:

Setup: the same model (gpt-5.4-mini), the same prompt and the same limits for every arm; only the MCP server differs.
Result: on the questions every server finished, canli-mcp answered 22 of 28 runs correctly (79%). The best rival setup, EdgarTools plus Yahoo, answered 15 of 28 (54%).
Caveats: we wrote the 24 questions, in areas our servers were built for. It is one small model with two runs per question. A held-out set is still to run.

The full report, with every answer, is bench/rivals/REPORT.md.

Context is the other cost. Installed separately, the seven Canli servers send 34,508 tokens of tool definitions and instructions with every request. canli-mcp sends 1,109, measured with bench/context.py. The 859 in the table counts tools in the shape OpenAI-style clients send them, the same way for every server.

Finding the right tool

With 306 tools, search is the product. I wrote 48 everyday requests after the last change to the search and never tuned on them: "buy spy in my alpaca paper account", "cot report for euro futures", "executive salaries at microsoft". find_tool puts the right tool first for 46 of them. The previous release managed 25.

The biggest single fix was embarrassing: the stemmer turned "rates" into "rat", so "mortgage rates" never matched anything that said "rate". Prices, shares and trades broke the same way.

Wrong answers we caught before you did

The most useful work this week was hunting answers that were wrong without warning:

"silver price" returned US CPI. The plain-word lookup for economic series took any series sharing half the words, and "price" is in "consumer price index". "japan inflation" returned US inflation the same way. Now every specific word must match, and a request it can't answer is refused, with where to look instead.
"facebook" resolved to an unrelated "Denny Hill/Facebook LLC" from EDGAR's entity search, and "jp morgan" to "JP Morgan AG". Names now go to the listed company first, so Google is Alphabet and Facebook is Meta. Fund managers go to the filer of their 13Fs.
Hostile inputs. Every tool was called with hostile arguments: "constructor", empty and 5,000-character strings, edge numbers, 20,000-item arrays. Of the 2,980 calls that passed validation, a few showed bugs: find_tool crashed on the word "constructor", and some tools returned NaN where they should refuse. All are fixed, and the sweep (bench/robustness.mjs) runs before every release now.

Privacy

Everything runs on your machine:

Where it connects: only the public sources (SEC, Treasury, FRED, FINRA, CFTC, the Fed, BLS, BEA, Census, OECD, World Bank, Cboe, and Yahoo's public chart data for prices).
What it keeps: it sends nothing to us and logs nothing.
Offline: CANLI_OFFLINE=1 keeps only the packs that use no network.
Provenance: packages are published from GitHub Actions with npm provenance.

Not investment advice. Data comes as the publishers release it, Cboe's quotes are delayed, and Yahoo's chart data is unofficial.

Try it

npx -y canli-mcp

Then ask your assistant things like:

"who owns more than 5% of coca cola"
"did the fed raise rates and who dissented"
"short interest in GME"
"is my backtest overfit"

Everything is on GitHub:

arhancanli/canlicapital: every MCP server, the benchmarks and the site.
arhancanli/alphac: the strategy research engine.

If something is missing or wrong, open an issue. I would much rather hear about a wrong answer than ship it quietly.

Coming in the next release: earnings dates from companies' own 8-K filings, press-release headlines as news, and ready-made workflows as MCP prompts.

[Boost]

Arhan Canli — Sat, 10 Oct 2026 19:23:24 +0000

Arhan Canli

Oct 7

My agent kept dropping numbers when it copied data into a tool call. A file path fixed it.

#mcp #ai #agents #llm

3 min read

I ran 399 trading strategies on the same prices. Whether the winner was luck depended on the question.

Arhan Canli — Thu, 08 Oct 2026 14:14:58 +0000

I ran 399 trading strategies on the same price history and asked one question: is the winner skill or luck?

The answer depended almost entirely on which test I used. The tests did not disagree because some were wrong. They were answering different questions, and only one of them was the question I meant.

The setup

The 399 strategies are textbook ideas, each with its usual parameters on a plain grid:

moving-average crossovers;
time-series momentum with and without volatility targeting;
channel breakouts and MACD;
z-score and RSI reversion;
cross-sectional momentum and dual momentum;
risk parity, minimum variance and low volatility;
short-term reversal, trend-filtered allocation, 52-week-high momentum and pairs.

None was picked because it backtested well. Every one is a fixed rule.

I ran them on two synthetic datasets of five assets and 1,000 days. Synthetic data lets me know the truth:

Trend: asset 0 has planted trends. Its drift flips between +0.25% and -0.25% a day every 125 days, so trend-following has a real edge on it.
No edge: the same kind of market with no planted structure. Nothing should beat simply holding the assets.

Every strategy is scored on the same 495-day window, after the longest warm-up (504 days). Trades cost 5 basis points.

What each test said

	Trend data	No-edge data
Best strategy's Sharpe	4.07	1.95
Sharpe the best of 399 would show by luck alone	6.21	2.34
Deflated Sharpe probability, counting all 399 tries	0.001	0.29
Effective number of independent strategies	4.0	3.5
Deflated Sharpe probability, counting those	0.996	0.954
White's Reality Check p-value (beats buy-and-hold?)	0.011	0.43
Hansen SPA p-value, re-studentized	0.017	0.35
Strategies Romano-Wolf StepM says beat buy-and-hold	4	0
Probability of backtest overfitting (CSCV)	0.24	0.76

Three things surprised me.

1. Counting all 399 tries rejected the real edge. On the trend data, the best strategy's Sharpe of 4.07 is below the 6.21 that the best of 399 independent coin-flip strategies would reach. So the deflated Sharpe ratio says "luck" (0.001). But these 399 strategies are not independent. Most are near-copies of each other, and their returns behave like about four independent bets. Counted that way, the same result passes easily (0.996).

2. Counting four tries passed the no-edge winner. On the no-edge data, the effective count gives 0.954, just over the usual 0.95 bar. That is a pass, but there was no edge.

The reason took me a while. The deflated Sharpe ratio tests whether the Sharpe ratio is above zero. In a market that drifts upward, a long-only strategy's Sharpe really is above zero; it just holds the market. The question I cared about was whether it beats holding the market. The Reality Check, SPA and StepM test that, and they said no: p = 0.43 and 0.35, and zero survivors.

3. The overfitting probability moved the right way on both. CSCV splits the history into halves many ways, picks the in-sample winner, and checks where it ranks out of sample. On the trend data, the winner landed below the median out of sample 24% of the time. On the no-edge data it was 76%, which is worse than picking at random.

Walk-forward: what picking the winners was worth

I also tested the selection process itself. Every 63 days I ranked strategies by trailing one-year Sharpe, held the top five for the next 63 days, then repeated.

Trend data: the picks averaged a Sharpe of 4.69 in sample and 3.76 out of sample. They kept most of their edge.
No-edge data: 2.81 in sample, 1.29 out of sample. That is below simply holding all 399 strategies equally (1.90) and below buy-and-hold (1.90).

The gap between in-sample and out-of-sample Sharpe is roughly how much of the pick's Sharpe was luck.

What I do now

Report the deflated Sharpe under both counts. The raw count of strategies is the conservative bound, and the effective count is the optimistic one. If a result passes only the optimistic one, I treat it as not proven.
Ask the benchmark question separately. If a strategy is long-only in a rising market, "Sharpe above zero" is nearly free. The Reality Check, SPA and StepM against buy-and-hold answer "is this better than doing nothing clever".
Test the picking, not just the pick. A walk-forward over the selection rule shows how much edge survives once you can't see the future.

Reproduce it

All of this ran in about half a second per dataset with an MCP server I built, which runs locally on the data you send. The tournament, the walk-forward and the 399 strategy definitions are tools in it. The generator for both datasets:

import numpy as np

def market(seed, trend):
    rng = np.random.default_rng(seed)
    R = rng.normal(0, 0.006, (1000, 1)) + rng.normal(0.0002, 0.009, (1000, 5))
    if trend:
        R[:, 0] += np.repeat(rng.choice([-1, 1], 8) * 0.0025, 125)
    return (100 * np.exp(np.cumsum(R, axis=0))).round(4)

trend, no_edge = market(404, True), market(405, False)

Then call sleeve_tournament with prices set to either matrix and seed 7 (the bootstrap seed, so the SPA and StepM numbers repeat exactly), and sleeve_walk_forward with the defaults.

The package is canli-quant-mcp on npm: canli-quant-mcp.

Synthetic data is the only way to know the right answer in advance. On real prices you do not get to know it, which is why the tests matter.

Correction (8 October). The first version of this post reported an SPA p-value of 0.002 and 24 StepM survivors on the trend data (0.21 on the no-edge data). Those came from a studentized SPA that divides every bootstrap resample by one fixed variance estimate, with a long default block. My own benchmark, the Null Zoo, measured that exact setup rejecting 13.5% of skill-less searches at a nominal 5% when returns are autocorrelated. The tool now re-estimates the variance in every resample, as Romano and Wolf recommend, uses a shorter default block, and reports White's Reality Check alongside. The table above shows the corrected numbers: the planted edge is still found, by 4 strategies instead of 24.

My agent kept dropping numbers when it copied data into a tool call. A file path fixed it.

Arhan Canli — Wed, 07 Oct 2026 17:58:53 +0000

I maintain an MCP server that checks backtests: give it a strategy's daily returns and it tells you, among other things, how many years of track record you'd need before the Sharpe ratio means anything.

The obvious way to use it is to paste the returns into the chat and let the agent pass them to the tool. That turned out to be the worst way. Here is the measurement.

The setup

Three questions, each needing the whole audit chain. For example: "how many years of track record does this return series need before its Sharpe beats 1.0 at 95% confidence?" The series had 400, 504 and 756 daily returns. Each question was asked 3 times of the same model (gpt-5.4-mini), so 9 runs per arm. The ground truth is the same local computation the tool runs, so an answer is either right (within 2%) or it isn't.

Three arms:

Old tools, returns pasted. The server as it was before the one-call audit tool existed, so the agent had to chain several validators itself.
One-call audit tool, returns pasted. The series sits in the prompt as a JSON array; the agent copies it into the tool call.
One-call audit tool, file path. The series is in a CSV; the prompt names the file and the tool reads it.

The result

arm	correct	median tokens per task	median time
old tools, pasted	0 of 9	11,180	2.4 s
audit tool, pasted	4 of 9	27,036	10.0 s
audit tool, file path	8 of 9	6,524	2.4 s

Same model, same tool, same numbers. Moving the data out of the prompt doubled the accuracy and cut the tokens by about three quarters.

What went wrong when it pasted

The interesting part is how the pasted runs failed. On the 756-return question, all three pasted runs gave the same wrong answer: 0.1718 years instead of 0.1452. Not three different mistakes, one identical mistake, three times.

That's what you get when values go missing on the way into the call. The model is re-typing 756 numbers as output tokens. Somewhere in there it skipped some, the tool dutifully computed the right answer for the wrong series, and the agent reported it with full confidence. Nothing errored. If I hadn't had the true value, I'd have believed it.

Pasting also costs. Every number is paid for twice: once as input in the prompt, once as output when the model writes the tool call. One pasted run used 76,930 tokens for a single question.

The one miss in the file arm was different: the agent answered 388, which is the right answer in observations (about 1.54 years × 252 trading days) reported where years were asked. A unit slip, not lost data.

What I changed

The audit tool takes returns_file (a path to a CSV) on the local server. It reads numbers only, caps the file size, and reports errors by row position, never by echoing file content back into the context.
Tool descriptions say plainly that a long series should go in as a file.
The hosted version can't read your disk, so it refuses file input instead of pretending.

Limits of this test

It's one small model, 9 runs per arm, on synthetic series. I didn't run Claude models for this one. So read it as "this failure is real and easy to hit", not "pasting loses exactly 55% accuracy". The run records and the task code are in the repo, if you'd like to rerun it with a different model.

The general lesson I took: if a tool needs a lot of data, don't make the model carry it. Pass a reference (a path, an ID, a URL) and let the tool fetch it. The model is good at deciding what to compute and bad at being a copy machine.

Have you seen the same thing with other kinds of data, like long JSON, CSV rows or logs? I'm curious where the length threshold sits for bigger models.

Your backtest beat a t-test. Would it beat a placebo?

Arhan Canli — Wed, 07 Oct 2026 12:31:16 +0000

You test 11 moving-average crossovers on five years of daily prices. The best one has a Sharpe of 1.2, and a t-test on its returns says p = 0.01. Is it real?

We simulated that situation 300,000 times, in markets where by construction nothing can be predicted, and counted how often the usual tests said "edge". A t-test on the best rule said yes between 10.9% and 78.9% of the time, depending on the market. The usual fix for testing many rules, Bonferroni, held up in flat markets but said yes 8.0% to 10.3% of the time when the market simply drifted upward, and 58.5% to 59.7% of the time when stocks just had different average returns. A placebo test stayed between 4.6% and 5.5% everywhere, against a promised 5%.

This post is about why, and how to run the placebo on your own pipeline.

Two things that look like skill

The search. The best of 11 rules is the best of 11 draws. Even with no edge, the maximum is high. On flat simulated markets, an 11-rule SMA grid's best Sharpe averaged 0.30 to 0.32 with nothing to find. That is what Bonferroni and the deflated Sharpe ratio correct for, if you know how many rules you really tried.

What the market does on its own. A long-only rule earns the drift of a rising market without predicting anything. A cross-sectional ranking that buys past winners earns the gap between assets with different long-run average returns, again without predicting anything: in our simulated markets where assets only differed in their constant means, a 20-stock momentum grid's best Sharpe averaged 1.27 to 1.29. A t-test on the strategy's returns asks "did it make money?", not "did it predict?", so drift and dispersion pass for skill, and dividing alpha by the number of rules does nothing about that.

The placebo

Keep your data's returns, but put the days in a random order, the same order for every asset. Each asset keeps its own returns, fat tails and average; each day keeps its cross-section; but nothing about a day tells you anything about the next one. That is a placebo: a market with the same raw material and nothing to predict.

Now run your whole pipeline on the real data and on 19 placebos: the same search, the same filters, the same parameter choices. If the real result beats all 19, the chance of that happening by luck is 1 in 20 (p = 0.05). If it beats 15 of them, p = 0.25. Every choice the pipeline makes is counted, because it makes it again on every placebo, and drift and dispersion are in the placebos too, so they stop looking like skill.

When the days are interchangeable, this p-value is exact: the real ordering is just one of the orderings. Volatility clustering breaks that, so we measured it.

The study

We wrote the rules down before running anything: three ways of reordering (a full permutation, a permutation of blocks of 11 days, and a stationary bootstrap), a bar of at most 6% false positives at a nominal 5% in every simulated market, and the rule that picks the winner. The pre-registration was committed before the run, and a test in the repository checks the run used it.

Markets with nothing to predict: five return shapes (normal, fat-tailed, negatively skewed, GARCH volatility clustering, volatility regimes), each flat or drifting, or for the cross-section, with equal or dispersed average returns. 1,260 days each.
Pipelines: an 11-rule SMA crossover grid, a 6-lookback time-series momentum grid, and a 4-lookback cross-sectional momentum grid over 20 assets, each reporting its best Sharpe.
30 combinations, 10,000 tests each, with 19 placebos per test, plus planted trends to measure power.

The full permutation met the bar in all 30: 4.6% to 5.5%, including GARCH and regime markets. The block permutation also met it (5.8% at worst) with less power. The stationary bootstrap was far too cautious: never above 1.5%, so it would miss real edges.

How often does the placebo catch a real edge? With a planted trend that a perfect forecaster would trade at a Sharpe of about 2, the SMA grid beat all 19 placebos 45.1% of the time and the time-series grid 47.3%; at a Sharpe of about 1, both were near 14.8%. The cross-sectional grid caught its strongest planted trend 89.0% of the time. An honest caveat: with only 19 placebos, Bonferroni catches some trends more often in flat markets, where it is valid. 99 placebos give a finer p-value.

What it does not tell you

Beating the placebos shows that the real order of your returns holds more than random orders of the same returns. It says nothing about costs, capacity or whether the edge lasts. And it counts only the search this pipeline runs: if you tried and dropped ten other pipelines before this one, those trials are not in the number.

Try it

The placebo is the placebo_test tool in canli-validation-mcp, an open-source MCP server. plan writes your price file and 19 placebo files to a temporary folder; run your pipeline on each, then compare returns the p-value. It runs on your machine; your code never leaves it. In Claude Code:

claude mcp add canli-validation -- npx -y canli-validation-mcp

The study's code, pre-registration and results are in the canlicapital repository. If you run the placebo on a real pipeline, I would like to hear what it finds.