Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi

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.

Schema Changelog

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

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the annotations (readOnly, openWorld, idempotent, non-destructive) to disclose behavioral nuances: it states statelessness, explains that two CLV numbers are returned deliberately and the distinction between them, details the de-vig anchoring to the sharpest book (noting the negative CLV if de-vigging own book), describes fail-closed matching with unmatched_reason, and clarifies that pending bets are excluded from averages. It even notes the free tier nulls numbers. This comprehensive transparency is exemplary and no contradictions with annotations exist.

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 fairly long, but every sentence contributes essential information. It opens with the core purpose, then logically explains outputs, nuances (CLV types, de-vig anchoring), edge cases (pending bets, fail-closed matching), and limitations (max 500, free tier). The structure is coherent and front-loaded, though it could be slightly tightened without losing meaning. Overall, it's dense but not verbose, and the organization aids readability.

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?

Given the tool's complexity (no output schema, nuanced CLV concepts, matching behavior, and various constraints), the description is exceptionally complete. It covers inputs, outputs, interpretation, edge cases, limits, and even gives strategic advice (which CLV metric to report). This leaves virtually no question unanswered for an agent deciding when and how to use the tool. It is highly complete for a tool with such intricate behavior.

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?

Although the schema already covers 100% of the single parameter (bets) with descriptions for each property, the tool description adds significant semantic depth: it clarifies what the tool does with the bets, explains that 'selection' is the subject, and outlines the meaning of the output fields (e.g., clv_pct vs ev_vs_close_pct). It also explains the matching logic and the significance of fields like closing_is_final. This goes well beyond the schema, providing crucial context that helps the agent understand how to construct and interpret the input.

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's purpose: 'Grades PLACED bets against their closing lines.' It specifies the resource (bets), the action (grading), and the key concept (comparison to closing lines). It also distinguishes from sibling tools like propline_get_odds or propline_get_event_results by focusing on bet grading and CLV calculation. The detailed explanation of outputs (closing price, de-vigged probability, CLV) leaves no ambiguity.

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?

While the description does not explicitly list alternative tools or 'when not to use,' it provides strong usage context: it explains that the tool grades placed bets and highlights specific scenarios (e.g., 'Bets whose event has not started... do not present those as results'). It also guides output interpretation: 'report that one when the user asks whether they got value.' This implicitly tells when to use the tool (when grading bets) and how to handle edge cases. A bit more explicit exclusion of alternatives would be ideal, but it's already clear enough.

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