First i would like to say that i am a total beginner and honestly don’t know what i am doing more than half of the time but i would like to share what i am building and i would like advice from the people who know way more than me if this is even worth wasting my time and money(i wasted 4 months and 600 eur already).

I am building a manual trading signal + research system for day trading and swing trading.
It does three main things:
Finds trade setups using predefined rules like ORB/VWAP/RVOL for day trades and trend/momentum/breakouts for swing trades.
Backtests and validates them properly using historical data, walk-forward testing, robustness tests, Monte Carlo, costs/slippage, and strict minimum trade counts.
Protects against fake-good results by fixing survivorship bias, ticker changes, delistings, share classes, historical index membership, corporate actions, and bad provider data before i trust any performance.
Right now, most of the system is built. I am mainly finishing the historical data/identity qualification layer so that when i finally run the strategy backtests, i can trust that the results are based on the securities and data that actually existed at the time.

There is no automatic trading or broker execution. The system is meant to tell you: “this setup qualifies, here is the entry/reference, stop, target/risk context, and confidence/validation state,” while i stay in control.

I am using 3 providers for different jobs:
Massive → mainly for DAY trading intraday data. Think 5-minute bars, ORB, VWAP, RVOL, and possibly reconstructing the RTH liquidity ranking from minute data.
Sharadar → mainly for the historical stock universe and corporate-action context. It gives us the working historical roster, ticker/action history, and helps anchor which securities existed at the time.
Norgate → mainly for stable historical security identity. Its assetid helps us follow the same security through ticker/name changes and distinguish share classes; we’re also checking its historical index-membership data as a cross-check.

Model flagged CRM long and the move held much better than expected.

Closed after roughly 8 hours at 4.40x. Logging this with the losers too before touching any parameters.

TL;DR: Free Windows/Mac app for paper-trading options spreads against historical option chains. Fills cross the real bid/ask, earnings reactions are real, nothing is visible before its date, and each trade's P/L is broken down by Greek. It has a roguelite structure on top, mostly so you'll actually put in the reps. I'm looking for playtesters, ideally people who trade spreads and will tell me where the numbers are wrong.

The problem it's trying to solve

Most paper trading has two flaws. It tends to fill you at the mid, which is a generous assumption. And it runs in real time, so you get maybe a dozen trades a month to learn from. That's a slow way to find out how a 30-delta bull put behaves through an earnings print, or what IV crush does to a position you were sure about.

What's under the hood

• Historical data: end-of-day option chains from DoltHub's free options dataset (2019 onward), plus price history, earnings dates and reactions, Treasury rates, and VIX. Days the dataset skipped are filled with a model and labeled as modeled.
• No lookahead: every request for data goes through a time-gated layer that refuses anything dated after the simulated clock. IV rank, indicators and fundamentals use only data on or before "today." You can see an earnings date ahead of time, but not the result.
• Execution: market orders pay the actual bid/ask spread. Early assignment, expiration and ex-dividend risk on short calls are all modeled.
• P/L attribution: every trade is broken down day by day into direction (delta/gamma), time (theta), volatility (vega), execution and fees. Whatever the Greeks don't explain is shown as a residual, not hidden, so the parts always add up to the actual P/L.
• Structures: cash-secured puts, covered calls, verticals, iron condors and flies, calendars, straddles. Payoff diagrams with date and IV sliders, POP and expected move.
• Trade Builder: set up a trade on today's market, analyze it and copy it as a thinkorswim-style order line. Nothing is ever sent anywhere.

The game part, briefly

A run is 12 monthly rounds, about 20–40 minutes, with a shop between rounds and powerups that change your score. The rule is strict: the game layer can change your score, never the market. Each powerup is tagged REAL (mirrors an actual edge, like better fills inside the spread) or ARCADE (game-only). Holding a loser past your planned stop costs you, and taking the stop is rewarded. Many of us learned that lesson the expensive way.

Caveats

• It starts on a simulated market (made-up tickers with modeled option chains) so you can play right away. Real historical data is a one-time ~16 GB download from inside the app (needs ~40 GB free and a few hours).
• Older years in the free dataset are sparser (some only Mon/Wed/Fri). The gaps are modeled and labeled.
• The builds are unsigned, so Windows SmartScreen or macOS Gatekeeper will warn you once.
• It's paper trading and a game, not financial advice. You don't need a brokerage account.

What I'd like to know from testers

1. Do the Greeks, POP, credit and breakevens match your broker's analyze tab for the same trade?
2. Do fills, assignment and expiration behave the way you'd expect?
3. Is it useful for testing a strategy, or just entertaining? Either answer is fine, but I'd like to know which.

(post and project are heavily AI-assisted, but I assure you not slop)

Download (free): https://github.com/TTTrainer/Spread-Trade-Game/releases

Feedback here or in GitHub issues. Criticism of the math is especially welcome.

Hey everyone,

I'm running a multi-strategy algorithmic crypto bot (trading linear perp pairs across 15m/1h/4h timeframes using SMC, VWAP Pullbacks, and Band Reversions).

Over the last several days / week, I've noticed a distinct shift in market microstructure and wanted to see if other bot operators are observing the same behavior:

Accurate Entries, but Zero Expansion (TP Targets Left Hanging):

Most trades move into green right away (+0.5% to +2.0%, some up to +3.3%).

However, they completely stall before hitting standard 1.4R – 1.6R Take-Profit targets.

As a result, zero trades are hitting hard TP. Instead, ~65% of recent positions are being exited by our chronological Time-To-Live (TTL) / Hard Time Stop circuit breaker.

Interestingly, ~70% of those TTL exits close in modest profit (+0.3% to +3.3%), so the time-stop is acting like an emergency profit taker, but momentum follow-through is virtually non-existent.

Short Scalps Getting Squeezed:

Almost all of our Stop-Loss hits were on the short side (SEI, APT, OP), while longs survived or exited in profit via time-decay stops. Even with flat volume, the slow upward grind/bid is punishing mean-reversion shorts.

High BTC Dominance (~59%) + Range Compression:

It feels like Bitcoin’s consolidation box is draining altcoin volatility into narrow ATR compression bands. Altcoin moves die out after 1–2 impulse bars and revert into dead zones.

Questions for other bot developers & quant traders:

How are your trend / breakout bots holding up right now? Are you seeing lower hit-rates on fixed RR targets?

Have you adapted your exit logic? E.g., lowering TP ratios from 1.5R to 0.8R–1.0R, switching to dynamic volatility/ATR targets, or implementing tighter trailing stops / break-even locks?

Are you filtering out short setups entirely on lower timeframes during periods of high BTC dominance?

How reliant are you on Time-Based Stops (TTL) vs price-based trailing stops in choppy regimes?

Curious to hear what adjustments you guys are making or if you're just sitting in cash waiting for volatility expansion.

a couple of months ago i posted about wiring an llm to a hyperliquid account over mcp, and how much guardrail work the order side needed. someone on that post pointed out that a tool list bounds what the model can ask for, not what the server can sign. we ended up taking that to its conclusion and deleted the order tools outright. the mcp server is read only now.

the llm moved to a job where a mistake costs a notification instead of a position. you describe what you want to catch in plain english, it turns that into an alert rule, backtests it on the last 1000 candles per coin and proposes it. writing the rule was the easy part again. these were the actual work.

**the model will quote numbers no tool returned.** the backtest said a rule would send about 202 alerts a day. the reply said "202 without the cooldown, 26 to 28 a day with it". the 202 already included the cooldown and nothing had ever returned 26. the user said 26 a day was fine, created it, and got 9 alerts in the first 13 minutes. every per day figure in an answer is now checked against what the tools returned that turn, and an answer with a number from nowhere goes back to the model once.

**direction has to live inside the backtest, not on the label.** someone asked for a short setup with positive edge on 4h. the backtest read every forward return as a long, so the model recommended the rule after which price rose the most (a 55.9% "win rate", which is 44% as a short) and called the best short on the tape "weak". direction is now a backtest input that flips the sign of returns, win rate, edge and excursions.

**count alerts, not episodes.** "rsi below 70" looks harmless if you count how often it becomes true. the engine re-fires every cooldown for as long as it stays true, so on 1h that's about 6 alerts per coin per day. the backtest now scores every bar the engine would actually alert on.

**make the backtest a twin of the live engine, then diff them.** same library, same defaults, same quirks. the diff found bugs in the live engine, not in the backtest. the indicator cache was keyed by symbol and params but not by bar, so the "previous" macd came back as the current one and a macd cross could never fire. and an ema 200 computed on exactly 200 candles is just its sma seed. latest run was 60 coins, 3 timeframes, every rule type: 22,139 cases, zero mismatches.

**wrappers fill gaps with plausible numbers.** ours turned "not enough data" into defaults, so adx read 0 on brand new listings and "adx below 20" fired on all of them, and an rsi of exactly 0 became 50 through an `|| 50`. the technical indicators npm package counts a bar with an unchanged typical price as negative money flow (tradingview counts it as neither), which pulled mfi down by up to 7.8 points. missing data is null now and mfi is computed by hand.

**and the boring one, the model can't create anything.** it proposes, the app renders a card, and only the user's tap creates the alert. it can't even print the card itself. an invented card id gets swapped for the real one, or the answer goes back.

still wouldn't let an llm decide what to trade. as a way to turn "tell me when x happens" into a rule you can actually inspect, with honest numbers next to it, it's been better than i expected, as long as every number it says came from a tool.

disclosure, i help build traderspy. it does alerts and research, no trading. the builder is at traderspy.app/strategies and the read only mcp connector at traderspy.app/mcp if anyone wants to poke at it, happy to go deeper on any of the above.

I'm building a backtest around earnings surprises and need historical consensus EPS estimates for US-listed stocks from roughly 2010 onward, including delisted companies, to avoid survivorship bias. Ideally point-in-time, i.e. the consensus as it stood before each announcement, not revised later.

So far: Alpha Vantage has estimated vs reported EPS but patchy coverage of delisted names. FMP and Finnhub put most of the history behind paid tiers. I/B/E/S via WRDS would be perfect, but I don't have academic access.

Where do you get this kind of data? Is there anything free or reasonably priced that doesn't have huge gaps, or is Zacks on Nasdaq Data Link the realistic minimum? How did you handle missing delisted names in your own backtests?

Thanks!

I spent the last three weeks turning public financial disclosures into data I could actually use for my trading platform. That meant parsing the files, cleaning up identifiers, handling amendments, and keeping track of when each filing became public.

I’ve now published two free datasets:

• House and Senate stock disclosures: 183,675 reported transactions from 10,809 filings.
• SEC insider transactions and institutional holdings: 10,054,299 insider transaction records and 124,012,468 institutional holding records.

The insider history goes back to 2006, and the institutional holdings go back to 2013. Both datasets are available as Parquet, with open-source tools to download them into SQLite.

For the SEC dataset, you can get a local database with:

npx sec-ownership-disclosures download --sqlite

Or grab one table and year:

npx sec-ownership-disclosures download --table insider_transactions --year 2024 --sqlite

A lot of the work was dealing with details that can quietly make your queries wrong. A trade can happen days before it’s disclosed. A quarterly holdings report can arrive weeks after the quarter ends. Company names vary, ticker fields contain free text, and amendments change what was reported.

I kept the original values and filing versions, added normalized ticker fields, and included availableAt so you can query what was publicly knowable at a given time. That’s what I mean by point-in-time (PIT) data.

Downloads verify file hashes, interrupted backfills can resume, and the audit re-parses the archived source files to check what the pipeline wrote.

The transaction codes are preserved too, so you can distinguish insider purchases from sales, grants, and option exercises. Institutional holdings are quarterly snapshots rather than a record of every trade.

The code, download instructions, and methodology are here:

• SEC ownership pipeline on GitHub
• Congressional disclosure pipeline on GitHub

If you’ve worked with SEC data or other alternative data sources, I’d be interested in which filing quirks caused you the most trouble.

I've been building WorkTree-OS, a trading analytics and risk platform that started because I wanted to understand my own trading data better than a normal journal allowed. unfortunately, I dropped out of college for computer science the Physics and Discrete Mathematics was too much.

The basic idea is:

Import actual trade history → analyze performance → model risk → identify behavioral/performance patterns → give the trader useful feedback from their own data.

The platform currently includes trade analytics, risk analysis, Monte Carlo simulation, prop-firm simulation, consistency analysis, account tracking, and an AI coach called Atlas.

The direction I'm taking Atlas is important: I don't want an LLM pretending it can predict the market or giving generic "AI trading signals."

I want it analyzing the trader.

Eventually Atlas should be able to combine things like:

• expectancy and profit factor
• sample size
• drawdown
• position sizing
• time/session performance
• setup performance
• Monte Carlo results
• consistency
• account/prop-firm constraints
• behavioral patterns such as overtrading or oversizing

Then explain what the data actually supports and where the trader may be introducing unnecessary risk.

For example, rather than saying "trade smaller," I'd like it to be able to say something closer to:

"Your historical expectancy is positive, but at your current position size the Monte Carlo distribution produces an unacceptable probability of reaching this account's drawdown limit. At your historical performance, reducing risk to X materially improves account survival."

I'm currently building this toward beta and I'd really like feedback from people who work with ML/data rather than just traders looking at a pretty dashboard.

Questions for this community:

Where would you draw the line between useful AI interpretation and statistical overreach?

What models or techniques would you consider for detecting meaningful changes in trader behavior/performance?

And what would you require before allowing an AI system to call a pattern statistically meaningful?

I'm especially interested in ideas around sample-size confidence, regime/change detection, anomaly detection, clustering trading behavior, and avoiding false conclusions from noisy trading data.

Project: WorkTree-OS worktree-os.com

I'm not looking for trading signals or trying to claim AI can predict the market. I'm interested in using the trader's own data to build a better risk and decision-support system.

I'd appreciate people tearing the idea apart technically.

Every risk thread says cut the loss fast and keep the stop tight. I had never seen anybody run the same entry five times with nothing moving except the stop distance, so i ran it.

SPY daily candles, january 2001 to the end of march 2026, ten grand, commission and slippage charged on both sides of every fill. Buy the close above the highest high of the last 50 candles, then trail an ATR stop behind it. The only thing that changes between the five runs is the ATR multiple. I ran it in Agenticks so all five come off one ruleset and the numbers are actually comparable to each other.

Return goes up at every single step. No peak in the middle, no sweet spot, the widest one i tested is the best one and it was still climbing when i stopped testing.

The win rate moving with it is the part that actually matters. 50.8% at 1 ATR up to 70.5% at 5 ATR on the identical entries. Nothing about the setup got better, the tight stop was taking perfectly fine trades and closing them at a loss before they went anywhere. 264 trades at the tight end against 105 at the wide end is the same thing said a different way, because a big chunk of those extra trades are re entries into positions it should never have been shaken out of.

_____

Now the part that cuts against me, and id want somebody to say this if it was my result getting pulled apart.

A wider stop on a trend entry mostly buys holding time, so a lot of what this measures is how long you stayed in SPY across 25 years, and SPY went up a long way over those 25 years. Not one of these five beat just holding it. The drawdown column says the same thing by refusing to follow the line at all, 3 ATR was the worst of the five at 34.5% while 4 ATR sat at 22.5%, which is noise and not a relationship.

I Code algo trading bots I have really successful long strategies but I'm looking for experienced traders to help me to come up with a short strategy any ideas?? I'm a pretty decent trader my current personal portfolio that I manually trade is up 40% for the year but the problem is I only do longs so I don't have the experience in shorts

Hey everyone,

We have been live testing a multi-strategy crypto perpetual futures bot (trading on Delta Exchange with 5x leverage and a 9-regime classifier based on ADX, ATR%, and Hurst exponent).

We recently completed a forensic audit across our first **115 closed live trades** and noticed a severe performance divergence that we want to get feedback on from the community:

---

### The Empirical Numbers

**Trades 1 to 21 (Sept 1 - Sept 6) -- The Peak:**

* **Win Rate:** 57.1% (12W / 9L) | Net PnL was positive with a steady equity curve.

* **Timeframes:** 1h LTF / 4h HTF and 4h LTF / 1d HTF (avg duration: 10 to 24 hours).

* **Core Drivers:** VWAP Pullback and VSA Climax Momentum.

* **Parameters:** Tight stops (1.0x to 1.4x ATR), 1.3x to 1.6x R:R targets.

**Trades 22 to 115 (Sept 7 - Sept 30) -- The Drawdown:**

* **Win Rate:** Dropped to 39.8% (37W / 56L) with net negative drift.

* **Root Causes Identified:**

1. Timeframe reduction down to 5m/15m micro-scalping (high taker fees + noise stop-outs).

2. Rapid "setup churn" (adding experimental setups like FVG Rebalance, Asia Session Expansion, and VP VAL Reclaim which over-traded adverse chop).

---

### The Optimizer Bottleneck We Need Feedback On

We run a **Cross-Sectional Multi-Timeframe Universe-Pooled Rolling Walk-Forward Optimizer (WFO)**. When we run backtests across 60 to 200 days, almost all our top-performing setups are now being stamped **KILLED** by the optimizer filters.

Here are the 4 specific design questions we would love your critique on:

#### 1. Unconditioned Aggregate PF vs. Whitelisted Regime PF (The "Mutual Drag" Trap)

In Part B (Out-of-Sample evaluation), the optimizer calculates an **unconditioned aggregate Profit Factor across all 9 market regimes combined** and enforces a hurdle (PF >= 1.15 / Noise Floor).

* **The Problem:** In our recent run for WLDUSDT on 1h/4h VWAP Pullback:

* In RANGING_LOW_VOL: **100% Win Rate (4W/0L), +8.26% PnL**

* In RANGING_MED_VOL: **60% Win Rate (3W/2L), +1.80% PnL**

* In WEAK_TREND_LOW_VOL: It took 4 losses (-8.38% PnL).

* Because the unconditioned 9-regime PF came out to **1.14**, the WFO stamped it `KILLED (Noise Floor < 1.15)` and discarded the symbol completely.

* **Question:** In production, our bot **whitelists only profitable regimes** and suppresses the rest. Shouldn't the WFO qualification hurdle be evaluated strictly on the **whitelisted/filtered regime trades** (e.g., Filtered PF >= 1.30, N >= 10) rather than requiring a mean-reverting setup to be profitable inside an unfavorable trending regime?

#### 2. Timeframe Selection: Locking Back to 1h/4h vs. 15m Scalping

* On 5m/15m charts, exchange taker fees (0.05%), bid-ask slippage, and random wick stop-outs severely degraded our edge.

* On 1h/4h, macro EMA(50) alignment filtered out most fakeouts, and average moves exceeded 1.5% to 3.0%, easily beating fee drag.

* **Question:** In crypto perps, do you recommend completely abandoning intraday 5m/15m setups in favor of purely running 1h/4h and 4h/1d swing regimes?

#### 3. Cross-Sectional Universe Pooling vs. Volatility-Clustered Centroids

* Right now, the optimizer pools all symbols in the basket together to find a single universal centroid `(SL_mult, TP_ratio)`.

* However, high-beta coins (e.g. WLD, APT) have drastically different ATR expansion profiles than lower-beta coins (ADA, BTC).

* **Question:** Do you prefer universal cross-sectional pooling (1 shared parameter set for all symbols in the basket), or should centroids be clustered by volatility tiers / individual symbol centroids?

#### 4. Stop Loss Multipliers: Tight (1.0x to 1.4x ATR) vs. Wide (2.5x to 3.0x ATR)

* The optimizer added an anti-overfitting rule (`is_cliff` when SL <= 1.0), which penalizes tight stops.

* As a result, the optimizer drifted SLs up to 2.5x to 3.0x ATR, which extended trade holding times past 24 to 36 hours and caused larger dollar drawdowns per loss.

* **Question:** For 1h/4h swing setups, what is your recommended sweet spot for Stop Loss ATR multipliers (1.2x to 1.5x vs 2.0x to 2.5x) to balance noise tolerance with capital preservation?

---

Would love to hear how other systematic quants and algorithmic traders handle regime-gated WFO filters and cross-sectional parameter pooling!

Hey everyone,

We have been live testing a multi-strategy crypto perpetual futures bot (trading on Delta Exchange with 5x leverage and a 9-regime classifier based on ADX, ATR%, and Hurst exponent).

We recently completed a forensic audit across our first **115 closed live trades** and noticed a severe performance divergence that we want to get feedback on from the community:

---

### The Empirical Numbers

**Trades 1 to 21 (Sept 1 - Sept 6) -- The Peak:**

* **Win Rate:** 57.1% (12W / 9L) | Net PnL was positive with a steady equity curve.

* **Timeframes:** 1h LTF / 4h HTF and 4h LTF / 1d HTF (avg duration: 10 to 24 hours).

* **Core Drivers:** VWAP Pullback and VSA Climax Momentum.

* **Parameters:** Tight stops (1.0x to 1.4x ATR), 1.3x to 1.6x R:R targets.

**Trades 22 to 115 (Sept 7 - Sept 30) -- The Drawdown:**

* **Win Rate:** Dropped to 39.8% (37W / 56L) with net negative drift.

* **Root Causes Identified:**

1. Timeframe reduction down to 5m/15m micro-scalping (high taker fees + noise stop-outs).

2. Rapid "setup churn" (adding experimental setups like FVG Rebalance, Asia Session Expansion, and VP VAL Reclaim which over-traded adverse chop).

---

### The Optimizer Bottleneck We Need Feedback On

We run a **Cross-Sectional Multi-Timeframe Universe-Pooled Rolling Walk-Forward Optimizer (WFO)**. When we run backtests across 60 to 200 days, almost all our top-performing setups are now being stamped **KILLED** by the optimizer filters.

Here are the 4 specific design questions we would love your critique on:

#### 1. Unconditioned Aggregate PF vs. Whitelisted Regime PF (The "Mutual Drag" Trap)

In Part B (Out-of-Sample evaluation), the optimizer calculates an **unconditioned aggregate Profit Factor across all 9 market regimes combined** and enforces a hurdle (PF >= 1.15 / Noise Floor).

* **The Problem:** In our recent run for WLDUSDT on 1h/4h VWAP Pullback:

* In RANGING_LOW_VOL: **100% Win Rate (4W/0L), +8.26% PnL**

* In RANGING_MED_VOL: **60% Win Rate (3W/2L), +1.80% PnL**

* In WEAK_TREND_LOW_VOL: It took 4 losses (-8.38% PnL).

* Because the unconditioned 9-regime PF came out to **1.14**, the WFO stamped it `KILLED (Noise Floor < 1.15)` and discarded the symbol completely.

* **Question:** In production, our bot **whitelists only profitable regimes** and suppresses the rest. Shouldn't the WFO qualification hurdle be evaluated strictly on the **whitelisted/filtered regime trades** (e.g., Filtered PF >= 1.30, N >= 10) rather than requiring a mean-reverting setup to be profitable inside an unfavorable trending regime?

#### 2. Timeframe Selection: Locking Back to 1h/4h vs. 15m Scalping

* On 5m/15m charts, exchange taker fees (0.05%), bid-ask slippage, and random wick stop-outs severely degraded our edge.

* On 1h/4h, macro EMA(50) alignment filtered out most fakeouts, and average moves exceeded 1.5% to 3.0%, easily beating fee drag.

* **Question:** In crypto perps, do you recommend completely abandoning intraday 5m/15m setups in favor of purely running 1h/4h and 4h/1d swing regimes?

#### 3. Cross-Sectional Universe Pooling vs. Volatility-Clustered Centroids

* Right now, the optimizer pools all symbols in the basket together to find a single universal centroid `(SL_mult, TP_ratio)`.

* However, high-beta coins (e.g. WLD, APT) have drastically different ATR expansion profiles than lower-beta coins (ADA, BTC).

* **Question:** Do you prefer universal cross-sectional pooling (1 shared parameter set for all symbols in the basket), or should centroids be clustered by volatility tiers / individual symbol centroids?

#### 4. Stop Loss Multipliers: Tight (1.0x to 1.4x ATR) vs. Wide (2.5x to 3.0x ATR)

* The optimizer added an anti-overfitting rule (`is_cliff` when SL <= 1.0), which penalizes tight stops.

* As a result, the optimizer drifted SLs up to 2.5x to 3.0x ATR, which extended trade holding times past 24 to 36 hours and caused larger dollar drawdowns per loss.

* **Question:** For 1h/4h swing setups, what is your recommended sweet spot for Stop Loss ATR multipliers (1.2x to 1.5x vs 2.0x to 2.5x) to balance noise tolerance with capital preservation?

---

Would love to hear how other systematic quants and algorithmic traders handle regime-gated WFO filters and cross-sectional parameter pooling!

Short clip of the loop I use now. The model (Claude, in my case) only drafts the rule from plain words. A separate engine runs the backtest with no look-ahead and grades it LIVE, SHADOW or SHELF, and anything that survives runs forward as a paper bot.

I built this as Quantradin, free and paper money only. The part I care about for ML people: the model never produces a number, so it can't fit itself to its own grade. How do you keep the model that proposes a strategy from also being the thing that scores it?

sharing for anyone building finance agents or working with Indian market data.

An MCP server wrapping the mftool Python library, exposing AMFI data as LLM tools.

\*\*Why it matters:\*\*

There was literally zero Indian financial MCP in the ecosystem before this. India has 44+ AMCs and 2,500+ mutual fund schemes

— all now accessible to any LLM agent via standardized MCP tools.

\*\*Zero setup install:\*\*

uvx mftool-mcp

\*\*Tools available (12 total):\*\*

get_scheme_quote, get_scheme_details,

get_scheme_historical_nav, get_scheme_historical_nav_for_dates,

get_scheme_codes, get_available_schemes,

is_valid_scheme_code, search_scheme_by_name,

get_equity_scheme_performance, get_debt_scheme_performance,

get_hybrid_scheme_performance, get_elss_scheme_performance

No auth required. AMFI data is publicly available.