Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi
OverviewDiscussionsAdmin

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), draftkings (its SGP widget's pricer), betonlineag / lowvig (the Sportcast engine both share, same builder price), or 'all' to quote every book on the same legs in one call — then the response is {quotes, errors, best_bookmaker}, and best_bookmaker is the book charging the smallest correlation reduction (use 'all' whenever the user asks which book to bet an SGP at). 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), period (omit for full game) and team for a TEAM total (omit for the game total; a totals leg with no team matches the game total only) — or book_outcome_id from includeBookIds (on betonlineag / lowvig that is Sportcast's settlement id, e.g. MatchWinner_Home). 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), draftkings, betonlineag, lowvig, or all (every book side by side).
sport_keyYese.g. baseball_mlb

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / bookmaker / description
      Previous value: -"fanduel (default), betonlineag or lowvig."New value: +"fanduel (default), draftkings, betonlineag, lowvig, or all (every book side by side)."
  2. Changed1 schema field changed
    • addedInput schema / properties / legs / items / properties / team
      Added value: +{
+  "description": "For a TEAM total: the team as /odds serves it in the market's team field. Omit for the game total.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  3. 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."
  4. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds rich behavior beyond them: fail-closed matching (422 leg_unmatched, no guessing on ambiguous totals), quoted=false semantics with the book's own failure_code, free-tier behavior (matched legs with nulled prices), and the correlation_factor interpretation (below 1 = charging, above 1 = paying). No contradiction with the annotations exists.

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

Conciseness3/5

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

Every sentence earns its place and the purpose is front-loaded, but the entire description is one dense run-on paragraph with no bullets or breaks. For a tool this complex the length is justified, yet the wall-of-text structure forces an agent to parse a very long block to find leg-field rules and error semantics.

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 carries the full burden of return-value explanation and meets it: sgp_price, independent_price, correlation_factor, the {quotes, errors, best_bookmaker} shape for 'all', quoted=false, and the 422 leg_unmatched error. Leg construction, bookmaker routing, and edge cases are all covered, making the tool fully callable from the description alone.

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?

With 75% schema coverage, the description goes well beyond the schema. It explains bookmaker values in detail (fanduel default, draftkings's SGP widget, betonlineag/lowvig shared Sportcast engine) and gives exhaustive leg-field semantics: what 'name' carries per bet type, when 'point' and 'period' are omitted, how 'team' selects a TEAM total vs game total, and the book_outcome_id alternative. This fully compensates for any schema gaps.

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 names a specific verb-resource pair (price a same-game parlay) and immediately differentiates it from a modeled price by stressing the BOOK'S OWN correlated odds. It also names the sibling it builds on (propline_get_odds for leg naming) and its 'all' mode that returns best_bookmaker, making the tool's identity distinct from the 27 siblings.

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?

Provides explicit when-to-use guidance: 'use all whenever the user asks which book to bet an SGP at,' and clear operational instructions for failures ('fix the leg, do not retry blindly'). It references propline_get_odds for leg naming conventions, though it stops short of explicitly stating when NOT to use this tool in favor of a specific sibling for single-leg pricing.

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
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources