Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi
OverviewDiscussionsAdmin

Grade bets against the close (CLV)

propline_grade_clv
Read-onlyIdempotent

Hobby+ endpoint. Grades PLACED bets against their closing lines. Closing line value is the only durable proxy for whether a bettor has edge: did the price they took beat the number the market settled on? Send the bets and each comes back with its closing price, the de-vigged closing fair probability, CLV, and — once the game settles — the graded resolution and actual stat value, plus a portfolio summary. Stateless: nothing is stored. TWO CLV numbers are returned deliberately. clv_pct is price-vs-price: familiar and quotable, but VIG-BLIND, so it flatters a bet taken on the juicy side of a wide market. ev_vs_close_pct scores the price against the DE-VIGGED close and is the honest one — report that one when the user asks whether they got value. The de-vig anchors to the SHARPEST book quoting that line at close (fair_source), not the book they bet at, because de-vigging their own book always returns a negative number (they paid its hold). Bets whose event has not started carry closing_is_final=false, are counted in summary.pending, and are EXCLUDED from the summary averages: before kickoff the 'closing' price is just the latest price, so CLV is ~0 by construction — do not present those as results. Matching is fail-closed: a bet that cannot be pinned to exactly one stored outcome returns matched=false with an unmatched_reason instead of a wrong match, so surface those rows rather than silently dropping them. Max 500 bets per request. Free tier returns structure with every number nulled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
betsYesPlaced bets to grade. selection is the subject: player name for a prop, team name for a game line.
devigNoHow the closing anchor's vig is removed before closing_fair_prob / ev_vs_close_pct. 'multiplicative' (default) or 'shin' (loads the overround onto the longshot). Same vocabulary as propline_get_event_ev; echoed as devig_method.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / devig
      Added value: +{
+  "description": "How the closing anchor's vig is removed before closing_fair_prob / ev_vs_close_pct. 'multiplicative' (default) or 'shin' (loads the overround onto the longshot). Same vocabulary as propline_get_event_ev; echoed as devig_method.",
+  "enum": [
+    "multiplicative",
+    "shin"
+  ],
+  "type": "string"
+}
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses statelessness, the deliberate return of two CLV numbers with their interpretation, de-vig anchoring to the sharpest book, fail-closed matching with unmatched_reason, exclusion of pending bets from averages, a 500-bet max, and free-tier nulling. These are rich behavioral details that materially help an agent interpret and trust results. No contradictions 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?

The description is lengthy but every sentence adds value. It front-loads the core purpose and then systematically covers the two CLV metrics, de-vig behavior, pending-bet handling, matching semantics, limits, and tier behavior. The structure is logical and the detail is justified given the tool's complexity and lack of an output schema. It is not overly redundant, though it could be slightly tightened.

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?

For a tool with only two parameters and no output schema, the description is thorough. It explains what each output field means, including the subtle distinction between clv_pct and ev_vs_close_pct, how de-vigging works, the fail-closed matching behavior, pending-bet exclusion, and free-tier nulling. An agent has everything needed to call the tool correctly and interpret results reliably. Edge cases and limits are covered.

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 schema already provides 100% coverage of both parameters with detailed descriptions, including the devig enum and the bets array structure. The description adds little new meaning about the input parameters themselves—it mostly explains output semantics and edge cases. It does mention the devig vocabulary links to propline_get_event_ev, which is useful, but this is a marginal addition. A baseline of 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 clearly states the tool grades placed bets against closing lines, a specific verb and resource. It enumerates the returned data (closing price, de-vigged fair probability, CLV, graded resolution, portfolio summary) and distinguishes it from sibling get_* tools by focusing on evaluation rather than fetching odds. The purpose is unambiguous and actionable.

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 provides clear context on when to use the tool (when grading placed bets to evaluate edge) and even gives interpretation guidance, such as reporting ev_vs_close_pct when the user asks about value and not presenting pending bets as results. It does not explicitly name alternative tools or say 'use X instead of Y', but the unique grading function makes this unnecessary. The 'Hobby+ endpoint' mention also hints at access constraints, though it is not fully explained.

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