Skip to main content
Glama

Lumify Sports Intelligence

list_forecasts

Read-onlyIdempotent

Daily board of forecasted wagers from Lumify's model — a prediction, not a beat-the-market claim (no OOS/independence gate; see list_ev for the gated main-line +EV claim). Player props (rate model) on MLB, NCAAF, NFL, NBA, NCAAB, NHL. Tennis main-line: moneyline (ranking Bradley-Terry) as bet_type ML_P1/ML_P2, game handicap as SPREAD_P1/SPREAD_P2, and total games as OVER/UNDER (a Normal-approx games model; soft-book game-unit lines only, never Pinnacle's set-unit total). Each wager has p_hit, conviction (|p_hit−0.5|×2×sufficiency×research), and posted books prices. Use list_ev to scan main lines by sharp-fair price gap; use this tool to scan high-probability forecasts. reliability is emerging on v0. 1 credit; empty slate is still 200. How + field catalog: https://lumify.ai/docs/forecasts Worked wager: https://lumify.ai/docs/understanding-odds#forecasts

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoUTC slate date YYYY-MM-DD. Defaults to today UTC.
limitNoMax wagers (1–100). Default 25.
sportYesSport slug: mlb, ncaaf, nfl, nba, ncaab, nhl, or tennis.
marketNoMain-line family filter (h2h, spreads, or totals). Tennis publishes all three (moneyline, game-handicap, total-games). Ignored on prop-only sports.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNoUTC slate date (YYYY-MM-DD).
sportNoSport slug this slate was scored for.
totalNoCount of wagers on this page.
wagersNoSelected forecasted wagers, highest conviction first. Read p_hit as P(the picked outcome — side on prop rows, bet_type on main-line rows — hits); conviction is the board rank. How + field catalog: https://lumify.ai/docs/forecasts
reliabilityNoDefault badge on this slate. v0 ships emerging; each wager repeats the same field.
model_versionNoScorer version (forecast-v0).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / properties / wagers / items / properties / market / description
      Previous value: -"Player-prop rows: Owls prop category (1:1 counting stats). MLB: strikeouts_pitcher, hits, rbis, runs, strikeouts_batter, hits_allowed, earned_runs, outs_recorded. NFL/NCAAF: passing/rushing/receiving_yards, receptions. NBA/NCAAB: points, rebounds, assists, steals, blocks, threes_made. NHL: goals, hockey_assists, shots_on_goal. Main-line rows (bet_type set): the main-line family — h2h, spreads, or totals."New value: +"Player-prop rows: prop category (1:1 counting stats). MLB: strikeouts_pitcher, hits, rbis, runs, strikeouts_batter, hits_allowed, earned_runs, outs_recorded. NFL/NCAAF: passing/rushing/receiving_yards, receptions. NBA/NCAAB: points, rebounds, assists, steals, blocks, threes_made. NHL: goals, hockey_assists, shots_on_goal. Main-line rows (bet_type set): the main-line family — h2h, spreads, or totals."
  2. Changed2 schema fields changed
    • changedInput schema / properties / market / description
      Previous value: -"Main-line family filter (h2h, spreads, or totals). Tennis publishes h2h only. Ignored on prop-only sports."New value: +"Main-line family filter (h2h, spreads, or totals). Tennis publishes all three (moneyline, game-handicap, total-games). Ignored on prop-only sports."
    • changedOutput schema / properties / wagers / items / properties / bet_type / description
      Previous value: -"Main-line token when this row is a main-line forecast — ML_P1/ML_P2/ML_HOME/ML_AWAY/ML_DRAW, SPREAD_P1/SPREAD_P2/SPREAD_HOME/SPREAD_AWAY, or OVER/UNDER (same vocabulary as get_intelligence bets[].bet_type and list_ev). Null on player-prop rows — that's the discriminator between the two row shapes. Tennis moneyline rows set ML_P1 / ML_P2."New value: +"Main-line token when this row is a main-line forecast — ML_P1/ML_P2/ML_HOME/ML_AWAY/ML_DRAW, SPREAD_P1/SPREAD_P2/SPREAD_HOME/SPREAD_AWAY, or OVER/UNDER (same vocabulary as get_intelligence bets[].bet_type and list_ev). Null on player-prop rows — that's the discriminator between the two row shapes. Tennis sets ML_P1/ML_P2 (moneyline), SPREAD_P1/SPREAD_P2 (game handicap), and OVER/UNDER (total games)."
  3. Changed3 schema fields changed
    • changedInput schema / properties / market / description
      Previous value: -"Main-line family filter (h2h, spreads, or totals) for a sport's main-line forecast rows, once one exists. No sport publishes main-line forecasts today, so this has no effect yet. Ignored on prop-only sports."New value: +"Main-line family filter (h2h, spreads, or totals). Tennis publishes h2h only. Ignored on prop-only sports."
    • changedInput schema / properties / sport / description
      Previous value: -"Sport slug: mlb, ncaaf, nfl, nba, ncaab, or nhl."New value: +"Sport slug: mlb, ncaaf, nfl, nba, ncaab, nhl, or tennis."
    • changedOutput schema / properties / wagers / items / properties / bet_type / description
      Previous value: -"Main-line token when this row is a main-line forecast — ML_P1/ML_P2/ML_HOME/ML_AWAY/ML_DRAW, SPREAD_P1/SPREAD_P2/SPREAD_HOME/SPREAD_AWAY, or OVER/UNDER (same vocabulary as get_intelligence bets[].bet_type and list_ev). Null on player-prop rows — that's the discriminator between the two row shapes. No sport ships a non-null bet_type here yet."New value: +"Main-line token when this row is a main-line forecast — ML_P1/ML_P2/ML_HOME/ML_AWAY/ML_DRAW, SPREAD_P1/SPREAD_P2/SPREAD_HOME/SPREAD_AWAY, or OVER/UNDER (same vocabulary as get_intelligence bets[].bet_type and list_ev). Null on player-prop rows — that's the discriminator between the two row shapes. Tennis moneyline rows set ML_P1 / ML_P2."
  4. Changed20 schema fields changed
    • addedInput schema / properties / market
      Added value: +{
      +  "description": "Main-line family filter (h2h, spreads, or totals) for a sport's main-line forecast rows, once one exists. No sport publishes main-line forecasts today, so this has no effect yet. Ignored on prop-only sports.",
      +  "enum": [
      +    "h2h",
      +    "spreads",
      +    "totals"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / properties / wagers / description
      Previous value: -"Selected forecasted wagers, highest conviction first. Read p_hit as P(side hits the posted line); conviction is the board rank. How + field catalog: https://lumify.ai/docs/forecasts"New value: +"Selected forecasted wagers, highest conviction first. Read p_hit as P(the picked outcome — side on prop rows, bet_type on main-line rows — hits); conviction is the board rank. How + field catalog: https://lumify.ai/docs/forecasts"
    • addedOutput schema / properties / wagers / items / properties / bet_type
      Added value: +{
      +  "description": "Main-line token when this row is a main-line forecast — ML_P1/ML_P2/ML_HOME/ML_AWAY/ML_DRAW, SPREAD_P1/SPREAD_P2/SPREAD_HOME/SPREAD_AWAY, or OVER/UNDER (same vocabulary as get_intelligence bets[].bet_type and list_ev). Null on player-prop rows — that's the discriminator between the two row shapes. No sport ships a non-null bet_type here yet.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / wagers / items / properties / books / description
      Previous value: -"American price for the chosen side, keyed by bookmaker slug (e.g. {draftkings: -453}). Posted market price for the side the model picked."New value: +"American price for the picked outcome, keyed by bookmaker slug (e.g. {draftkings: -453}). Posted market price for the side/bet_type the model picked."
    • changedOutput schema / properties / wagers / items / properties / drivers / description
      Previous value: -"Signed contributions that moved p_hit. Read input as the player's measured rate and effect as how far that rate lifts the chosen side versus a league-mean player."New value: +"Signed contributions that moved p_hit. Read input as the measured rate/rating behind the pick and effect as how far it lifts the chosen outcome versus a baseline."
    • changedOutput schema / properties / wagers / items / properties / drivers / items / properties / effect / description
      Previous value: -"Signed shift in p_hit versus a league-mean player on the same line. 0.0 on yardage markets."New value: +"Signed shift in p_hit versus a baseline case on the same line. 0.0 on yardage markets."
    • changedOutput schema / properties / wagers / items / properties / drivers / items / properties / id / description
      Previous value: -"e.g. player.l10_rate — the recent-form rate that fed Poisson."New value: +"Prop rows: typically player.l10_rate — the recent-form rate that fed Poisson. Main-line rows would use a different namespace once a main-line forecast model ships."
    • changedOutput schema / properties / wagers / items / properties / drivers / items / properties / input / description
      Previous value: -"Measured rate in counting-stat units per game after shrinkage."New value: +"Measured rate/rating behind this driver, in native units."
    • changedOutput schema / properties / wagers / items / properties / line / description
      Previous value: -"Posted Over/Under main line the model was scored against."New value: +"Posted line the model was scored against. Prop and totals main-line rows: Over/Under number. Spreads main-line rows: the spread number. Null on h2h/moneyline rows."
    • changedOutput schema / properties / wagers / items / properties / line / type
      Previous value: -"number"New value: +[
      +  "number",
      +  "null"
      +]
    • changedOutput schema / properties / wagers / items / properties / market / description
      Previous value: -"Owls prop category (1:1 counting stats). MLB: strikeouts_pitcher, hits, rbis, runs, strikeouts_batter, hits_allowed, earned_runs, outs_recorded. NFL/NCAAF: passing/rushing/receiving_yards, receptions. NBA/NCAAB: points, rebounds, assists, steals, blocks, threes_made. NHL: goals, hockey_assists, shots_on_goal."New value: +"Player-prop rows: Owls prop category (1:1 counting stats). MLB: strikeouts_pitcher, hits, rbis, runs, strikeouts_batter, hits_allowed, earned_runs, outs_recorded. NFL/NCAAF: passing/rushing/receiving_yards, receptions. NBA/NCAAB: points, rebounds, assists, steals, blocks, threes_made. NHL: goals, hockey_assists, shots_on_goal. Main-line rows (bet_type set): the main-line family — h2h, spreads, or totals."
    • changedOutput schema / properties / wagers / items / properties / p_hit / description
      Previous value: -"Model probability (0–1) that side hits line, from the player's shrunken counting-stat rate (Poisson vs the posted Over/Under). Optional research may nudge this by at most ±0.03; the side stays."New value: +"Model probability (0–1) that the picked outcome (side on prop rows, bet_type on main-line rows) hits. Prop rows: built from the player's shrunken counting-stat rate (Poisson vs the posted Over/Under). Optional research may nudge a prop's p_hit by at most ±0.03; the chosen side stays the same."
    • changedOutput schema / properties / wagers / items / properties / player / description
      Previous value: -"Player display name from the priced line."New value: +"Player display name from the priced line. Null on main-line rows with no player attribution (bet_type is a match-level token like OVER/UNDER/ML_DRAW)."
    • changedOutput schema / properties / wagers / items / properties / player / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
    • changedOutput schema / properties / wagers / items / properties / player_id / description
      Previous value: -"Lumify player ID. Bound by exact / Jr-stripped name match."New value: +"Lumify player ID. Bound by exact / Jr-stripped name match. Null on main-line rows with no player attribution."
    • changedOutput schema / properties / wagers / items / properties / player_id / type
      Previous value: -"integer"New value: +[
      +  "integer",
      +  "null"
      +]
    • addedOutput schema / properties / wagers / items / properties / player_role
      Added value: +{
      +  "description": "'home'/'away' for team sports or 'p1'/'p2' for head-to-head sports, set only alongside a non-null bet_type. Null for player-prop rows and for match-level main-line tokens (OVER, UNDER, ML_DRAW).",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / wagers / items / properties / research / description
      Previous value: -"Optional Deep Research overlay: {stance, conviction, note}. stance is validate / neutral / invalidate. Validate nudges p_hit up by at most 0.03 and lifts conviction; invalidate does the reverse. The chosen side stays. Null means read p_hit from the rate model alone."New value: +"Optional Deep Research overlay on high-probability wagers (p_hit ≥ 0.80): {stance, conviction, note}. stance is validate / neutral / invalidate. note is the wager-level why. Validate / invalidate rows always carry a note. Validate nudges p_hit up by at most 0.03 and lifts conviction; invalidate does the reverse. The chosen side stays. Null means read p_hit from the rate model alone."
    • changedOutput schema / properties / wagers / items / properties / side / description
      Previous value: -"'over' or 'under' — the more likely side given the player's shrunken rate versus line."New value: +"Prop rows: 'over' or 'under' — the more likely side given the player's shrunken rate versus line. Null on main-line rows — read the picked outcome from bet_type instead."
    • changedOutput schema / properties / wagers / items / properties / side / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
  5. Added

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it read-only and idempotent, but the description adds meaningful behavioral context: this is a prediction model not a beat-the-market claim, reliability is emerging, credit cost is disclosed, and the 'empty slate is still 200' quirk is noted. All this goes beyond the annotation hints and clarifies expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but each sentence earns its place: the core differentiation is front-loaded, sport-specific caveats are grouped, and supporting links are at the end. Slightly long, but no wasted words given the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Considering the tool's complexity (multi-sport, multiple models, market nuances), the description covers the essential context: what the forecast represents, field semantics (p_hit, conviction), limitations (no OOS gate, soft-book lines), and pointers for further details. An output schema exists, so return values don't need elaboration here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% description coverage for all four parameters, including enums and defaults. The description adds supplemental context for sport and market (e.g., tennis's three market families), but it does not redefine parameter semantics beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific purpose: 'Daily board of forecasted wagers from Lumify's model' and explicitly contrasts with list_ev ('use this tool to scan high-probability forecasts'). It clearly identifies the resource and what makes it distinct from the sibling tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Direct guidance is given: 'Use list_ev to scan main lines by sharp-fair price gap; use this tool to scan high-probability forecasts.' It also clarifies scope across sports and market types, including caveats like tennis-specific behavior, leaving no ambiguity about when to invoke this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool maps to a distinct data resource or operation: events, live scores, odds, odds history, splits, stats, intelligence, player props, players, teams, sports, and seasons. Pairs like list_events vs query_events and get_event vs get_live_score are clearly differentiated by structured vs natural-language filtering and lightweight vs full detail.

Naming Consistency5/5

Tool names consistently follow a verb_noun snake_case pattern: get_*, list_*, search_*, query_*, batch_get_*, and estimate_cost. The naming conventions make the resource family immediately obvious, and deviations like batch_get_events are still predictable variants.

Tool Count4/5

19 tools is on the higher side, but each tool covers a specific sports-intelligence data product or workflow with little redundancy. The count feels intentional for the breadth of the domain rather than bloated.

Completeness4/5

The surface covers event discovery and retrieval, live scores, odds and line movement, splits, statistics, player props, intelligence, player/team/sport/season lookups, batch fetching, and cost estimation. Minor gaps like team standings or full rosters are not exposed, but core agent workflows are well supported.