SSB MCP ── Sharp Money Intelligence for AI Agents

SSB MCP is a Model Context Protocol server that lets AI agents see what the sharpest sportsbooks are doing. Its current registry covers 39 screen feeds across 12 league configs, detects coordinated sharp movement, surfaces steam moves and line lags, and explains the consensus — so you can decide what to bet, not be told.

Connect it to Claude Desktop, Cursor, Cline, Hermes, or any MCP client. Requires a PropProfessor account — the free tier is enough; no paid subscription needed.

Honest scope — measured, not merely unproven: SSB MCP is a sharp-signal DISCOVERY and RATING tool. tier / kaiCall / edge / screenScore are signal-quality ratings, not win-probability predictions. A settled-results backtest now exists and it does NOT support an edge. Across 186 measured closing lines the ranking beat the close 20.4% of the time (95% CI 15.3–26.8%) with a mean CLV of -0.94%, and its own top confidence tier performed worst. The read got worse as the sample grew — the signature of an artifact, not an edge. Use it to see what sharp books are doing; do not treat outputs as a winning system. docs/STATUS.md carries the full measurement, what was ruled out first, and the two lanes that ARE supported (promotions and cross-venue arbitrage — neither of which is prediction). The ranking pipeline surfaces what sharp books are doing; the betting decision stays with you.

What this project demonstrates

• Agent integration — a 31-tool MCP surface with natural-language routing and structured responses

• Data pipelines — live odds extraction, line-history hydration, consensus scoring, and market-specific ranking

• Operational reliability — auth recovery, circuit breakers, caching, validation, and deterministic install checks

• Honest evaluation — synthetic validation is separated from real settled-results backtesting; unsupported win-rate claims are deliberately avoided

Related MCP server: pmcp

🚀 Overview

Your AI agent gets 31 tools that surface the same signal feed professional bettors use:

• Screen & rank — query the current 39-feed screen registry, ranked by consensus edge and movement

• Detect sharp coordination — Pinnacle, Circa, BookMaker, and BetOnline moving together? That's a signal

• Explain the "why" — every play comes with a human-readable rationale: what moved, on which books, over what timeframe

• Natural language routing — agents call ask("best plays on Fliff tonight") and get routed to the right tool automatically

The pipeline extracts odds, hydrates line history, ranks by movement quality + consensus strength, assigns a tier and risk score, and returns everything your agent needs to present an informed recommendation. The betting decision stays with the human.

⚡ Quickstart (30 seconds)

1. Clone and install: git clone https://github.com/jbdrak/ssb-for-agents.git && cd ssb-for-agents && npm ci && npm link

2. Wire your MCP client — pick your client below:

   Claude Desktop (claude_desktop_config.json):

   {
     "mcpServers": {
       "ssb": {
         "command": "pp",
         "args": ["--mcp"]
       }
     }
   }

   Cline (cline_mcp_settings.json):

   {
     "mcpServers": {
       "ssb": {
         "command": "pp",
         "args": ["--mcp"],
         "env": {}
       }
     }
   }

   Cursor — Settings → Features → MCP Servers → Add:

   Name: ssb
   Type: command
   Command: pp --mcp

   Continue.dev (~/.continue/config.json):

   {
     "experimental": {
       "mcpServers": {
         "ssb": {
           "command": "pp",
           "args": ["--mcp"]
         }
       }
     }
   }

   Hermes (~/.hermes/config.yaml):

   mcp_servers:
     ssb:
       command: pp
       args: [--mcp]

3. Auth (one-time): node scripts/pp-login.js — opens a browser for PropProfessor login and persists cookies for the server to use.

4. Ask your agent: "What are tonight's sharpest plays on Fliff?"

That's it — your agent now sees 31 tools.

Verify your install: npm run install:verify runs the credential-free install verification suite.

⬆️ Upgrading from propprofessor-mcp

The project was renamed in 2.10.0. The old GitHub URL redirects, and nothing changed behaviorally — but a few consumer-visible identifiers moved. If you installed from source before the rename:

mv ~/.propprofessor ~/.ssb-for-agents   # move your auth/state (or just re-run `pp-query login`)

• State directory: ~/.propprofessor → ~/.ssb-for-agents. A mv preserves permissions; re-running pp-query login is the alternative.

• Environment variables: PROPPROFESSOR_* → SSB_*. The PP_* variables are unchanged.

• Module paths (deep imports only): lib/propprofessor-*.js → lib/ssb-*.js.

• Binaries: ssb, ssb-mcp, ssb-query, and ssb-backtest are the canonical names. The pp, pp-mcp, pp-query, and pp-backtest names still work and are unchanged.

• Deliberately unchanged: the upstream API hosts (app. / backend. / screen. / slipgen.propprofessor.com) and the pp / PP_* CLI and env names.

See CHANGELOG.md for the full breaking-change list.

CLI — ssb (alias pp)

SSB ships with a fast, standalone CLI that calls handlers directly — no MCP server needed.

git clone https://github.com/jbdrak/ssb-for-agents.git
cd ssb-for-agents
npm ci
npm link
ssb scan mlb tennis -M supportive -n3

Run ssb --help for the live list. Every ssb command also answers to its pp alias.

Companion binaries (each with a pp- alias): ssb-mcp (MCP stdio server), ssb-query init / login / doctor (setup + auth), ssb-backtest.

MCP mode: ssb --mcp runs as an MCP stdio server. Connect it to Claude Desktop, Cursor, Cline, or any MCP client. Pass --mode full for the full 31-tool surface.

Quick start (from a clone): after npm link, run ssb --mcp to start the MCP server. No global package download is required. Development/clone setup: use the full path — node /path/to/scripts/ssb-mcp-server.js — see MCP Client Setup below.

All commands support -j/--json for piping and --no-color for CI/Telegram output.

Example output (scan filtered by supportive movement):

MLB › Moneyline  (2)
  Houston Astros @ +127  |  TIER 1  ● BET
    1.9%  ·  clv +4¢  ·  mv supportive_bouncy  ·  5 books
    Chicago White Sox vs Houston Astros  Fri, Jul 24, 6:40 PM

Tennis › Total Games  (1)
  Under 21.5 @ -104  |  TIER 1  ● BET
    3.4%  ·  mv supportive_clean  ·  16 books
    Avanesyan vs Oliynykova  Fri, Jul 24, 7:00 AM

📊 Backtesting

SSB includes a backtest runner that prints settled-pick performance across any date range.

# Show last 30 days of settled picks
node scripts/backtest-runner.js --days 30

# Show a specific date range
node scripts/backtest-runner.js --from 2026-06-01 --to 2026-07-20

# Or use the installed binary
pp-backtest --days 30

The runner reads from ~/.ssb-for-agents/picks.json — the same file used by pp log and pp picks. It shows total picks, settled records, win rate, P&L, and breakdowns by tier and league. It never fabricates ROI. If no settled picks exist in the range, it says so honestly.

📒 Record Keeping — legacy tracker migration

The local record ledger (PP_RECORD_LEDGER, default ~/.ssb-for-agents/tracker/ledger.json) is the v2 source of truth for official bets. To import the old Python tracker's settled bets (~/.ssb-for-agents/tracker/bets.json) into the v2 ledger:

# Preview what would be imported (dry-run is the default — writes nothing)
node scripts/migrate-tracker.js

# Machine-readable preview
node scripts/migrate-tracker.js --json

# Actually migrate (backs up the destination ledger first)
node scripts/migrate-tracker.js --apply

Safety properties:

• Dry-run by default — --apply is required to write anything; --dry-run is explicit and conflicts with --apply.

• bets.json is never overwritten — it is read-only input, and the script refuses to run when the source and ledger paths resolve to the same file.

• Timestamped backup — before --apply writes, the existing destination ledger is copied to ledger.json.bak-<timestamp> (no backup is needed on first migration).

• Idempotent — legacy IDs are preserved, so re-running never double-counts.

• No guessed dates — legacy records carry no event date (only loggedAt/settledAt), so migrated bets get eventDate: "unknown" and can never appear in strict date-filtered reviews. The complete original record is preserved verbatim in each bet's legacy metadata, along with the legacy id, status, and P&L (plUnits).

Active workflow — record, review, settle

The day-to-day recordkeeping loop is manual and local-only; nothing polls SSB in the background:

# 1. Record the scan — snapshots the scan + normalized candidates into the ledger
pp scan --record-scan

# 2. Promote reviewed decision cards (BET → official bet; LEAN/PASS update the candidate only)
pp record-card card.json
pp record-card --json '<payload>'          # inline card JSON (single card or array)

# 3. Review the ledger (local, read-only)
pp record stats    --date 2026-08-04 --json
pp record review   --date 2026-08-04
pp record pending  --date 2026-08-04

# 4. Capture the CLOSING price for candidates near their start (bounded, single pass)
node scripts/capture-close.js --live --window 30        # or: npm run capture:close -- --live
node scripts/capture-close.js --prices closes.json      # deterministic path, no network
node scripts/capture-close.js --audit                   # report record usability, capture nothing

# 5. Fetch real result data and settle the official bets against it
node scripts/fetch-results.js --date 2026-09-17 --leagues MLB,WNBA --out results.json
python3 scripts/flashscore-results.py --days 1 --out fs.json   # tennis (same-day only)
node scripts/fetch-results.js --date 2026-09-17 --flashscore fs.json --out tennis.json
node scripts/settle-record.js --results results.json --date 2026-09-17 --dry-run

# 6. Evaluate — hit rate with a confidence interval, ROI, and beat-the-close
npm run evaluate                       # or: node scripts/evaluate.js --json

Evaluating a record, and what "no result" looks like

npm run evaluate answers two questions separately and refuses to blur them:

• Did we win? Hit rate with a 95% Wilson interval, stake-weighted ROI, split by tier / market / league / price bucket. Every bucket prints its sample size, and a bucket under 30 decided outcomes is flagged insufficientSample rather than shown as a result.

• Did we beat the close? Measured over recorded CANDIDATES, not just bets, so it uses the whole scan. This is the leading indicator: it needs far fewer observations than win rate before it means anything.

Two things it will not do. It never reports a 0 mean CLV when no close has been captured — it reports unmeasured, because "we never looked" and "we broke even against the close" are different claims. And it never counts a row whose price is a probability display string ('49.0%') into ROI; those are counted separately as unpricedRows. On an empty ledger it says insufficient sample for everything instead of printing zeros that read like results.

The card gate

pp card now applies a price test and a volume cap (--max-bets, default 2; --min-ev, default 2%; --min-margin, default 2 percentage points; --no-gate to disable). A row is only a BET if the price returns positive EV against the decision-time de-vigged fair probability and that EV rests on a real absolute margin, or it beats the sharp consensus edge by the same margin. A row with neither has no price evidence and becomes a LEAN. Anything from a bucket with fewer than 30 decided bets is labelled UNPROVEN, and No plays on today's <league> card — all N BET(s) failed the price gate is a legitimate, expected output.

The reason is arithmetic: a -135 price needs 57.1% to break even, and the repo's own docs score the tier that produced most of these plays at ~50-54% on outcomes. Movement alone is a hypothesis, not a price argument — the close is what tests it.

Why the EV floor alone was not enough. An EV-only test manufactures longshot value. On the first real slate it ran against (2026-09-17) it passed 5 rows out of 122, and every one was a plus-money longshot whose whole edge was 0.5-1.1 percentage points of fair probability — inside the noise of a de-vig averaged across books, because a longshot price is quoted coarsely. A small absolute error in the fair probability is a large relative error in EV as the price lengthens, so the gate now also requires an absolute fair-probability margin, and reports margin_too_thin separately from ev_below_floor. At -110 a 2pp margin is about +3.8% EV; at +545 it is about +13% EV. Re-run on the same slate the honest answer was 0 of 122.

The close is not the decision price

The ledger records a candidate's odds at DECISION time — the price when the scan ran. Closing line value is a comparison against the CLOSE, and capture-close.js is the only producer of one; before it existed there was no close anywhere in the repo, so every printed "CLV" was an open-to-current move rather than a close-relative number. Two things about the close record are deliberate:

• closeIsPrice is the load-bearing field. For a NoVig-family book the structured odds field in the scan payload is a display string ('49.0%'), not a price — lib/ssb-formatter.js overwrites it via oddsValueForDisplay. A close that arrives in that shape is stored as closeImpliedProbability with closeIsPrice: false and closeOdds: null. It is never converted into an American price, because turning a one-sided implied probability into a price means inventing a de-vig.

• closeKind is 'pregame' or 'post_start'. A quote taken inside the post-start grace window is not a close, so it is labelled rather than silently treated as one.

• A candidateId is never recomputed. It is the decision-time identity pp record-card joins on; rehashing a row after adding a close would orphan every bet linked to it.

• --audit reports, and never repairs. It counts unusable rows by reason (probability_not_price, missing_game_id, missing_start, missing_fair_probability, missing_capture_time) so the gaps are visible instead of assumed absent.

Key properties:

• --record-scan is manual only — it records whenever you run pp scan --record-scan. Scan capture is deliberately low-frequency (a few times a day) and is never a poller: the historical account loss came from polling the scan endpoint every 10 minutes. Any timer lives in a shim outside this repo, because test/manual-only-gates.test.js forbids a tracked scripts/* executable that touches live SSB from carrying its own timing.

• Only BET promotes — pp record-card turns explicit BET cards into official bet records; LEAN/PASS update the candidate without creating a bet. Re-importing an already-recorded card is a no-op (idempotent).

• pp record is local and read-only — stats, review, and pending modes read the ledger with no network and no writes; --date filters by the America/Chicago calendar day of scheduled start, --json emits machine-readable output.

• Settlement never calls SSB — scripts/settle-record.js (and lib/record-settlement) contain no network code. You fetch results yourself (e.g. an ESPN scoreboard dump) and hand them over as a local JSON file; the script matches bets to final scores, computes P&L, and writes the ledger atomically. --dry-run reports without writing anything; --force re-settles bets that already have a settled status.

• Results file provenance is required — the results file must be an object with non-empty top-level provider and sourceUrl plus an events array; bare event arrays are no longer accepted. A same-ID event never settles on its ID alone: it must also match the bet's participants and fall inside the scheduled date window, and event-specific source URLs are kept only when the top-level provenance is valid. Missing provenance is a CLI usage error (the ledger is never touched), and library callers receive pending records with a precise reason instead of a settlement.

• PP_RECORD_LEDGER overrides the ledger path — every command above reads/writes $PP_RECORD_LEDGER when set, otherwise the default ~/.ssb-for-agents/tracker/ledger.json.

Offline record → settle → evaluate example

Run the complete lifecycle without credentials, network calls, or user-file writes:

node examples/record-settle-evaluate.js

The synthetic fixture records an immutable probability snapshot, promotes a reviewed card, settles it from supplied result data, and derives calibration from the v2 ledger. Its one-bet report is explicitly marked insufficient for accuracy or uplift claims. See Project status and evaluation roadmap for shipped capabilities and hard limits.

🏛 Architecture

SSB MCP follows a layered data pipeline:

API Layer

• SSB Backend — authenticated REST API for live odds, line history, and fantasy data

• ESPN Integration — live scores for tennis time correction and game verification

• X / Google News — player context (injury news, tweets) for bet validation

Ranking Pipeline (Node.js)

• Extract — parse raw odds payloads from the screen API, expand multi-book selections

• Hydrate — use SharpOdds as the primary movement-history source, with the authenticated PP history path as a fail-closed fallback; cache board/history reads within the bounded request

• Rank — score by consensus edge (% advantage over sharp consensus), CLV proxy (opening vs current line movement), and league-specific market priorities

• Tier — assign TIER 1–4 based on movement grade (green/yellow/red) × risk score (1–10) × sharp book confirmation, with hysteresis to prevent thrashing

• Format — output at three verbosity levels: minimal (plain English), standard (tier/edge/risk/rationale), full (raw movement data)

MCP Server (stdio)

• JSON-RPC over stdio — standard MCP transport with Content-Length framing (NDJSON optional)

• 31 tools — organized into situational, analytical, and research tiers

• Server-side validation — enforces input schemas at the server, not trusting the client

• Categorized errors — auth, backend, transport, validation, internal — each with structured recovery hints

Data Flow

flowchart LR
    subgraph BOOKS["39 Screen Feeds"]
        B1[Pinnacle]
        B2[Circa]
        B3[BookMaker]
        B4[BetOnline]
        B5[NoVigApp]
        B6[Fliff]
        BN[...33 more]
    end

    API[PropProfessor API]

    subgraph PIPE["Ranking Pipeline"]
        E[Extract odds]
        H[Hydrate with line history]
        R[Rank by movement + consensus]
        T[Tier + risk score]
    end

    subgraph OUTPUT["31 MCP Tools"];
        QS[quick_screen]
        T[today]
        SB[smart_bet]
        VP[validate_play]
        ASK[ask]
        OTH[...25 more]
    end

    CLIENT[Your AI Agent<br/>Claude / Cursor / Cline / Hermes]

    BOOKS --> API --> PIPE --> OUTPUT --> CLIENT
    CLIENT -. "you decide what to bet" .- BOOKS

🛠 Getting Started

Quick Start

git clone https://github.com/jbdrak/ssb-for-agents.git
cd ssb-for-agents
npm install
npm link
pp-query init          # auth + verification + config — all at once

pp-query init checks Node version, opens PropProfessor login if needed, runs doctor, and prints ready-to-paste MCP config for your client. Or do it step by step:

pp-query login         # browser login
pp-query doctor        # verify everything works

Requires a PropProfessor account — the free tier is sufficient. That's it — you're ready to connect your AI agent.

MCP Client Setup

Add to your client's MCP config:

{
  "mcpServers": {
    "ssb": {
      "command": "node",
      "args": ["/path/to/ssb-for-agents/scripts/ssb-mcp-server.js"],
      "env": {
        "SSB_MCP_NDJSON": "true",
        "AUTH_FILE": "/path/to/.ssb-for-agents/auth.json"
      }
    }
  }
}

Replace /path/to/ with your actual install path (e.g. /Users/you/projects/ssb-for-agents). Supports Claude Desktop, Cursor, Cline, Zed, Continue.dev, Windsurf, and any other stdio-based MCP client. See each client's docs for where MCP config lives.

For short-lived one-off sessions:

Clone the repository, install dependencies, and point your client at the server script:

{ "command": "node", "args": ["/path/to/ssb-for-agents/scripts/ssb-mcp-server.js"] }

Requires a local clone and a free PropProfessor account.

For headless/CI environments (no Chrome):

Set the SSB_COOKIES env var with your PropProfessor cookies exported as JSON. This bypasses the CDP/Chrome auth path entirely:

{
  "mcpServers": {
    "ssb": {
      "command": "node",
      "args": ["/path/to/ssb-for-agents/scripts/ssb-mcp-server.js"],
      "env": {
        "SSB_COOKIES": "[{\"name\":\"__Secure-next-auth.session-token\",\"value\":\"...\",\"domain\":\".propprofessor.com\"}]"
      }
    }
  }
}

Auth refresh fallbacks (optional). When the server-to-server token fetch is gated by Vercel (HTTP 429), the server self-heals via a logged-in browser. Fallback order is got-scraping → ego-browser → CDP: the ego-browser fallback (named task space pp-token-refresh, created on first use, unless SSB_EGO_TASK_SPACE is set to a positive integer task-space id) is tried first; the CDP fallback runs only if ego-browser fails. The CDP endpoint defaults to http://127.0.0.1:9222/json/version; set SSB_CDP_VERSION_URL (e.g. http://127.0.0.1:9333/json/version) to use a different Chrome-for-Testing listener. Both fallbacks are on-demand only — no polling.

Hermes Agent

If you use Hermes Agent:

make install          # register MCP server + install default config

Or manually: add ssb to your mcp_servers in config.yaml. The get_started tool provides on-demand workflow guidance.

Sharp-money alerts

SSB is manual-only for decisions. There is no polling mode and no supported way to have automation place a bet — run quick_screen on demand when you want a fresh result. One bounded exception exists for measurement, authorized by the operator on 2026-09-17: a closing-price sweep every 30 minutes, a scan capture three times a day, and a public-only settle/evaluate digest. A closing price exists only in the minutes before a start, so without a scheduled sweep the record can never accumulate the closes that decide whether the card has an edge. Timers live in shims outside this repo.

🎯 The Natural Language Flow

ask is a query router — it parses natural language and returns a suggested tool + args, but it does NOT execute the tool. Your agent calls ask to figure out what to do, then makes the actual call:

You:  "Tell me the best plays on Fliff tonight"
Agent: ask({ query: "best plays on Fliff tonight" })
       → { parsed: { book: "Fliff" }, suggestedTool: "quick_screen", suggestedArgs: { books: ["Fliff"] } }
Agent: quick_screen({ books: ["Fliff"] })
       → [ranked plays with odds, edge, tier, risk, rationale — all on Fliff]

📊 Available Tools

Quick Situational Checks

get_market_registry returns main-line markets in the markets field and exact player/pitcher prop names in the propMarkets field. scan and quick_screen accept includeProps:true to merge those prop markets into a scan. Prop scans are manual-only because they increase backend fan-out and rate-limit risk.

Deeper Signal Analysis

Research & Bet Management

Output Tuning

Every tool accepts:

quick_screen additionally accepts:

Player research is ON by default in quick_screen (pass includeResearch: false to disable). It's scoped to the final returned plays and de-duplicated per game, so research always maps 1:1 to what you got back. On a huge unfiltered scan, lower researchLimit or use lite if the response nears the transport cap.

cardWindow honesty: when today is alive and next-day rows are merged, the response reports cardWindow: "today" (not tomorrow's date) plus nextDayMerged: true and nextDayDate. Earlier builds mislabeled this as tomorrow — that bug is fixed.

Tier consistency: as of 2.8.x, tierCache is cleared at the start of every MCP screen call (quick_screen, screen_ranked, validate_play). A given play's tier is therefore stable within a call and recomputed fresh per call — no cross-call drift from stale hysteresis state.

verbosity: minimal returns a plain-English summary string WITH a structured plays array — agents get both human-readable text and machine-parseable data in one call. Each play in the array includes league, market, game, selection, odds, confidenceTier, edge, startCST, movementDisposition, and screenScore.

Tool Surface Modes

Set SSB_MCP_MODE at server boot to control how many tools the agent sees on tools/list:

Lite mode exposes: ask, smart_bet, quick_screen, today, find_best_price, validate_play, get_play_details, player_context, log_pick, get_pick_history, resolve_pick, get_market_registry, place_bet, sharp_alerts, health_status.

The tools/list response always includes a _meta block so agents can tell which mode is active:

{
  "tools": [...],
  "_meta": { "mode": "full", "toolCount": 31, "liteToolCount": 15, "fullToolCount": 31 }
}

Tool Categories

Every tool carries a category field that groups it by purpose — agents can use this to mentally cluster the surface rather than reading 29 individual descriptions:

Canonical vs Deprecated Param Names

A handful of params accept both a clean canonical name and a legacy alias — every existing call site keeps working, and new code can use the cleaner names:

Deprecated aliases are documented in each schema's description field and are normalized to the canonical key at dispatch time. No code change required for existing callers.

🧪 How the Ranking Works

The pipeline grades every play in 5 steps:

1. Movement grade — green (all sharp books aligned), yellow (some signals, some not), red (adverse)

2. Risk score (1–10) — weighted from movement quality, consensus count, CLV strength, execution quality, and freshness

3. Tier assignment — lookup table: green + low risk → TIER 1, green-yellow + moderate → TIER 2, yellow → TIER 3, red → TIER 4

4. Hysteresis — a play doesn't thrash between TIER 1 and TIER 3 on small odds changes; tier trajectory is smoothed

5. Sharp cross-reference — verifies target-book moves independently against non-target sharp books

Tier system:

Full methodology, weight tables, and the tier assignment lookup in docs/METHODOLOGY.md. Backtesting results in docs/BACKTESTING.md.

🔌 Integrations

See Quick Start for Hermes Agent setup. The MCP is self-documenting — agents call get_started to discover the right workflow.

Discord / Telegram Alerts

The Positive EV Command Center is a companion project that monitors SSB for high-EV slips and plays, then pushes them to Discord and Telegram in real-time. It uses the same auth session and API client.

pp-query CLI

pp-query is a standalone CLI for one-off queries without an MCP client. Soccer is queried from the generic Soccer backend feed; named competitions are filtered by their leagueName (the same model used by the frontend):

pp-query screen --league NBA --market Moneyline
pp-query screen --league EPL --market "Total Goals"
pp-query screen --league Soccer --league-name EPL --market "Total Goals"
pp-query sharp-plays --leagues NBA,MLB --market Moneyline
pp-query login
pp-query doctor

📈 Validation methodology

TL;DR: The infrastructure is in place. Real outcome data hasn't accumulated yet.

Two paths to validate the signal:

1. Synthetic engine validation — runs generated scenarios (sharp_move, stable_no_edge, adverse) through the full pipeline to confirm the tier system actually differentiates quality:

node scripts/backtest-synthetic.js

2. Real outcome backtest — snapshot-based, since the PropProfessor API does not serve historical settled results. Take a pre-game odds snapshot daily, then resolve outcomes as games settle:

# capture today's recommended plays
node scripts/daily-snapshot.js
# after games settle, apply win/loss/push via CSV
node scripts/resolve-outcomes.js --csv results.csv
# compute P&L, ROI, Sharpe, max drawdown from resolved data
node scripts/backtest.js --metrics data/snapshots.jsonl

The pipeline (daily-snapshot.js → settle games → resolve-outcomes.js → backtest.js --metrics) is built and tested (full deterministic pipeline suite passes). What's missing: real settled-results data. The synthetic tier-validation run shows a TIER 1 hit rate of 53.7% over N=873 simulated samples — these validate the ranking engine, they do NOT prove profitability.

Honesty: tier/kaiCall/edge/screenScore are signal-quality ratings, not win-probability predictions. Profitability is UNPROVEN — no settled-results backtest has been published yet. The system surfaces what sharp books are doing; it doesn't come with a bundled historical results feed. Don't trust a win rate you can't trace to settled bets. See docs/BACKTESTING.md.

🔧 Troubleshooting

Still stuck? Run pp-query doctor and open an issue with the output.

❓ FAQ

Does this tell me what to bet? No. It surfaces what sharp books are doing. The betting decision is yours.

Do I need a PropProfessor account? Yes, and the free account is enough. Live data works on the free tier at propprofessor.com — no paid subscription required.

What books does it cover? The code currently registers 39 screen feeds across 12 league configs. Some entries are alternate or specialized feeds rather than distinct sportsbooks. Sharp cross-reference: Pinnacle, Circa, BookMaker, BetOnline.

Is it free? Code is MIT-licensed, and a free PropProfessor account covers the data. There is no paid tier of the MCP itself.

Can I run it without an MCP client? Yes — pp doctor is a standalone CLI.

What if I find a bug? Run pp doctor first, then open an issue.

⭐ Support

This is free, MIT-licensed software. If it saves you time or makes you money:

• ⭐ Star the repo — helps others find it

• 🐛 Open an issue when you find a bug

• 💸 Sponsor on GitHub — funds ongoing development

No paid tier. No upsell. The whole codebase is open and the priority is making it better for the people who use it.

🔧 For Maintainers

npm test              # full deterministic suite passes (no exact count — see check:claims)
npm run test:coverage # ~82% statements
npm run lint          # clean
npm run format:check  # clean (npm run format to fix)
npm run check:version # verifies package.json ↔ CHANGELOG

Release: push a v* tag → CI runs lint + tests on Node 20 + 22 → publishes to npm → creates the GitHub release.

📚 Docs Index

📝 License

MIT. PropProfessor offers a free tier; this MCP is an unofficial client built by James Drake, not affiliated with PropProfessor.