DEV Community: connerlambden

A 260-line vanilla-JS dashboard for ML stock forecasts (one CORS-open MCP endpoint, zero dependencies)

connerlambden — Wed, 27 May 2026 16:07:32 +0000

I'm a fan of "smallest thing that could possibly work" demos for APIs. If a tool needs Node + Webpack + a build step + 800 KB of node_modules before I can see what it does, I quietly close the tab.

So when I wanted to make a visual surface for Helium MCP's top-10 volatility candidate ticker stream, I went the other way: a single HTML file, one fetch call, no dependencies, no build, ~260 lines of JS. It is live at:

connerlambden.github.io/helium-news-explorer/tickers.html

Here is the architecture and the small handful of choices that made it work.

The endpoint

GET https://heliumtrades.com/mcp_top_strategies/

Returns a JSON object:

{
  "sort": "expected_vol_30d",
  "short_volatility": [ ... 5 tickers ... ],
  "long_volatility":  [ ... 5 tickers ... ]
}

Each ticker entry packs everything I need into one object:

{
  "ticker": "NVDA",
  "name": "NVIDIA Corporation",
  "latest_price": 138.45,
  "price_forecast_days": 37,
  "price_forecast_percent": 8.2,
  "price_forecast_lower_bound_percent": -12.6,
  "price_forecast_upper_bound_percent": 29.8,
  "bullish_case": "<p>Blackwell ramp ahead of plan; ...</p>",
  "bearish_case": "<p>Hyperscaler capex digestion risk; ...</p>",
  "analysis_date": "2026-05-27",
  "page_url": "..."
}

That's huge: the central forecast number AND the bull/bear narrative AND the uncertainty bounds come from the same model, so the chart you draw and the words you display agree on the same view of the world. No reconciliation step. No data joining. Just fetch, then render.

Crucially, Helium's MCP REST endpoints set Access-Control-Allow-Origin: *, so the page can fetch directly from the browser — no proxy, no server, no CORS tax.

The whole render path

<div id="content" class="loading">…</div>

<script>
const ENDPOINT = "https://heliumtrades.com/mcp_top_strategies/";

async function load() {
  const resp = await fetch(ENDPOINT, { cache: "no-store" });
  const data = await resp.json();
  document.getElementById("content").innerHTML = `
    <div class="columns">
      <div class="column short">
        ${data.short_volatility.map(t => cardHTML(t, "short")).join("")}
      </div>
      <div class="column long">
        ${data.long_volatility.map(t => cardHTML(t, "long")).join("")}
      </div>
    </div>`;
}
load();
</script>

Two columns. Five cards each. Template literals as a render engine. That's it. No virtual DOM, no reactivity, no router. The page is static the moment the fetch resolves.

The uncertainty cone in 18 lines of SVG

The interesting visual is the per-card uncertainty cone — a small wedge that gets wider with time, shaded green or red based on the forecast direction, with a line through the center showing the central forecast and a label at the endpoint:

function renderCone(forecastPct, lowerPct, upperPct, days) {
  const W = 260, H = 80, PAD = 6;
  const maxAbs = Math.max(Math.abs(lowerPct), Math.abs(upperPct),
                          Math.abs(forecastPct), 1);
  const yZero = PAD + (H - 2*PAD) / 2;
  const pctToY = p => yZero - (p / maxAbs) * ((H - 2*PAD) / 2);
  const xStart = PAD, xEnd = W - PAD;
  const yUp = pctToY(upperPct);
  const yDn = pctToY(lowerPct);
  const yFc = pctToY(forecastPct);
  const stroke = forecastPct > 0.1 ? "#6bff9c"
               : forecastPct < -0.1 ? "#ff6b8a"
               : "#8a93b8";
  const fill   = stroke.replace(")", ",0.18)").replace("#", "rgba(");
  return `<svg viewBox="0 0 ${W} ${H}" preserveAspectRatio="none">
    <polygon points="${xStart},${yZero} ${xEnd},${yUp} ${xEnd},${yDn}"
             fill="${fill}" stroke="${stroke}"/>
    <line x1="${xStart}" y1="${yZero}" x2="${xEnd}" y2="${yFc}"
          stroke="${stroke}" stroke-width="1.6"/>
    <circle cx="${xEnd}" cy="${yFc}" r="3" fill="${stroke}"/>
  </svg>`;
}

The cone is just a polygon with three points: (start, 0), (end, upper), (end, lower). The forecast line is a single segment from (start, 0) to (end, forecast). The whole shape collapses to a point at the left edge ("today") and fans out on the right ("today + 37 days").

I went back and forth on whether to plot the cone in absolute price terms vs. percent terms. Percent won: it makes a $69 KO card and a $1842 MSTR card visually comparable, since both cones are scaled to their own max-abs bound. You see the shape of uncertainty, not the units.

Why no chart library?

Because for 10 small charts with one polygon and one line each, a chart library is more code than the chart itself.

D3: 270 KB. Sets up d3.scaleLinear(), d3.area(), axes you don't need.
Chart.js: 200 KB. Needs a canvas, animation loop, plugin system.
ECharts: 1 MB+.

Hand-rolled SVG: 18 lines. The browser already has a SVG renderer. The math is one division per coordinate. The styling lives in the same CSS file as the rest of the page. Less is more.

The bull/bear narratives are HTML

Helium returns the cases as <p>...</p> strings. Easiest possible strip:

function stripHTML(s) {
  const tmp = document.createElement("div");
  tmp.innerHTML = s;
  return (tmp.textContent || tmp.innerText || "")
    .replace(/\s+/g, " ").trim();
}

Then truncate to ~280 chars with a word-boundary check so you don't cut mid-word:

function truncate(s, n) {
  if (s.length <= n) return s;
  const cut = s.slice(0, n);
  const lastSp = cut.lastIndexOf(" ");
  return (lastSp > n * 0.6 ? cut.slice(0, lastSp) : cut) + "…";
}

The card links to the full Helium analysis page for the long-form version.

Failure handling

The one real failure mode is a per-IP daily quota on the free tier (Helium returns HTTP 402 with no CORS headers, which the browser surfaces as a generic TypeError: Failed to fetch). I handle it the boring honest way:

try {
  const resp = await fetch(ENDPOINT, { cache: "no-store" });
  if (!resp.ok) throw new Error(`HTTP ${resp.status}`);
  // ... render ...
} catch (e) {
  root.innerHTML = `Could not load forecasts: ${e.message}.
    The Helium REST API enforces a per-IP daily quota for unauthenticated calls.
    Reload tomorrow, or browse the
    <a href="https://github.com/connerlambden/helium-mcp-cookbook">cookbook</a>.`;
}

A casual visitor will not hit this — each page load is one GET, and the free quota is ~50/day.

Companion explorer

The same repo also hosts a News Bias Explorer at the root, built on the same pattern: one fetch to mcp_all_source_biases/, vanilla-JS render of 216 sources × 37 bias dimensions, ranked bars and scatter plots with a live Pearson correlation. Same architecture, different data surface. connerlambden.github.io/helium-news-explorer.

Why this matters for the MCP ecosystem

Most MCP server demos are dense Python notebooks or CLI tools. They demonstrate the protocol but not the data. A casual visitor — a journalist evaluating bias-scoring tools, a retail trader curious about an options model, a researcher looking for a teaching corpus — won't install Python to find out.

A 21 KB HTML file on GitHub Pages, with no signup and no key, is the lowest-friction path from "I just heard about this server" to "oh, here's what it can do."

If you're building an MCP server, consider shipping a small zero-dep web surface next to your CLI examples. The marginal cost is one HTML file. The marginal benefit is every browser becoming a demo client.

Fear-coding in 160 news sources correlates +0.85 with political extremism — and only -0.08 with political direction

connerlambden — Wed, 27 May 2026 15:31:35 +0000

A common assumption in newsroom and media-literacy discourse is that fear-coded language is correlated with political "side" — that one ideological camp uses more fear language than the other. I wanted to test this empirically, so I pulled a structured per-source bias corpus, kept the sources with at least 100 analyzed articles plus both fear and political scores, and computed two correlations:

Pearson r between fear language and political direction (left vs right): −0.081
Pearson r between fear language and political extremism (|liberal–conservative|, ignoring direction): +0.854

That's a striking gap. In a sample of 160 sources, fear-coded language barely correlates with political direction — but it correlates very strongly with how far a source sits from the center, on either side. Fear is a feature of extremism, not of ideology.

This post walks through the data, the API I used, and the replication code. The whole analysis is under 30 lines of Python.

The data

I used the mcp_all_source_biases endpoint of the Helium MCP server, which exposes a structured bias profile for every source in its corpus. The endpoint is a plain HTTPS GET — no API key, no signup:

GET https://heliumtrades.com/mcp_all_source_biases/

It returns 216 sources, each with two top-level numeric fields (emotionality_score, prescriptiveness_score) plus a nested bias_values dict. Across the corpus, 37 distinct named dimensions appear in bias_values, including:

overall credibility
fearful bias
liberal conservative bias
opinion bias
oversimplification bias
appeal to authority bias
establishment bias
cruelty bias
scapegoat bias
conspiracy bias
victimization bias
ideological bias
political bias
written by AI

…and 23 others. Each value is an integer score. Most dimensions are populated for 150+ of the 216 sources.

For this analysis I filtered to sources with ≥100 analyzed articles plus both a fearful bias and a liberal conservative bias score. That left 160 sources.

The analysis

import json
import statistics

import requests

resp = requests.get("https://heliumtrades.com/mcp_all_source_biases/")
sources = resp.json()["sources"]

rows = []
for s in sources:
    bv = s.get("bias_values") or {}
    fear = bv.get("fearful bias")
    pol = bv.get("liberal conservative bias")
    n = s.get("articles_analyzed", 0)
    if isinstance(fear, (int, float)) and isinstance(pol, (int, float)) and n >= 100:
        rows.append((s["source_name"], fear, pol, n))

fear_vals = [r[1] for r in rows]
pol_vals = [r[2] for r in rows]

def pearson(xs, ys):
    mx, my = sum(xs) / len(xs), sum(ys) / len(ys)
    cov = sum((x - mx) * (y - my) for x, y in zip(xs, ys)) / len(xs)
    sx, sy = statistics.pstdev(xs), statistics.pstdev(ys)
    return cov / (sx * sy) if sx and sy else 0.0

print(f"Sources analyzed: {len(rows)}")
print(f"r(fear, lib-cons direction) = {pearson(fear_vals, pol_vals):+.3f}")
print(f"r(fear, |lib-cons|)          = {pearson(fear_vals, [abs(p) for p in pol_vals]):+.3f}")

Output on my run:

Sources analyzed: 160
r(fear, lib-cons direction) = -0.081
r(fear, |lib-cons|)         = +0.854

The top-15 most-fear-coded sources, with political context

Let me show the actual sources. Below are the 15 sources with the highest fearful bias scores, with their liberal conservative bias and overall credibility shown alongside.

Source	Fear	L/C	Cred
World Socialist	28	−33	0
American Thinker	27	+23	−2
Global Research	26	−14	−11
Common Dreams	26	−33	16
Activist Post	24	−3	5
The Federalist	21	+26	3
Counterpunch	21	−27	15
The Canary	20	−24	6
Truthout	20	−29	23
Daily Sceptic	20	+14	3
Gateway Pundit	19	+24	−6
Daily Signal	19	+29	−2
newrepublic.com	18	−28	15
American Spectator	18	+20	8
newsbusters.org	17	+20	−1

Notice the pattern: the L/C column has values like −33, +23, −14, −33, −3, +26, −27, −24, −29, +14, +24, +29, −28, +20, +20. The values are far from zero in both directions. Of the 15 sources, 8 are coded as politically left, 7 as politically right. The political direction is roughly balanced; the political magnitude is huge.

Compare with the middle-tercile mean. When I split the 160 sources into terciles by political direction:

Tercile	n	L/C range	Mean fear
Left	53	−33..−1	8.74
Center	53	−1..0	3.23
Right	54	0..+29	8.41

The U-shape is unmistakable. The center-tercile fear mean is less than 40% of either edge.

So what?

This kind of finding is what structured bias measurement is for. It's the empirical test of a folk-wisdom hypothesis. The folk wisdom predicts a monotonic relationship between fear language and one side of the political spectrum; the data shows a V-shape with the symmetry-breaking factor being political extremism, not political direction.

A few corollaries that I think are interesting:

Media-literacy curricula that teach "watch out for fear language as a signal of bias" should add: in either direction. Treating fear-coding as a signal exclusive to one camp will systematically miss the other camp's instances.
Newsroom self-audits that compare against ideological peers will see less fear than they expected. The right peer-group for comparison is moderation, not "the other side".
For any structured news intake (LLM agent, RAG pipeline, fact-checking workflow), fearful bias is partially redundant with |lib-cons|. They share most of their variance. If you're already adjusting for ideological extremism, you're already adjusting for most fear-coding.

A secondary finding while I was there: "written by AI" coverage

The same endpoint exposes a written by AI dimension. It's only populated for 27 of the 216 sources with ≥100 articles — a sparse signal. The top of the distribution is mostly auto-generated finance summary sites:

Source	"written by AI"	Cred
quiverquant.com (Opinion)	41	20
marketbeat.com	41	18
rappler.com	23	20
studyfinds.com	20	33
fool.com	5	25
benzinga.com	4	28

While the bottom (Reuters, CNBC, journal-news, tradingview, news-medical, etc.) sits at 0. Without more methodology detail this is suggestive rather than definitive, but the pattern matches what you'd expect: template-driven finance content scores high, established human-staffed publications score low.

Replicate it yourself

The full analysis is 25 lines of Python with requests as the only dependency. If you want to extend it, the helium-mcp-cookbook repo has a recipes/01_news_bias_dashboard.py script that does the corpus pull and dimension-ranking for any of the 37 bias dimensions:

git clone https://github.com/connerlambden/helium-mcp-cookbook
cd helium-mcp-cookbook
pip install -r requirements.txt
python recipes/01_news_bias_dashboard.py "fearful bias" 20
python recipes/01_news_bias_dashboard.py "scapegoat bias" 20
python recipes/01_news_bias_dashboard.py "cruelty bias" 20

You can run the same correlation analysis against any pair of dimensions. The 37-dimension space has 666 ordered pairs; I suspect there are several more publishable findings in there.

If you'd like the same endpoints inside an LLM client instead of a Python script, the MCP server config is in the main repo README.

Closing thought

The single most useful thing a structured-bias corpus does is let folk wisdom be tested. Fear-coding-as-left-coded or fear-coding-as-right-coded is a hypothesis everyone has informally, and now we can ask the data. The data says: it's not about side. It's about distance from the center.

That's the kind of empirical finding that should travel further than my marketing budget. Replicate the numbers, push back if you disagree, and if you find a different pattern with the same data, write the post — I'd love to read it.

How to Brier-grade your own ML option-pricing forecasts in 40 lines of Python

connerlambden — Wed, 27 May 2026 03:33:09 +0000

If you ship a probabilistic forecast, the single highest-value habit you can build is logging your forecasts so you can grade them later. Sabermetrics figured this out forty years ago. Weather forecasting has done it for a century. Most ML model owners still do not do it.

This post walks through a 40-line Python recipe that logs an ML option-pricing model's per-contract probability-ITM forecast to a CSV, so you can compute the Brier loss after the option expires. The recipe is part of a small open-source cookbook for the Helium MCP REST surface — an MCP server that also exposes its tools as plain HTTPS GETs, which makes it convenient as a teaching substrate even if you do not use MCP.

You will not need an API key, a signup, or a Python SDK.

What we are doing

For every option contract we care about, we want one row that records:

The contract identifier (symbol, strike, expiration, type)
The model's predicted fair value
The model's probability the contract finishes in the money
The model's data date
(Filled in later) the market mark at the same timestamp
(Filled in at expiration) the realized underlying price
(Computed) whether the contract was actually ITM
(Computed) the Brier loss for the probability forecast

When we Brier-grade later, we get one number per contract. Average across many contracts and we have a directly comparable calibration score — exactly the discipline a baseball win-probability model or a weather precipitation forecast gets graded on.

The endpoint

The Helium server exposes its option-pricing tool at this URL:

GET https://heliumtrades.com/mcp_option_price/
    ?symbol=AAPL&strike=310&expiration=2026-06-26&option_type=call

Plain GET, JSON in / JSON out, no auth header, free tier of 50 calls per IP per day. A live call returns:

{
  "symbol": "AAPL",
  "strike": 310.0,
  "expiration": "2026-06-26",
  "option_type": "call",
  "predicted_price": 6.53,
  "prob_itm": 0.42,
  "options_data_date": "2026-05-26"
}

Two of those fields are forecasts about the future: predicted_price (the model's fair value) and prob_itm (the model's probability the option finishes ITM at expiration). The expiration date in the request is the fixed resolution date. That gives us a clean falsifiable target.

The recipe

"""Log Helium's ML option-price + prob_itm forecasts to a CSV so you can
Brier-grade them at expiration.
"""
import csv
import sys
from datetime import datetime
from pathlib import Path

import requests

ENDPOINT = "https://heliumtrades.com/mcp_option_price/"
LOG_FILE = Path("calibration_log.csv")


def main(symbol, strike, expiration, option_type):
    params = {
        "symbol": symbol, "strike": strike,
        "expiration": expiration, "option_type": option_type,
    }
    resp = requests.get(ENDPOINT, params=params, timeout=30)
    resp.raise_for_status()
    data = resp.json()

    is_new = not LOG_FILE.exists()
    with LOG_FILE.open("a", newline="") as f:
        w = csv.writer(f)
        if is_new:
            w.writerow([
                "timestamp", "symbol", "strike", "expiration", "option_type",
                "helium_predicted_price", "helium_prob_itm", "helium_data_date",
                "market_mark", "realized_underlying_price", "realized_itm",
                "brier_loss",
            ])
        w.writerow([
            datetime.utcnow().isoformat(timespec="seconds"),
            symbol, strike, expiration, option_type,
            data.get("predicted_price"), data.get("prob_itm"),
            data.get("options_data_date"),
            "", "", "", "",
        ])
    print(f"Logged {symbol} ${strike} {option_type.upper()} {expiration}: "
          f"predicted={data['predicted_price']} prob_itm={data['prob_itm']}")


if __name__ == "__main__":
    main(sys.argv[1], float(sys.argv[2]), sys.argv[3], sys.argv[4])

Save as track.py, then:

pip install requests
python track.py AAPL 310 2026-06-26 call
python track.py AAPL 295 2026-06-26 put
python track.py NVDA 220 2026-07-17 call
# repeat for any contracts you want to grade later

The script appends one row per contract to calibration_log.csv. Snapshot the file once a day to capture how the forecast evolves over time.

Grading the forecast after expiration

At expiration, fill in the realized underlying price and compute Brier loss. For a single contract the Brier loss for the prob_itm forecast is:

brier_loss = (prob_itm - realized_itm) ** 2

where realized_itm is 1 if the contract finished in the money and 0 otherwise. Score every contract you logged, average the losses, and you have a calibration number you can compare across models, weeks, or strike regimes.

A quick scorer:

import csv
import pandas as pd

df = pd.read_csv("calibration_log.csv")

def realized_itm(row):
    s = float(row["realized_underlying_price"])
    k = float(row["strike"])
    if row["option_type"] == "call":
        return 1 if s >= k else 0
    return 1 if s <= k else 0

resolved = df[df["realized_underlying_price"] != ""].copy()
resolved["realized_itm"] = resolved.apply(realized_itm, axis=1)
resolved["brier_loss"] = (
    resolved["helium_prob_itm"].astype(float) - resolved["realized_itm"]
) ** 2

print(f"Contracts graded: {len(resolved)}")
print(f"Mean Brier loss: {resolved['brier_loss'].mean():.4f}")
print(f"Calibration histogram:")
print(resolved.groupby(
    pd.cut(resolved["helium_prob_itm"].astype(float), [0, 0.25, 0.5, 0.75, 1.0])
)["realized_itm"].mean())

The calibration histogram is the part most people skip. A model with mean Brier loss of 0.18 can still be wildly miscalibrated in specific probability bins (overconfident at extreme ends, say). The histogram tells you where it is miscalibrated.

Why this is useful

Most quant content compares predicted prices to current prices and stops there. That comparison cannot distinguish between "the model is right and the market is wrong" and the reverse — and both are unfalsifiable until expiration. Probability-ITM, on the other hand, has an unambiguous resolution: the underlying either closes above the strike or it does not.

So prob_itm is the friendliest output to grade. If you want to spend an hour playing with calibration intuition, log forecasts for 50 contracts across a few different expirations, wait for them to resolve, and run the scorer.

Other recipes in the cookbook

The same pattern — one endpoint, one short script, real output — works for the other tools the Helium server exposes:

News-bias dashboard: pull every tracked source's bias profile and rank by overall credibility, fearful bias, emotionality_score, or any other dimension
Balanced-news synthesis: pull multi-source synthesis on any topic with probability-weighted falsifiable outcomes already baked in
Source credibility ranking: top-N and bottom-N sources by credibility, with their emotionality and prescriptiveness alongside
Ticker forecast explorer: pull HTML-stripped bull/bear narrative cases for a watchlist
Top-strategies explorer: pull the daily short-vol and long-vol candidate lists

All six recipes are in the open-source cookbook here:

➡️ github.com/connerlambden/helium-mcp-cookbook

The cookbook is MIT-licensed. Fork it, modify it, write your own recipes. PRs welcome.

If you want MCP instead of REST

The same ten tools are also exposed as a remote MCP server. If you would rather call them from inside Claude Desktop, Cursor, or any MCP-aware client, the config is:

{
  "mcpServers": {
    "helium": {
      "command": "npx",
      "args": ["mcp-remote", "https://heliumtrades.com/mcp"]
    }
  }
}

After a client restart your LLM can call the same tools by name. The Helium repo is at github.com/connerlambden/helium-mcp.

Closing thought

If your model emits probabilities, you should grade them. The friction-free version is a 40-line script and a CSV. The day you put that habit in place is the day your forecasts start improving — not because the model changes, but because you finally have a feedback signal to learn from.

I probed my own MCP server — here's what 7 live API calls actually return

connerlambden — Wed, 27 May 2026 00:28:37 +0000

I've been writing about MCP servers for a couple of months now. The most common (fair) reply I get is some version of "cool thesis, but show me what actually comes back when you call it." This post does exactly that. I sat down today, ran seven real calls against the Helium MCP + REST surface, and pasted the actual JSON below. No screenshots, no curated demos, no "imagine if." The numbers below are timestamped May 26, 2026, the same day I wrote this.

Helium is a free MCP server + plain REST API that combines two things people normally pay separate vendors for: (1) per-symbol ML-derived options pricing and (2) 31-dimensional structured news-bias scoring across ~5,000 sources. The REST surface is meant to be reachable from a five-line requests.get. The MCP surface is the same backend with tool-registration metadata on top. There's no signup, no API key, no SDK — just an IP-rate-limited free tier (50/day).

Let's see what it returns.

Probe 1: NVDA ticker (`/mcp_ticker/`)

import requests
r = requests.get("https://heliumtrades.com/mcp_ticker/", params={"ticker": "NVDA"})
print(r.json())

What came back today:

Latest price: $215.33
37-day forecast: +6.0% (lower-bound +2%, upper-bound +10%)
Probability-weighted outcomes:
- 45% — NVDA above $230 within 45-90 days
- 25% — chop in $210-230 over 30-120 days
- 20% — drift to $190-210 within 45-120 days
- 7% — severe to $180-190 within 60-120 days
- 3% — ultra-bearish below $180

Each probability is supposed to be Brier-scoreable — if the model says "45% above $230 in 45 days," that's a falsifiable claim with a resolution date. You can backtest it against expiration.

Probe 2: AAPL options ML pricing (`get_option_price`)

This is the one I most wanted to test live. AAPL is at $308.33 today. I asked for the 30-DTE $310 call (close to ATM, June 26 expiration):

r = requests.get("https://heliumtrades.com/mcp_option_price/", params={
    "symbol": "AAPL", "strike": 310,
    "expiration": "2026-06-26", "option_type": "call",
})
print(r.json())
# {"symbol":"AAPL","strike":310.0,"expiration":"2026-06-26","option_type":"call",
#  "predicted_price":6.53,"prob_itm":0.42,"options_data_date":"2026-05-26"}

The market mark on this contract today is $7.55. Helium's model says fair value is $6.53 — i.e., the contract is overpriced by ~$1, or ~13.5% above what the model thinks it should clear.

The contract's delta is 0.50 (market-implied probability of finishing in the money is ~50%). Helium's prob_itm is 0.42, meaningfully lower. Two ways to read it:

The model thinks IV is too high. (Helium thinks realized vol will undershoot implied — a short-premium-into-strength view.)
The model is wrong. (Always a live hypothesis.)

The point is the disagreement is concrete and testable. On June 26, this contract resolves. If AAPL closes below $310, the model wins one (or rather, gets a partial credit on the calibration test). The whole point of prob_itm being explicit is so you can score it. Compare with the put side:

# AAPL 295P 6/26  — market mark $3.09
# Helium predicted: $2.36  /  prob_itm 0.23  (market-implied via delta: ~0.24)

The put case is funnier: Helium agrees with market-implied probability to within one percentage point, but disagrees on the price by ~24%. That can only happen if the model thinks the payoff conditional on ITM is smaller than what market IV would price it. That's a different bet from the call-side bet, and you can see both surfaces from the same endpoint.

Probe 3: Top trading strategies (`get_top_trading_strategies`)

r = requests.get("https://heliumtrades.com/mcp_top_strategies/")
print(r.json())

Today's output ranks long-vol and short-vol candidates across the whole equity universe. Top 5 of each:

Short vol (likely overpriced IV)	Long vol (likely cheap IV)
SWK — Stanley Black & Decker ($78.94)	DUK — Duke Energy ($125.01)
UVV — Universal ($54.61)	KD — Kyndryl ($12.04)
ABCL — AbCellera Biologics ($5.20)	BEN — Franklin Resources ($31.02)
HAS — Hasbro ($87.99)	SNAP — Snapchat ($5.75)
BEN — Franklin Resources ($31.02)	OUST — Ouster ($42.70)

Note that BEN appears on both sides — sometimes the long-vol model and the short-vol model disagree on the same name. That's a feature, not a bug; it signals the kind of name where the term structure is doing something interesting and a calendar/diagonal might be the actual edge.

Each name also comes back with full bullish-case / bearish-case / probability-weighted outcomes (same shape as the NVDA pull above). One call, top-N ranked candidate list, ready for further filtering.

Probe 4: News bias on a source (`get_source_bias`)

I picked WSJ:

r = requests.get("https://heliumtrades.com/mcp_source_bias/", params={"source": "Wall Street Journal"})
print(r.json())

Returned (excerpt of the 31 dimensions):

Articles analyzed: 528
Emotionality: 7 / 10
Sensational: 3, Fearful: 4, Opinion: 4, Political: 3
Anti-establishment ↔ Pro-establishment: +6 (pro)
Dovish ↔ Hawkish: +2 (hawkish)
Covering responses (defensive framing): 6 / 10
Signature phrases: "hoover institution fellow", "jerome powell", "spirit airlines"

Notice how the signature phrases are doing real work. They're not generic — they're the multi-word expressions that appear at higher frequency than the cross-corpus baseline. That tells you the editorial fingerprint without you having to read 528 articles.

Probe 5: All source biases at once (`get_all_source_biases`)

This is the one I think is genuinely under-appreciated. One call, 216 sources, 113,253 articles' worth of aggregated 31-dim scoring:

r = requests.get("https://heliumtrades.com/mcp_all_source_biases/")
# Returns: {"sources": [216 entries with full bias profiles]}

Sorting today's snapshot by a single dimension, here's the bottom-and-top tail of the Fear score (0-30 scale):

Most fearful	Score (out of 30)	Articles
World Socialist	28	296
Unz	28	178
American Thinker	27	139
Global Research	26	109
Common Dreams	26	293

What's interesting is that "most fearful" cuts across the political spectrum — World Socialist (far-left), Unz (far-right), American Thinker (right), Common Dreams (left), Global Research (conspiratorial-left). High fear in framing isn't a partisan signature; it's a style. You couldn't see that without aggregated source-level scoring.

By the Credibility dimension instead:

Highest credibility	Score (out of 50)	Articles
AP	41	404
Texas Tribune	37	138
Science Daily	37	232
medicalxpress.com	36	133
earth.com	36	110

The corpus is big enough that the rankings are stable.

Probe 6: Balanced news synthesis (`search_balanced_news`)

r = requests.get("https://heliumtrades.com/mcp_balanced_search/", params={"query": "fed rate cuts", "limit": 1})

Output (excerpt):

"summary": "Fed signals potential rate cuts, affecting markets and mortgage rates.",
"takeaway": "Anticipated rate cuts indicate optimism for easing borrowing costs, but risks of inflation resurgence remain important.",
"context": "Federal Reserve's monetary policy decisions are highly consequential, impacting various economic sectors...",
"evidence": ["Cooling inflation and stable economic indicators...[16]",
             "Anticipation of rate cuts has spurred refinancing activities...[8]"],
"potential_outcomes": [
   "Rate cuts stimulate growth and stabilize housing — economic expansion (70%)",
   "Premature rate cuts reignite inflation — economic instability (30%)"],
"relevant_tickers": "SPY,QQQ,NLY",
"num_sources": 4

That's a multi-source synthesis with probability-weighted falsifiable outcomes, citation indices, relevant tickers tagged out, and the synthesis assembled from 4 sources. One HTTP call. The "70% rate cuts stimulate growth" claim is again Brier-scoreable.

Probe 7: One source's tagged bias on a real URL (`get_bias_from_url`)

r = requests.get("https://heliumtrades.com/mcp_url_bias/", params={"url": "https://www.bbc.com/news"})

Returns: source identification, total social shares (338,183 for the BBC homepage), and per-URL bias metadata when the article has been scored. This one is the cheapest call to do at scale on a backlog of URLs you have lying around — paste a URL in, get a structured score back.

MCP is quietly commoditizing data+model SaaS moats — the structural case

connerlambden — Tue, 26 May 2026 23:41:03 +0000

I shipped an MCP server six months ago and spent the last couple of weeks emailing data-engineering and AI-VC newsletter writers about it. The reactions sorted into two piles. Pile A: "cool, another MCP toy." Pile B: "wait, is this actually a structural threat to data+model SaaS moats?"

Pile B is right. This post is the short version of the argument.

The thesis in one sentence

MCP turns the kind of API that used to require a sales cycle, an OAuth dance, an SDK, and a dashboard — into a five-line tool call from inside an LLM.

That's not just a developer-ergonomics improvement. It's a change in the cost structure of distribution for a specific class of B2B product.

The class of product I mean

I'm narrowly talking about "data-plus-model" SaaS: companies whose moat is (1) a proprietary dataset (or a process for building one) and (2) a model trained on it, exposed through a paid API and a dashboard. Examples in the wild: most fintech data vendors, sentiment-API vendors, document-extraction APIs, "alternative data" SaaS, news-bias dashboards, options-analytics platforms.

These products historically distributed through:

An enterprise sales motion (talk to a rep, sign an MSA, get an API key)
A self-serve dev portal (sign up, copy API key, install our SDK, read docs, build integration)
A dashboard layer (the actual product surface for non-developers)

All three of those distribution layers are cost, not value. They exist because there was no cheaper way to get the model output into the hands of a downstream user.

What MCP changes

MCP is a tiny, dull spec: standardize how an LLM client discovers and calls external tools. Trivial in the technical sense. But here's what it does economically:

It collapses the distribution cost of "data-plus-model output → downstream user" to approximately zero.

A user asks Claude/Cursor/Windsurf "what's the AI-derived fair value of AAPL $200 calls expiring 6/19?" The LLM, with my MCP server installed, makes one tool call. The data + model output lands in the conversation. No sales rep, no API key, no SDK, no dashboard. The "product surface" is whatever LLM the user is already using.

That collapse has cascading effects:

The dashboard layer becomes optional. For users with an LLM open, the LLM is the dashboard. The vendor's expensive UI investment is no longer the primary surface.
The dev portal becomes optional. "Install the MCP server" is the new "sign up for an API key." It's one paste of a URL into an LLM config.
The sales motion becomes optional. A free-tier MCP server with no signup is a perfectly viable surface, because there's no friction to try it.
The moat is now whatever moat the underlying data+model has — minus the distribution layer that used to be 60-80% of the company's expense.

A concrete example

I run Helium, which exposes per-symbol ML options pricing (fair value, prob_ITM, Greeks) and 31-dim news-bias scoring across 3.2M articles. As an MCP server. And, recently, also as a plain REST API:

import requests

r = requests.get(
    "https://heliumtrades.com/mcp_option_price/",
    params={
        "symbol": "AAPL",
        "strike": 200,
        "expiration": "2026-06-19",
        "option_type": "call",
    },
)
print(r.json())
# {"predicted_fair_value": 20.64, "prob_itm": 0.52, "greeks": {...}}

The same backend serves both interfaces. The MCP server is a thin metadata wrapper over the REST endpoints. When an LLM client calls a Helium MCP tool, what actually happens at the network level is identical to what happens when a Python script calls the REST endpoint.

That's the key technical observation. MCP and REST are two views into the same data+model. MCP is the "embedded in an LLM client" view. REST is the "embedded in a Python script" view. They share the model, the data, the infrastructure, the cost basis. There is no MCP-specific work happening server-side.

This means a company shipping an MCP server gets the entire AI-assistant-using developer audience as a distribution channel — for free, at zero marginal cost over the REST API they were already serving.

What this implies for fintech-data and sentiment-API valuations

If you're an investor or operator in this space, the structural implications are non-trivial:

The "moat" portion of the valuation is now under-supported. Companies whose multiple is driven by "API integrations across N enterprise clients" are pricing in a distribution lock-in that MCP partially erodes.
The "data plus model" portion of the valuation is what's actually defensible. If your dataset is genuinely hard to build and your model is genuinely better, MCP is neutral-to-positive for you (it cheapens distribution, but doesn't help competitors who lack the underlying assets).
The marketing motion has to change. "Pay $500/mo for our dev portal access" is a hard sell against "free MCP server, no signup, IP-rate-limited 50/day, install in 30 seconds." Even if the paid offering is more featured, the price-anchor moves.
A new class of free-tier-only data+model business becomes viable. Where the unit economics of paid-tier-dashboard SaaS were marginal, a free-tier-only MCP server backed by ads, sponsorship, or community good-will can work. (Helium is this.)

The counterargument

The standard pushback is that MCP is just a thin shim over what already worked (REST APIs + an SDK), and that nothing has fundamentally changed. I think this misses the audience reach delta. The audience of "developers willing to install your SDK" is a subset of "developers willing to install your MCP server" which is a subset of "users of Claude/Cursor/Windsurf who can paste a config." Each step up the audience hierarchy is roughly 10x. MCP doesn't replace REST — it makes the same backend reachable by ~100x more users at zero marginal cost.

What to watch

Whether the major LLM clients (Claude Desktop, Cursor, ChatGPT) settle on common MCP registry / discovery patterns. The faster this happens, the more aggressive the "data+model SaaS as MCP" trend becomes.
Whether established data vendors ship MCP surfaces over their existing REST APIs. (Bloomberg won't; mid-tier vendors will start.)
Whether free-tier MCP-only data plays start eating mid-tier paid-API revenue. The Helium-style "free, no signup, 50 queries/IP" model is the leading indicator.

TL;DR

MCP is the cheapest distribution layer ever invented for data+model SaaS. The shape of competition in that segment changes accordingly. If you're a vendor whose moat was distribution, you should be worried. If your moat is the actual data+model, you should be busy shipping an MCP server.

Helium MCP is open source: https://github.com/connerlambden/helium-mcp

MCP servers are just REST APIs in a polite wrapper - here's 5 lines of Python

connerlambden — Tue, 26 May 2026 22:38:09 +0000

If you've been watching the MCP (Model Context Protocol) ecosystem from the sidelines, here's a quietly important detail: a lot of MCP servers are also just plain REST APIs underneath. The MCP layer is a polite wrapper that says "Claude, here are tools you can call." But the underlying HTTP endpoints are right there, ready to be called from requests.get(...) like any other JSON API.

That matters because the most interesting MCP servers are useful even if you've never opened Claude Desktop or Cursor. You can drop them into a Streamlit app, a Jupyter notebook, a Lambda function, a Discord bot, an Airflow DAG, or a cron job. The MCP integration is gravy on top.

I'll show this with a concrete example: pulling per-symbol ML option fair values and 31-dimension news-bias scores into pandas in 5 lines.

The setup

I run Helium MCP, which started as an MCP server and recently grew a plain REST surface. Both speak the same data:

Per-symbol ML options pricing - predicted fair value, probability ITM, Greeks
31-dimension news-bias scoring across 3.2M articles and 5,000 sources
Real-time market data, top trading strategies, semantic meme search, source bias profiles

The MCP endpoint is https://heliumtrades.com/mcp. The REST endpoints live under https://heliumtrades.com/ with paths like /mcp_search/, /mcp_option_price/, /mcp_ticker/, /mcp_url_bias/. 50 free queries per IP. No signup, no API key needed for the free tier.

Five lines of Python

import requests

r = requests.get(
    "https://heliumtrades.com/mcp_search/",
    params={"q": "apple earnings", "limit": 3},
    timeout=30,
)
print(r.json())

You get back a JSON list of articles with full bias scoring across all 31 dimensions per article: credibility, sensationalism, overconfidence, opinion_vs_fact, scapegoating, ai_authorship_probability, covering_responses, oversimplification, and 23 more.

Loading into pandas

This is where it gets fun. The JSON is already flat enough that pandas just works:

import pandas as pd, requests

resp = requests.get(
    "https://heliumtrades.com/mcp_search/",
    params={"q": "federal reserve", "limit": 50},
)
df = pd.json_normalize(resp.json())
print(df[["source", "credibility", "sensationalism", "opinion_vs_fact"]].head())

Now you can do everything pandas does: groupby source, compute mean credibility, plot a credibility-vs-sensationalism scatter, filter to high-AI-authorship-probability articles, etc.

Option fair values, also 5 lines

import requests

r = requests.get(
    "https://heliumtrades.com/mcp_option_price/",
    params={
        "symbol": "AAPL",
        "strike": 200,
        "expiration": "2026-06-19",
        "option_type": "call",
    },
)
print(r.json())
# {'predicted_price': 20.64, 'prob_itm': 0.52, 'delta': 0.55, 'gamma': 0.02, 'vega': 0.41, ...}

You get back a model-derived fair value and prob_ITM next to market price. The diff between the two is a (testable, scorable) prediction.

A small Streamlit app

Once the API returns JSON, building a Streamlit app is essentially a wrapper exercise:

import streamlit as st, requests, pandas as pd

q = st.text_input("Search query", "tariffs")
limit = st.slider("Results", 1, 50, 10)

if st.button("Go"):
    resp = requests.get(
        "https://heliumtrades.com/mcp_search/",
        params={"q": q, "limit": limit},
    )
    df = pd.json_normalize(resp.json())
    st.dataframe(df[["title", "source", "credibility", "sensationalism", "ai_authorship_probability"]])
    st.bar_chart(df.groupby("source")["credibility"].mean())

This is the smallest realistic media-bias dashboard I've ever written. It's about 12 lines.

Where this fits in your stack

The point isn't that this one API is special. The point is that MCP servers with REST surfaces are a quietly powerful new class of API. They are:

LLM-native by design - built so an LLM can call them without a custom integration
Schema-rich - the MCP tool spec doubles as auto-generated API documentation
Free-tiered aggressively - because the operator wants discoverability in LLM clients
Composable from anything HTTP - Python, JS, curl, Go, n8n, Zapier, Make

If you're a data scientist who's never installed Claude Desktop and never wants to: that's fine. Treat MCP servers as a directory of unusually well-curated free REST APIs and start with the ones that solve a problem you already have.

For finance and news intelligence specifically, the full Helium MCP REST endpoint list is:

Endpoint	Purpose	Params
`/mcp_search/`	News search across 3.2M articles	`q`, `limit`
`/mcp_balanced_search/`	Multi-perspective news synthesis	`q`, `limit`
`/mcp_source_bias/`	31-dim bias profile for one source	`source`
`/mcp_url_bias/`	31-dim bias profile for one article URL	`url`
`/mcp_all_source_biases/`	All scored sources	-
`/mcp_ticker/`	Real-time market data for a symbol	`ticker`
`/mcp_option_price/`	ML option fair value + Greeks	`symbol`, `strike`, `expiration`, `option_type`
`/mcp_historical_options/`	Full options chain with ML fair values	`symbol`, `date`
`/mcp_top_strategies/`	AI-ranked options strategies	`limit`, `sort`
`/mcp_meme_search/`	Semantic meme search	`q`, `limit`

The MCP server config (for Cursor / Claude Desktop / Windsurf) is:

{ "mcpServers": { "helium": { "url": "https://heliumtrades.com/mcp" } } }

But honestly - if Python is your thing - just open a notebook and requests.get. The whole point of a public REST surface is that you don't have to care about anything else.

Source, schema, full tool spec: github.com/connerlambden/helium-mcp. Page: heliumtrades.com/mcp-page.

If you build something with it, I'd love to see it. Open an issue, or send a notebook - happy to feature good demos.

Detecting AI-authored news at corpus scale from a single MCP call

connerlambden — Tue, 21 Apr 2026 15:04:16 +0000

There's a growing crisis inside news feeds: AI-generated content, slop, and opinion-masked-as-reporting are all appearing faster than human review systems can flag them. Most "AI detection" tools work per-document and return a single binary probability with no supporting evidence. That's not enough for someone who has to actually decide what to read, publish, or cite.

I put the opposite approach behind an MCP server - a continuous, corpus-scale, per-article ai_authorship_probability score, plus 30 other framing dimensions, all queryable in plain English from Claude or Cursor.

The core dimension

Helium MCP scores every article it ingests across 3.2M+ articles and 5,000+ sources on:

ai_authorship_probability - explicit model estimate that the article was LLM-generated
credibility - sourcing density, named-source ratio, evidence-citation patterns
sensationalism - headline-vs-body amplification, superlative density
overconfidence - hedge-language vs declarative-certainty ratio
opinion_vs_fact - opinion language vs declarative-fact language ratio
oversimplification - single-cause reduction of complex causation
begging_the_question - conclusion assumed in the framing
scapegoating - actor-blaming vs structural-explanation patterns
covering_responses - whether the criticized parties get space to respond
...22 more

The point is not that any one score is a verdict. The point is that you can now triangulate. A high AI-authorship probability paired with low sourcing density and high sensationalism is a very different signal from high AI-authorship in a meticulously-sourced explainer - and a scoring pipeline that only returns one number cannot tell them apart.

Setup

# In Cursor or Claude Desktop MCP config:
npx mcp-remote https://heliumtrades.com/mcp

Free. No signup. No API key. Remote server.

Asking the question

In Claude, I asked:

Using Helium, show me the most AI-suspicious recent articles across the corpus, and cross-reference against their credibility and sensationalism scores.

Claude called search_articles, filtered by the top decile of ai_authorship_probability, joined against per-source metadata, and returned a ranked list with the four relevant scores side-by-side. The top of the list was dominated by low-credibility, high-sensationalism sources - which is what you'd expect. But the more interesting result was a small cohort in the middle of the pack: high AI-authorship, high credibility, moderate sensationalism. Those are almost certainly human-edited AI drafts - the category that a single-axis detector would miss entirely.

Why 31 dimensions, not one

The one-number-detector fails in two ways:

False negatives from human editing. A human editor can smooth an LLM draft enough to drop a binary detector score below threshold, but framing artifacts (overconfidence pattern, opinion-vs-fact ratio, coverage-of-responses) survive. Multi-dim signal catches them.
False positives from LLM-like human writing. Academic-style prose is often flagged as AI-generated by single-axis detectors. But the sourcing-density and citation-evidence axes in a 31-dim score are the difference between a grad student and an LLM - and they show up cleanly in the schema.

Example use cases

Newsroom standards editors - a daily cron job that flags high-AI-authorship articles in your freelance submissions bucket, weighted by credibility score, before an editor ever opens them.

Fact-checkers - when triaging a viral claim, pull the source's recent-window scores on ai_authorship_probability, credibility, and overconfidence. A source that has drifted toward AI authorship and away from sourced evidence is a different trust situation than one that has been stable.

Journalism-school instructors - assign students to pull 10 articles from a single publication across a decade, graph the ai_authorship_probability and credibility trend lines, and write a piece on what changed.

AI-safety researchers - the full 31-dimension scored corpus is a ready-made dataset for studying how LLM-generated news content is spreading through mainstream feeds.

Live example

Here's a real query I ran in Claude:

Helium: Show me how AI-authorship probability has moved for tech-news sources over the last year, correlated with credibility.

Claude used the MCP tools, ran the query across the Helium corpus, and returned a tidy summary showing that several mid-tier aggregator sources have seen a meaningful upward shift in ai_authorship_probability over the last 12 months, while their credibility score drifted down. That's a reportable trend. The reporter didn't have to build a scraper, didn't have to maintain a classifier, didn't have to write SQL - they asked a question in English.

What to do

If you work anywhere near news - as a reader, a writer, an editor, a researcher, or someone building AI-news workflows - try it:

npx mcp-remote https://heliumtrades.com/mcp

Then ask Claude the question you've been asking Google and failing to get a structured answer from. The 31-dim schema is there, the corpus is populated, and the tool calls are free.

Full tool list, full schema, full source: github.com/connerlambden/helium-mcp.

If you find the schema missing something important, open an issue or reach out. The axes were picked empirically across 3.2M articles, but the space of things-worth-measuring about a news article is larger than what's in the schema today - and I'd rather know.

31 dimensions of news bias, queryable from Claude in plain English

connerlambden — Sun, 19 Apr 2026 22:21:30 +0000

The problem

Most "news bias" tools collapse a story into a single number on a left-right axis. That's useful for a thumbnail, but it's the wrong granularity for almost any real workflow - a newsroom standards editor, a fact-checker triaging a viral claim, a journalism-school instructor teaching framing, an AI safety researcher building a misinformation classifier.

What those workflows actually need is structured, multi-dimensional, queryable framing data. So I built it and put it behind an MCP server that any AI assistant can call.

The schema

Helium MCP scores every article on 31 dimensions. A non-exhaustive sample:

liberal_conservative - the standard left-right axis (kept for compatibility)
credibility - sourcing density, named-source ratio, evidence-citation pattern
opinion_vs_fact - opinion language vs declarative-fact language ratio
scapegoating - actor-blaming patterns vs structural-explanation patterns
covering_responses - whether the article gives space to the people/orgs being criticized
fearful - emotional valence, threat language
sensationalism - headline-vs-body amplification, superlative density
overconfidence - hedge language vs declarative certainty
intelligence - reading level, conceptual density
begging_the_question - assumes the conclusion in the framing
oversimplification - reduces complex causation to single factors
ai_authorship_probability - explicit estimate that the article was LLM-generated
... 19 more

The key thing is that every dimension is operationalized - it's not just "vibes" labeling, each one is computed from features in the text.

The corpus

3.2M+ articles
5,000+ sources
Updated continuously
Sources span global mainstream, US partisan, business press, tech press, regional, and long-tail / hyperlocal

The MCP interface

Helium MCP exposes this via three main tools you can call from any AI assistant:

get_source_bias(source) - aggregate scores across a source's recent corpus
get_bias_from_url(url) - score a single article on demand
search_balanced_news(query) - synthesize multi-source coverage of an event with structured outcomes

Setup (one line)

Add to your mcp.json in Cursor or Claude Desktop:

{
  "mcpServers": {
    "helium": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://heliumtrades.com/mcp"]
    }
  }
}

Free, no signup, no API key.

A real example

In Claude, I asked: "Show me the bias profile for CNN's recent corpus using Helium."

Real output (445 articles analyzed):

Liberal/Conservative:  -2   (slightly left)
Credibility:           15   (moderate-high)
Fearful:                4
Intelligence:          11
Covering Responses:     9   (gives space to the criticized)
Opinion:                5
Overconfidence:         8

The value of seeing it as 31 numbers (and not 1) is that you can ask follow-up questions like "For these same articles, are the high-credibility ones more or less likely to be high-overconfidence?" - and the agent can compute the correlation in-place.

Use cases this unlocks

For a newsroom standards editor: triage incoming wire/syndication content by ai_authorship_probability before it goes through your editorial pipeline.

For a fact-checker: rank a list of suspect URLs by credibility (low) and overconfidence (high) - the combination is a strong indicator of claims worth investigating.

For a journalism instructor: show students how the same event was framed across 10 sources, with structured scapegoating / covering_responses / opinion_vs_fact scores attached.

For an AI safety researcher: the schema is essentially a deployed multi-criterion eval pipeline applied to news rather than to LLM outputs - useful as an empirical reference for how multi-criterion eval criteria interact with each other in production (Goodhart, distribution shift, taxonomy choice).

For anyone building an AI agent that consumes news: structured per-source/per-article framing metadata is the missing primary key for reasoning about source reliability programmatically.

The bigger point

In a world where readers query LLMs more than they visit homepages, the value of an individual article goes down and the value of structured, queryable, per-article metadata goes up. The schema above is one open attempt at what that metadata layer should look like.

If you have ideas for dimensions that should be added (or critiques of the existing ones), I'd love to hear them - the methodology is open.

Caveats

This is not a substitute for human editorial judgment. Bias scoring is hard, the schema can be wrong, and there are distribution-shift / Goodhart concerns with any operationalized criterion. Use it as a triage layer, not a verdict.

How I screen for ratio spread opportunities in 30 seconds with an MCP server

connerlambden — Sun, 19 Apr 2026 22:05:52 +0000

The setup

A "ratio spread" in options trading is when you sell N options at one strike and buy M options at another, where N != M. The classic 1x2 put ratio spread (sell 1 ATM put, buy 2 OTM puts) is a favorite of vol traders because it lets you express a view that downside skew is overpriced and gives you positive convexity if the market really crashes.

The hard part is finding candidates. Skew mispricings are the kind of thing you used to need a Bloomberg terminal + a custom IV-surface model + an analyst to surface. With a free remote MCP server I built called Helium MCP, you can do it in 30 seconds inside Claude Desktop or Cursor.

What the MCP exposes

Helium MCP is a thin wrapper over a per-symbol ML options pricing model. For any contract, it returns:

predicted_price - Helium's model fair value
prob_itm - probability of expiring in the money
options_data_date - freshness of the chain snapshot

The model is trained per-symbol on each ticker's own historical options data, so it makes different (and sometimes wildly different) calls than a generic Black-Scholes fit.

Setup (one line)

Add to your mcp.json in Cursor or Claude Desktop:

{
  "mcpServers": {
    "helium": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://heliumtrades.com/mcp"]
    }
  }
}

That's it. Free, no signup.

Finding a ratio-spread candidate

Inside Cursor, I asked the agent: "Pull AAPL option prices from Helium for May 15 expiry across $180/$195/$200/$205 strikes."

Real output, just now:

get_option_price('AAPL', 200, '2026-05-15', 'call')   ->  $20.64,  prob_itm 0.52
get_option_price('AAPL', 205, '2026-05-15', 'call')   ->  $20.69,  prob_itm 0.52
get_option_price('AAPL', 195, '2026-05-15', 'put')    ->  $0.06,   prob_itm 0.01
get_option_price('AAPL', 180, '2026-05-15', 'put')    ->  $0.02,   prob_itm 0.01

Look at the puts. The model thinks AAPL has effectively 1% probability of finishing below $195 by mid-May. The market is paying actual money for those puts (and a lot more for the deeper OTM ones - that's the skew).

If you believe the model, the deep OTM put side is the overpriced side. That's a textbook setup for a 1x2 put ratio spread:

Sell 1 near-ATM put (collect the rich premium the market is offering for a bearish view)
Buy 2 deep OTM puts (cheap insurance + tail-side convexity)

If the market chops sideways or rallies (the model's base case), all the puts expire worthless and you keep the credit. If the market crashes hard, the 2 long puts catch up to and exceed the 1 short put.

The point isn't this specific trade

The point is that screening this kind of structural mispricing went from "needs an institutional setup" to "ask Claude in plain English" the day MCP made it possible to expose model APIs to LLMs.

The same workflow applies to:

Calendar spread arbitrage (compare term-structure of Helium IV vs market IV)
Diagonal spreads (mix the two)
Volatility compression candidates - Helium MCP has a get_top_trading_strategies endpoint that returns a daily-ranked long-vol vs short-vol screen with explicit bull/bear cases:

"Market IV (~30%) above Helium IV (~26-27%) across maturities - favoring volatility compression. Skew is mostly tail-priced..."

The bigger picture

ML option pricing was an institutional moat for two decades. With MCP, the marginal cost of querying an ML option pricing model from inside an LLM is zero. That changes who can run a structured options screen.

Helium MCP also exposes 31-dimension structured bias scoring across 3.2M+ news articles (5,000+ sources) - useful for the news/narrative side of trading - but that's a topic for another post.

Caveats

This is not trading advice. Helium's model can be wrong. Per-symbol regression models can overfit. Always size positions appropriately and validate against your own framework.

How to Give Your AI Assistant Real-Time Market Intelligence

connerlambden — Tue, 14 Apr 2026 21:15:15 +0000

MCP (Model Context Protocol) lets AI assistants call external tools. I built a remote MCP server called Helium that gives any MCP-compatible AI assistant access to real-time financial intelligence — market data, ML-powered options pricing, news bias analysis, and more.

The interesting part isn't the financial data itself (there are plenty of market APIs). It's what happens when you combine structured financial data with an LLM's reasoning.

Setup (30 seconds)

Add one line to your AI assistant's MCP config:

Cursor / Windsurf:

{"mcpServers":{"helium":{"url":"https://heliumtrades.com/mcp"}}}

Claude Desktop:

{"mcpServers":{"helium":{"command":"npx","args":["mcp-remote","https://heliumtrades.com/mcp"]}}}

No API key. Nothing to install. Free tier.

What it does

Helium exposes 10 tools through MCP:

1. Market Intelligence (`get_ticker`)

Ask "What's the outlook for NVDA?" and get:

AI-generated bull and bear cases
5 probability-weighted scenarios (e.g., 38% chance of mean-reversion, 25% upside on AI headlines, 10% tail risk on export shock)
Each scenario includes falsifiability criteria — what would prove it wrong

2. ML Options Pricing (`get_top_trading_strategies`)

The model computes independent fair values for every listed options contract. For each ticker, it returns:

Strategies ranked by expected value
Backtested win rates (e.g., short vol calls on AAPL: 61% win rate, avg +$8.40/trade over 39 historical trades)
Full Greeks for every contract

A single call returns ~355KB of structured data.

3. Balanced News Synthesis (`search_balanced_news`)

Aggregates 3.2M+ articles from 5,000+ sources. Instead of one take, it shows where sources agree vs. diverge on any topic.

4. Multi-Dimensional Bias Scoring (`get_all_source_biases`)

Scores news sources across 15+ dimensions — not just left/right:

Prescriptiveness: Does the outlet tell you what to think, or just report?
Sensationalism: Framing intensity
Fearful framing: How much fear-based language is used
Integrity: Factual rigor
Plus: dovish/hawkish, libertarian/authoritarian, and more

5. Historical Options Data (`get_historical_options_data`)

Full historical chains with ML pricing baked in. A single SPY request returns ~30MB of every contract with the model's theoretical value.

Why MCP matters for this

The key insight is that MCP eliminates the build step. Instead of building a custom financial app, you add one config line and ask questions in natural language. The AI handles parsing 355KB of structured options data and pulling out what's relevant.

This pattern — domain-specific intelligence delivered through MCP — is how I think a lot of specialized AI tools will work going forward.

Links

Happy to answer questions about the implementation or the MCP protocol in general.

Search Scientific Papers from Any AI Tool — Introducing BGPT MCP

connerlambden — Tue, 17 Feb 2026 04:50:13 +0000

If you work with scientific literature — whether you're a researcher, bioinformatician, or building AI-powered tools — you know the pain of searching for papers programmatically. PubMed's API is clunky. Semantic Scholar doesn't give you experimental details. And scraping is fragile.

BGPT MCP solves this by giving any AI tool direct access to a curated database of scientific papers, complete with raw experimental data extracted from full-text studies.

What is MCP?

Model Context Protocol (MCP) is an open standard that lets AI assistants connect to external tools and data sources. Think of it as "USB-C for AI" — one protocol, many tools.

If you use Cursor, Claude Desktop, Cline, Windsurf, or any MCP-compatible client, you can connect to BGPT with a single line of config.

What Does BGPT MCP Do?

BGPT provides a search_papers tool that searches a curated database of scientific papers. Unlike typical search APIs, BGPT extracts raw experimental data from full-text papers. Each result includes:

Title, DOI, and authors
Methods — actual experimental procedures used
Results — quantitative findings extracted from the paper
Quality scores — automated assessment of study rigor
25+ metadata fields — journal, year, sample size, organism, and more

This is the kind of structured data that used to require hours of manual extraction.

Quick Start (2 minutes)

For Cursor IDE

Add this to your MCP settings:

{
  "mcpServers": {
    "bgpt": {
      "url": "https://bgpt.pro/mcp/sse"
    }
  }
}

That's it. No API keys needed for your first 50 searches.

For Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "bgpt": {
      "url": "https://bgpt.pro/mcp/sse"
    }
  }
}

For Any MCP Client

BGPT uses Server-Sent Events (SSE) transport. Point your client to:

https://bgpt.pro/mcp/sse

Example Queries

Once connected, just ask your AI assistant naturally:

"Search for papers on CRISPR gene editing efficiency in human cells"
"Find studies comparing immunotherapy response rates in melanoma"
"What papers exist on transformer models for protein structure prediction?"

The AI will call the search_papers tool and return structured results you can immediately work with.

Why This Matters

If you're building research tools, literature review pipelines, or AI agents that need scientific context, BGPT MCP gives you:

No infrastructure — it's a remote server, nothing to install
Structured data — not just abstracts, but methods and results
Quality scores — filter for rigorous studies automatically
Works everywhere — any MCP-compatible AI tool

Pricing

50 free searches per network (no account needed)
$0.01 per result after that with an API key

Get your API key at bgpt.pro/mcp.

DEV Community: connerlambden

A 260-line vanilla-JS dashboard for ML stock forecasts (one CORS-open MCP endpoint, zero dependencies)

The endpoint

The whole render path

The uncertainty cone in 18 lines of SVG

Why no chart library?

The bull/bear narratives are HTML

Failure handling

Companion explorer

Why this matters for the MCP ecosystem

Links

Fear-coding in 160 news sources correlates +0.85 with political extremism — and only -0.08 with political direction

The data

The analysis

The top-15 most-fear-coded sources, with political context

So what?

A secondary finding while I was there: "written by AI" coverage

Replicate it yourself

Closing thought

How to Brier-grade your own ML option-pricing forecasts in 40 lines of Python

What we are doing

The endpoint

The recipe

Grading the forecast after expiration

Why this is useful

Other recipes in the cookbook

If you want MCP instead of REST

Closing thought

I probed my own MCP server — here's what 7 live API calls actually return

Probe 1: NVDA ticker (/mcp_ticker/)

Probe 2: AAPL options ML pricing (get_option_price)

Probe 3: Top trading strategies (get_top_trading_strategies)

Probe 4: News bias on a source (get_source_bias)

Probe 5: All source biases at once (get_all_source_biases)

Probe 6: Balanced news synthesis (search_balanced_news)

Probe 7: One source's tagged bias on a real URL (get_bias_from_url)

MCP is quietly commoditizing data+model SaaS moats — the structural case

The thesis in one sentence

The class of product I mean

What MCP changes

A concrete example

What this implies for fintech-data and sentiment-API valuations

The counterargument

What to watch

TL;DR

MCP servers are just REST APIs in a polite wrapper - here's 5 lines of Python

The setup

Five lines of Python

Loading into pandas

Option fair values, also 5 lines

A small Streamlit app

Where this fits in your stack

Detecting AI-authored news at corpus scale from a single MCP call

The core dimension

Setup

Asking the question

Why 31 dimensions, not one

Example use cases

Live example

What to do

31 dimensions of news bias, queryable from Claude in plain English

The problem

The schema

The corpus

The MCP interface

Setup (one line)

A real example

Use cases this unlocks

The bigger point

Caveats

Links

How I screen for ratio spread opportunities in 30 seconds with an MCP server

The setup

What the MCP exposes

Setup (one line)

Finding a ratio-spread candidate

The point isn't this specific trade

The bigger picture

Caveats

Links

Probe 1: NVDA ticker (`/mcp_ticker/`)

Probe 2: AAPL options ML pricing (`get_option_price`)

Probe 3: Top trading strategies (`get_top_trading_strategies`)

Probe 4: News bias on a source (`get_source_bias`)

Probe 5: All source biases at once (`get_all_source_biases`)

Probe 6: Balanced news synthesis (`search_balanced_news`)

Probe 7: One source's tagged bias on a real URL (`get_bias_from_url`)

1. Market Intelligence (`get_ticker`)

2. ML Options Pricing (`get_top_trading_strategies`)

3. Balanced News Synthesis (`search_balanced_news`)

4. Multi-Dimensional Bias Scoring (`get_all_source_biases`)

5. Historical Options Data (`get_historical_options_data`)