Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

Get odds

propline_get_odds
Read-onlyIdempotent

Get live odds. If event_id is supplied, returns full per-event props for that event; otherwise returns bulk game-line odds for the whole sport. Pass markets as a comma-separated list (e.g. 'h2h,spreads,totals' or 'player_points,player_rebounds'). Response includes a bookmakers[] array across every book that carries the requested markets (currently up to 27: Bovada, DraftKings, FanDuel, Pinnacle, BetMGM, BetRivers, Unibet, BetUS, BetOnline.ag, LowVig.ag, MyBookie.ag, Fanatics, Marathon Bet, 1xBet, TAB, Underdog Fantasy, PrizePicks, Sleeper, Dabble, Betr Picks, ReBet, Kalshi, Polymarket, Matchbook, Smarkets, Novig, ProphetX — coverage varies by sport). Underdog Fantasy outcomes carry a payout_multiplier on EVERY outcome (1.0 = standard pick, e.g. 1.5 = boost, 0.75 = discount; null means the book is not Underdog) — keep only payout_multiplier == 1.0 when comparing DFS lines to sportsbook consensus, since filtering on non-null would drop every Underdog line. Each market carries suspended_at: null while on the board, set when that book pulled the market pregame (late scratch, dropped market type) — its outcomes are then the last quoted legs, not a live price. Treat a suspended market as unbettable and, if several books show it for one player, as a probable scratch. Each BOOKMAKER carries pregame_only: true when the event is live and that book does not price it in play, so its prices are the last pregame quote and will never move again this game. suspended_at cannot show this — a book with no in-play feed is never polled once the game starts, so nothing goes missing to flag. Exclude pregame_only books when reasoning about a live game; they are still returned because on DFS books that frozen line is what the bet settles against. Each market also carries team: the canonical event team name when the market is scoped to ONE team (a TEAM total), and null for the game total. Both ride the totals key, so NEVER compare totals on (market key, point) alone — a team total at 0.5 is not a game total at 0.5. Filter team == null for the game total; team matches home_team/away_team exactly. Always null outside totals.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
periodNoGame-period filter. Omitted = full-game markets only. Canonical codes: q1..q4 (quarters), h1/h2 (halves), p1..p3 (hockey periods), i1..i9 (innings), f3/f5/f7 (first N innings). Comma-separated for multiple. 'all' = include every period alongside full-game.
marketsNoComma-separated market keys. Defaults to h2h on bulk; h2h,spreads,totals on event. Pass an explicit list to fetch player props (sport-specific — e.g. player_points,player_rebounds for NBA; pitcher_strikeouts,batter_home_runs for MLB).
event_idNoOptional. If set, returns props for this event.
sport_keyYes
bookmakersNoComma-separated subset of book keys (bovada, draftkings, fanduel, pinnacle, betmgm, betrivers, unibet, betus, betonlineag, lowvig, mybookieag, fanatics, marathon, onexbet, tab_au, underdog, prizepicks, sleeper, dabble, betr, rebet, kalshi, polymarket, matchbook, smarkets, novig, prophetx). Default returns all available.
include_linksNoWhen true, each bookmaker block carries a link — that book's public event-page URL for click-out (Bovada/DraftKings/FanDuel/BetMGM/Kalshi/Polymarket/Smarkets; others null). Plain navigation, no affiliate tagging. Also adds app_link — a mobile app-open deep link that opens the book's native app on the fixture (ProphetX only today, null elsewhere).
include_book_idsNoWhen true, each bookmaker block carries book_event_id and each outcome carries book_outcome_id — that book's OWN ids for the event and the priced selection, for joining onto a book's native feed by id instead of matching team/player names and lines. Kalshi ships both (event ticker + per-contract market ticker, e.g. KXMLBGAME-26AUG08NYYBOS-NYY); most other books ship an event id; books without a stable id return null. NB a two-sided market can share ONE book_outcome_id across both legs — a Kalshi contract is binary, so Over/Under are its YES/NO sides; the outcome's name says which side.

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / bookmakers / description
      Previous value: -"Comma-separated subset of book keys (bovada, draftkings, fanduel, pinnacle, betmgm, betrivers, unibet, underdog, prizepicks, kalshi, polymarket, matchbook, smarkets). Default returns all available."New value: +"Comma-separated subset of book keys (bovada, draftkings, fanduel, pinnacle, betmgm, betrivers, unibet, betus, betonlineag, lowvig, mybookieag, fanatics, marathon, onexbet, tab_au, underdog, prizepicks, sleeper, dabble, betr, rebet, kalshi, polymarket, matchbook, smarkets, novig, prophetx). Default returns all available."
  2. Changed1 schema field changed
    • changedInput schema / properties / include_links / description
      Previous value: -"When true, each bookmaker block carries a link — that book's public event-page URL for click-out (Bovada/DraftKings/FanDuel/BetMGM/Kalshi/Polymarket/Smarkets; others null). Plain navigation, no affiliate tagging."New value: +"When true, each bookmaker block carries a link — that book's public event-page URL for click-out (Bovada/DraftKings/FanDuel/BetMGM/Kalshi/Polymarket/Smarkets; others null). Plain navigation, no affiliate tagging. Also adds app_link — a mobile app-open deep link that opens the book's native app on the fixture (ProphetX only today, null elsewhere)."
  3. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations declare read-only/idempotent/non-destructive, and the description adds rich behavioral context on top: response shape (bookmakers[] across up to 27 books with sport-varying coverage), plus four critical data semantics — payout_multiplier (including the trap that 'filtering on non-null would drop every Underdog line'), suspended_at as last-quoted legs/probable scratch, pregame_only as a frozen quote invisible to suspended_at, and the team/totals key-collision warning. No contradiction with annotations.

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?

Well front-loaded: core action and mode switch first, then response shape, then the data-interpretation warnings. However, it redundantly enumerates all 27 book names that the schema's bookmakers parameter already lists as keys, inflating the description by roughly 40 words. Every other sentence earns its place given the tool's complexity.

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

Completeness4/5

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

A 7-parameter tool with no output schema and 25 siblings, and the description covers the highest-risk interpretation areas exhaustively: identifying the true game total (team == null), treating suspended/pregame_only books as unbettable, and normalizing Underdog lines. Minor gaps remain — decimal price format, timestamps, and bulk-response ordering are unmentioned — but nothing that would cause a mis-invocation.

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?

Schema description coverage is 86%, so the schema carries most parameter meaning and the baseline is 3. The description adds the fallback behavior for omitted event_id (bulk game lines for the whole sport) and reinforces the comma-separated markets format with examples, but the bulk of parameter detail (period codes, book keys, include_links/include_book_ids semantics) lives in the schema — the description exceeds it only modestly.

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?

States a specific verb+resource ('Get live odds') and immediately disambiguates the two operational modes: full per-event props when event_id is supplied vs bulk game-line odds otherwise. The 'live' qualifier distinguishes it from siblings like propline_get_odds_closing and propline_get_odds_history, and the mode switch is stated in the first sentence.

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

Usage Guidelines3/5

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

Internal usage guidance is strong: the event_id-triggered mode selection is explicit, and the description gives practical data-handling rules (filter payout_multiplier == 1.0, exclude pregame_only books for live games, filter team == null for game totals). However, it never names sibling tools or states when to choose this over propline_get_odds_closing/history — tool-selection guidance exists only implicitly through the word 'live'.

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.1/5.0
Disambiguation3/5

The tools are mostly distinct by purpose, but several overlap in areas like odds retrieval (get_odds vs get_best_line vs get_event_ev) and historical data (get_odds_history vs get_odds_closing vs export_odds_history). Descriptions are detailed and clarify distinctions, but the close functional relationships (e.g., get_event_movement vs get_odds_history) may cause selection ambiguity for an agent.

Naming Consistency4/5

The naming pattern is largely consistent: propline_<verb>_<noun> with verbs like get, list, export. Most tools follow this structure (e.g., get_event_results, list_events, list_sports). Deviations include 'propline_export_odds_history' (export instead of get) and a few longer names like 'propline_get_mlb_grand_salami' and 'propline_get_nhl_daily_goals_total' that break the simple verb_noun pattern but are still readable. Overall, the naming is predictable with minor exceptions.

Tool Count4/5

With 23 tools for a sports betting odds and prop resolution server, the count is on the higher side but still within a reasonable range given the domain's complexity (odds, EV, movement, results, player trends, webhooks, exports). Each tool serves a distinct function, though some could be consolidated (e.g., grand salami and NHL daily totals could be one). Slightly heavy but not excessive.

Completeness4/5

The tool set covers the core lifecycle: discover sports and events (list_sports, list_events), retrieve odds and markets (get_odds, list_event_markets), analyze EV and lines (get_event_ev, get_best_line, get_event_movement), track results and player stats (get_event_results, get_event_stats, get_player_history, get_player_trends), and backfill via exports. Missing features include webhook management (deliberately omitted) and possibly batch operations, but the surface is comprehensive for the stated purpose.