Skip to main content
Glama

PropLine — Sports Betting Odds & Prop Resolution

by io.github.proplineapi
OverviewDiscussionsAdmin

Get line movement & steam

propline_get_event_movement
Read-onlyIdempotent

Line movement + steam detection from the snapshot tick history. Per (book, market, outcome): opening line, latest line, signed implied-probability shift, point shift, direction. The steam[] array flags outcomes that multiple books moved the same direction — the classic sharp-money signal, computed across all 27 books PropLine polls. When a book moves the line itself, that outcome's prob_shift is null and direction is 'line_moved' (excluded from the steam signal). No pull-only odds API can produce this. Each outcome carries outcome_id (the id /odds and webhooks use); steam rows carry team (team totals) plus open_point/latest_point. Hobby+ full; free tier redacted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sinceNoMeasure movement from this moment instead of each line's first quote: ISO-8601 timestamp or a negative offset from now ('-6h', '-30m', '-2d'). Steam then covers only moves inside the window.
periodNoGame-period filter (q1..q4, h1/h2, p1..p3, i1..i9, f3/f5/f7; comma-separated, or 'all'). Omit for full-game.
marketsNoComma-separated market keys. Defaults to h2h,spreads,totals.
event_idYes
sport_keyYes
bookmakersNoComma-separated subset of book keys (e.g. 'draftkings,fanduel'). Default returns all available.
include_book_idsNoWhen true, each outcome also carries book_outcome_id — the book's own selection id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / include_book_ids
      Added value: +{
+  "description": "When true, each outcome also carries book_outcome_id — the book's own selection id.",
+  "type": "boolean"
+}
    • addedInput schema / properties / since
      Added value: +{
+  "description": "Measure movement from this moment instead of each line's first quote: ISO-8601 timestamp or a negative offset from now ('-6h', '-30m', '-2d'). Steam then covers only moves inside the window.",
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior5/5

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

While annotations already declare readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral detail beyond that: the steam[] array's exact definition, the null prob_shift and 'line_moved' direction when a book moves the line itself, exclusion of those outcomes from steam, the inclusion of outcome_id for /odds and webhooks, and the free-tier redaction behavior. This is rich, non-obvious behavioral disclosure that materially helps an agent interpret results correctly.

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 long but every sentence carries dense, useful information: the core output, the steam semantics, the line_moved edge case, and the outcome_id linkage. It is front-loaded with the main purpose before diving into details. It earns its length, though it could be slightly tightened without losing meaning.

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?

Given that there is no output schema, the description does a strong job explaining what the response contains: opening line, latest line, prob shift, direction, steam rows, outcome_id, team, and open/latest point. It also flags the free-tier limitation. Combined with the 71% schema coverage on inputs, an agent has enough to call the tool correctly. Minor gaps remain, such as explicit error behavior, but not enough to lower the score further.

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 71%, so the schema already documents most parameters. The description adds valuable output context (outcome_id semantics) but does not significantly elaborate on the parameters themselves beyond what the schema provides. With moderate coverage, the 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 opens with a specific, unambiguous statement: 'Line movement + steam detection from the snapshot tick history,' naming the exact resource and operation. It further enumerates what is returned per (book, market, outcome), distinguishing this from generic odds endpoints. This clearly differentiates the tool from its siblings, especially the various odds and history tools.

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 clearly implies when to use this tool: whenever an agent needs opening/latest lines, implied-probability shifts, and steam detection. The closing line, 'No pull-only odds API can produce this,' contrasts it with pull-only odds tools, giving context for exclusion. It does not name a specific sibling as an alternative, but the usage context is 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
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