Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi

Price a same-game parlay at the book's own odds

propline_price_sgp
Read-onlyIdempotent

Hobby+ endpoint. Prices a same-game parlay at the BOOK'S OWN correlated odds — the price a FanDuel customer would be offered for that exact slip right now, not a model of it. bookmaker is fanduel (default, its own pricer) or betonlineag / lowvig (the Sportcast engine both share, same builder price). Send 2-10 legs from ONE event, each named exactly as propline_get_odds names an outcome: market key, name (team / Over / Under / player for YES-only props), description (the player on a two-way prop, '' for game lines), point (omit for h2h and YES-only props) and period (omit for full game) — or book_outcome_id from includeBookIds. The response carries sgp_price (the book's parlay price), independent_price (the product of the live single-leg prices) and correlation_factor = their ratio: below 1 the book is charging for correlation, above 1 it is paying for anti-correlation — say which when presenting it. Matching is fail-closed: a leg that does not pin to exactly one stored outcome is a 422 leg_unmatched naming the leg (an Over with no point on an event with two total lines is refused, not guessed) — fix the leg, do not retry blindly. quoted=false means the book will not offer that combination as an SGP; refused legs carry the book's own failure_code. Free tier returns the matched legs with every price nulled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
legsYesLegs named exactly as /odds names an outcome.
event_idYes
bookmakerNofanduel (default), betonlineag or lowvig.
sport_keyYese.g. baseball_mlb

Schema Changelog

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

  1. Changed1 schema field changed
    • changedInput schema / properties / bookmaker / description
      Previous value: -"Book to price at. Only fanduel today."New value: +"fanduel (default), betonlineag or lowvig."
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this as read-only, open-world, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond that: fail-closed matching, 422 leg_unmatched errors, quoted=false semantics, refusal failure codes, free-tier nulled prices, and how to interpret correlation_factor. No contradiction exists.

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

Conciseness5/5

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

The description is long, but the tool is complex and every clause carries necessary information: pricing semantics, parameter conventions, error behavior, response fields, and free-tier caveats. The core purpose statement is front-loaded, and the rest reads as a dense but efficient specification.

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?

With no output schema present, the description takes on the burden of explaining return semantics and does so thoroughly: sgp_price, independent_price, correlation_factor, quoted=false, and failure_code. It also covers edge cases like unmatched legs, Over without a point, and free-tier nulling, making the tool fully usable by an agent.

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

Parameters5/5

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

Schema coverage is 75%, but the description substantially enriches it. It explains bookmaker values, sport_key format, compact leg field semantics for name/description/point/period, omission rules, and the book_outcome_id alternative. This goes well beyond the schema's minimal property names.

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 opens with a specific verb and resource: 'Prices a same-game parlay at the BOOK'S OWN correlated odds', and immediately contrasts it with 'not a model of it'. This clearly states the tool's unique function and differentiates it from other odds-related siblings like propline_get_odds or propline_get_best_line.

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

Usage Guidelines4/5

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

The description gives clear usage context: 2-10 legs from ONE event, bookmaker choices, and leg-naming conventions from propline_get_odds. It does not explicitly state 'use this instead of X for single-leg pricing', but the SGP-specific wording and the detailed conditions make when-to-use evident.

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

All PropLine — Sports Betting Odds & Prop Resolution toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources