What can you do with this server?

PropLine MCP lets you query live sports betting odds, player props, scores, and analytics using natural language through any MCP-compatible AI assistant. Key capabilities include: * Discover Sports & Events: List all 38+ sports covered (MLB, NBA, EPL, etc.), fetch upcoming/live events with team names and start times, and identify available market types (spreads, totals, player props, etc.) for specific events. * Live Odds: Pull real-time odds across up to 13 sportsbooks (DraftKings, FanDuel, Pinnacle, BetMGM, PrizePicks, and more). Filter by bookmaker or market type (e.g., player_points, pitcher_strikeouts). * Odds History & Line Movement: Retrieve historical line-movement snapshots, detect sharp-money steam moves, export bulk tick-by-tick odds history, and get closing lines for CLV analysis (Hobby+ tier). * Scores & Game Results: Check live and recent game scores and statuses (scheduled, live, final) for free. * Box-Score Stats: Fetch raw per-player box-score stats for completed games, plus game context like probable pitchers, lineups, umpire, and weather. * Prop Resolution & Grading: View graded prop outcomes (won/lost/push/void) with actual stat values vs. the line for completed events (Pro tier), plus a summary of graded prop volume across sports and markets. * Player Prop History & Trends: Track a player's prop-bet history with lines, prices, and resolution across recent games, and analyze hit-rate trends (over/under splits, streaks, avg actuals) over last 5–50 games. * +EV & Sharp Betting Analysis: Calculate cross-book positive expected value (+EV%) using Pinnacle-anchored no-vig fair lines to identify potentially profitable plays (Pro tier).

Which integrations are available for this server?

Allows querying live odds, player props (e.g., pitcher strikeouts, batter home runs), scores, and box-score stats for MLB games. Allows querying live odds, player props (e.g., points, rebounds, assists), scores, and box-score stats for NBA games.

de en es ja ko ru zh

PropLine

Official

by proplineapi

Overview Schema Related Servers Score Discussions

TypeScript

Remote

propline-mcp

npm version License: MIT

Listed in the official MCP Registry as io.github.proplineapi/propline-mcp — discoverable from Claude Code, Claude Desktop, and any MCP-aware client.

Model Context Protocol server for the PropLine player props betting odds API. Plug it into Claude Desktop, Claude Code, or any MCP-compatible client and ask natural-language questions about live odds, prop resolution, cross-book +EV, scores, and box-score stats — the model picks the right tool, calls the API, and answers from real data.

No more "I'd need an API for that" deflections from your AI assistant. PropLine MCP turns sports-betting research into a chat.

What you can ask

Once installed, you can prompt the model with things like:

"What's the +EV on Yankees vs Red Sox tonight across all books?"
"Pull Aaron Judge's last 20 prop-bet history with hit/miss outcomes."
"List today's MLB pitcher strikeout props from DraftKings and Pinnacle side by side."
"Did Nikola Jokic's points prop hit last night? What was the line?"
"Compare PrizePicks DFS projections to Bovada lines for tonight's NBA slate."
"What's the first-quarter total on Lakers vs Celtics, and which book has the best Over?"

The model uses these tools transparently:

Tool	What it does
`propline_list_sports`	Discover what sports PropLine polls (54 today)
`propline_list_events`	Upcoming events for a sport, with ids
`propline_list_event_markets`	Available market types for an event
`propline_get_odds`	Live odds — bulk by sport or full props per event. Accepts `period` (q1/h1/p1/f5/…) to scope to game-period markets.
`propline_get_odds_history`	Hobby+: snapshot history per outcome; supports `period` (q1/h1/…) plus time-window filters (from/to, relative_from/relative_to, interval, changes_only)
`propline_get_odds_closing`	Hobby+: opening and closing line per (book, market, outcome) — CLV helper. Accepts `period` to scope to a specific game period.
`propline_grade_clv`	Hobby+: grade placed bets against their closing lines. Returns closing price, de-vigged closing fair (`fair_source` = sharpest book at close, not yours), `clv_pct` (price-vs-price, vig-blind) and `ev_vs_close_pct` (the honest number), plus the graded result once the game settles. Fail-closed matching; unstarted events come back `closing_is_final: false` and are excluded from the averages.
`propline_price_sgp`	Hobby+: price a same-game parlay at the book's own correlated odds (FanDuel, BetOnline, LowVig). Returns `sgp_price`, `independent_price` (product of the live single-leg prices) and `correlation_factor` (their ratio). Legs are named exactly as `/odds` names an outcome; matching is fail-closed.
`propline_export_odds_history`	Backfill-pass / Enterprise: bulk line-movement tick history (every snapshot, per book) for a sport. Requires a `since`/`until` window; result capped to 200 rows (use the REST endpoint directly for the full file).
`propline_get_futures`	Season-long futures — championship/division/conference winners, MVP + awards, season win totals — across Bovada/FanDuel/DraftKings/Pinnacle/Kalshi (free)
`propline_get_scores`	Game scores + status (free)
`propline_get_dfs_payouts`	PrizePicks Power/Flex payout schedule + per-leg breakeven win probability (free)
`propline_get_mlb_grand_salami`	Synthetic daily MLB Grand Salami — total runs + each book's implied line (free)
`propline_get_nhl_daily_goals_total`	Synthetic daily NHL goals total — hockey's Grand Salami (free)
`propline_get_resolution_summary`	Graded-prop volume + per-sport/market breakdown (free)
`propline_get_event_stats`	Raw box-score stats (free, book-agnostic)
`propline_get_event_context`	Game conditions a prop settles under — probable pitchers, lineup flag, home-plate umpire, first-pitch weather (free)
`propline_get_event_movement`	Line movement + steam detection (sharp-money signal across all books) from the tick history (Hobby+)
`propline_get_event_results`	Pro: graded won/lost/push per prop
`propline_get_player_history`	Player prop history with resolution
`propline_get_player_games`	Player game log — recent games with every raw box-score stat per game, one call instead of one per event; `opponent` gives head-to-head (last N meetings). Raw-stat archive, so it includes games no book priced
`propline_get_player_trends`	Hit-rate trends — over/under/push splits over last 5/10/20/50 graded games, streak, avg actual (optional `dfs_odds_type` to scope to a PrizePicks flavor)
`propline_get_event_ev`	Pro: cross-book +EV with no-vig fair lines
`propline_get_event_projections`	Hobby+: market-implied consensus projection per (market, player)
`propline_get_best_line`	Hobby+: cross-book line shopping — best price per (market, player, line) across all comparable books, `all_prices` sorted best-first; optional `bookmakers` filter
`propline_list_webhooks`	Streaming Lite+: list webhook subscriptions (read-only, secrets masked)
`propline_get_webhook_deliveries`	Streaming Lite+: recent delivery attempts for a webhook — status, HTTP code, attempts, payload; `before_id` pages backwards. The "why isn't my webhook firing" tool

Related MCP server: Sports Betting MCP

Hosted endpoint (no install)

The same 27 tools are served over Streamable HTTP at

https://mcp.prop-line.com/mcp

Use it from any remote-capable client — nothing to install, nothing to run.

Client	How
Claude Code	`claude mcp add --transport http propline https://mcp.prop-line.com/mcp`
Claude.ai / Claude Desktop	Settings → Connectors → Add custom connector → URL above
Cursor	Settings → MCP → Add server → type `http`, URL above (one-click)
ChatGPT (developer mode)	Settings → Connectors → Create → MCP server URL above
Any client	Streamable HTTP, endpoint `/mcp`; `GET /` returns a JSON manifest

Auth is per request. Send your PropLine key as Authorization: Bearer <key> (or X-API-Key: <key>, or ?apiKey=<key> for clients that cannot set headers). With no key the endpoint falls back to the shared free demo key — every tool works, paid features are redacted, limits are pooled. Keys are used for the one request and never stored.

Claude Code with your own key:

claude mcp add --transport http propline https://mcp.prop-line.com/mcp \
  --header "Authorization: Bearer YOUR_KEY"

The stdio build below (npx -y propline-mcp) is the same code; pick whichever your client prefers.

Zero-config quick start

No key needed to try it. The server falls back to a shared public demo key, so this just works:

npx -y propline-mcp

Your agent can immediately pull live odds, scores, and stats. The demo key is free-tier and shared — paid features (resolution, +EV, history, exports) return a redacted teaser, and limits are pooled across everyone. For full access and your own limits, set PROPLINE_API_KEY (below). Get a free personal key at prop-line.com.

While the demo key is in use, every tool result carries a second content block noting the pooling and redaction, so the assistant can explain an empty field or a 429 accurately. It disappears the moment you set your own key.

Install (with your own key)

1. Get a PropLine API key

prop-line.com — free tier is 1,000 requests/day, no credit card. Hobby at $9/mo unlocks resolution, history, closing lines and +EV — Pro at $19/mo is that same feature set at 25,000 requests/day.

2. Add to your MCP client

Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "propline": {
      "command": "npx",
      "args": ["-y", "propline-mcp"],
      "env": {
        "PROPLINE_API_KEY": "YOUR_KEY_HERE"
      }
    }
  }
}

Restart Claude Desktop. The hammer icon should show 27 PropLine tools. (Or skip the install and add https://mcp.prop-line.com/mcp as a custom connector — see the hosted endpoint above.)

Claude Code

claude mcp add propline \
  --env PROPLINE_API_KEY=YOUR_KEY \
  -- npx -y propline-mcp

Any other MCP client

Run propline-mcp as a stdio server. Most clients accept a command + env. See the MCP spec for client-specific config.

Configuration

Env var	Required	Default	Notes
`PROPLINE_API_KEY`	no	shared demo key	Unset = shared free demo key (paid features redacted, pooled limits). Set your own free key from prop-line.com for full access.
`PROPLINE_BASE_URL`	no	`https://api.prop-line.com`	Override for self-hosted setups

Comparison with the-odds-api

PropLine is API-compatible at the response level (same bookmakers[].markets[].outcomes[] shape) and adds three things the-odds-api doesn't offer at any tier:

Prop resolution — every Over/Under graded against the actual box-score stat after the game
Cross-book +EV — Pinnacle-anchored no-vig fair lines per book, sorted with +EV plays at the top
Webhooks — push delivery on Streaming tier, not pull-only

Pricing: free at 1,000 req/day (vs their 500/month), Hobby at $9/mo for 5,000 req/day, Pro at $19/mo for 25,000, Streaming Lite at $39/mo for 250,000 (webhooks + websocket), Streaming at $79/mo for 1,000,000. No credit math.

License

MIT

Available Tools

11 tools

propline_get_event_evAInspect

Pro-tier endpoint. Returns cross-book +EV per outcome for an event. We anchor on Pinnacle's sharp line, remove vig, derive a no-vig fair line, and compute EV% per book at the same line. Outcomes are sorted with +EV plays floated to the top of each line group. PrizePicks is excluded from EV math (DFS payouts aren't comparable to per-book prices).

ParametersJSON Schema

Name	Required	Description
`sport_key`	Yes
`event_id`	Yes
`markets`	No
`min_ev_pct`	No	Filter to outcomes with EV ≥ this percent (e.g. 2.0).

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the methodology (Pinnacle sharp line, vig removal, fair line derivation), sorting behavior, and exclusion of PrizePicks. This provides sufficient behavioral context for an agent.

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 concise at four sentences, well-structured with front-loading of key purpose. Every sentence adds value with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains core behavior but lacks details on output format, pagination, or error handling. Given no output schema, the agent lacks complete context for interpreting results.

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 25% (only min_ev_pct described). While the description adds context about computing EV per book and outcome, it does not clarify the format or usage of the other parameters (sport_key, event_id, markets). It partially compensates but not fully.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns cross-book +EV per outcome for an event, with specific methodology. It does not explicitly distinguish from sibling tools like propline_get_odds, but the tool name and description make the purpose clear.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, context, or exclusions beyond being a 'Pro-tier endpoint'.

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

propline_get_event_resultsAInspect

Pro-tier endpoint. Returns graded prop outcomes for a completed event — every Over/Under marked won, lost, push, or void with the actual stat value next to the line. The single most distinctive feature vs the-odds-api: they don't grade props at any tier. Free tier returns the same structure with resolution and actual_value redacted plus an upgrade pointer.

ParametersJSON Schema

Name	Required	Description	Default
`sport_key`	Yes
`event_id`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses pro-tier endpoint behavior, free tier redaction of resolution and actual_value, and upgrade pointer. It implies read-only operation but does not explicitly state nondestructive nature or authentication requirements.

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?

Three sentences with front-loaded purpose, followed by distinctive feature and free tier note. Every sentence adds value without redundancy. Highly efficient.

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 no output schema, the description explains return structure (graded outcomes with marks and actual values) and free tier behavior. It is sufficient for a low-complexity tool with 2 params, though pagination and error handling are not mentioned.

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

Parameters2/5

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

Schema has 2 parameters with 0% description coverage, and the tool description adds no detail about sport_key or event_id beyond their names. The purpose indirectly explains them but does not provide formats, examples, or constraints.

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 it returns graded prop outcomes for completed events, specifying details like won/lost/push/void marks and actual stat values. It distinguishes itself from the-odds-api which does not grade props, making the purpose highly specific and differentiated.

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 indicates use for completed events and contrasts with the-odds-api, providing clear context. However, it does not explicitly suggest when to use this tool over other propline siblings (e.g., propline_get_event_ev), though the purpose is distinct enough.

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

propline_get_event_statsBInspect

Book-agnostic raw box-score stats for a completed event. Returns per-player stats (e.g. strikeouts, hits, points, rebounds, shots-on-goal) decoupled from any sportsbook's lines. Free tier.

ParametersJSON Schema

Name	Required	Description	Default
`sport_key`	Yes
`event_id`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It states the result is 'book-agnostic' and 'decoupled from any sportsbook's lines', and notes 'Free tier', but does not mention authentication needs, rate limits, or what happens if the event is not completed. The description is too sparse given the lack of annotations.

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 composed of two concise sentences with no filler. The first sentence defines the core purpose, and the second adds relevant examples. Every word contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has only two required parameters and no output schema or nested objects, the description provides a baseline understanding. However, it lacks details on return format, error conditions, or pagination. It is minimally complete for a simple tool but leaves gaps in behavioral context.

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

Parameters2/5

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

The input schema has two parameters (sport_key, event_id) with no description coverage (0%). The description does not elaborate on these parameters or their expected formats/values. While the description provides examples of returned stats, it adds no meaning to the parameters themselves.

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 returns 'book-agnostic raw box-score stats for a completed event', specifying the verb (implicitly 'get'), resource (raw box-score stats), and scope (per-player stats decoupled from sportsbook lines). It distinguishes from siblings like propline_get_event_results or propline_get_scores by emphasizing it provides per-player stats such as strikeouts, hits, points, etc.

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

Usage Guidelines3/5

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

The description mentions the tool is for 'completed event' and is on the 'Free tier', implying it should be used for finalized events. However, it does not explicitly state when not to use this tool or provide comparisons to sibling tools (e.g., propline_get_event_results). Usage context is implied but lacks exclusions or alternatives.

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

propline_get_oddsAInspect

Get live odds. If event_id is supplied, returns full per-event props for that event; otherwise returns bulk game-line odds for the whole sport. Pass markets as a comma-separated list (e.g. 'h2h,spreads,totals' or 'player_points,player_rebounds'). Response includes a bookmakers[] array across every book that carries the requested markets (currently up to 13: Bovada, DraftKings, FanDuel, Pinnacle, BetMGM, BetRivers, Unibet, Underdog, PrizePicks, Kalshi, Polymarket, Matchbook, Smarkets — coverage varies by sport).

ParametersJSON Schema

Name	Required	Description
`sport_key`	Yes
`event_id`	No	Optional. If set, returns props for this event.
`markets`	No	Comma-separated market keys. Defaults to h2h on bulk; h2h,spreads,totals on event. Pass an explicit list to fetch player props (sport-specific — e.g. player_points,player_rebounds for NBA; pitcher_strikeouts,batter_home_runs for MLB).
`bookmakers`	No	Comma-separated subset of book keys (bovada, draftkings, fanduel, pinnacle, betmgm, betrivers, unibet, underdog, prizepicks, kalshi, polymarket, matchbook, smarkets). Default returns all available.

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses that the response includes a bookmakers[] array with up to 13 books, that coverage varies by sport, and how parameters affect behavior. It lacks details on authentication or rate limits, but the core behavior is well covered.

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 concise (5 sentences), front-loaded with the core action, and each sentence adds necessary detail without redundancy. It is well-structured and easy to parse.

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?

For a tool with 4 parameters and no output schema, the description adequately covers the main behaviors and response structure. It could mention error handling or supported sports, but the essentials are present.

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

Parameters4/5

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

Schema coverage is 75%, and the description adds value beyond schema descriptions by providing examples (e.g., 'h2h,spreads,totals' for markets) and explaining default behaviors for event_id and markets. The parameters are well explained in combination.

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 'Get live odds' and distinguishes two modes based on event_id: full per-event props when event_id supplied, bulk game-line odds otherwise. It is specific and actionable, differentiating from siblings by naming the resource (odds) and behavior.

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 guidance on when to use the tool with or without event_id, and how to specify markets and bookmakers. It does not explicitly contrast with sibling tools, but the context is sufficient for common use cases.

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

propline_get_odds_historyAInspect

Pro-tier endpoint. Returns the historical line-movement snapshot series for an event (every recorded price/point change per outcome over the event's lifetime). Free tier returns market structure with redacted snapshots and an upgrade pointer.

ParametersJSON Schema

Name	Required	Description	Default
`sport_key`	Yes
`event_id`	Yes
`markets`	No

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description explains the data returned (snapshot series) and tier differences, but lacks details on rate limits, authentication, or error handling. Some behavioral info is present but incomplete.

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?

Two concise sentences, front-loaded with purpose and supplemented with tier context. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three undocumented parameters and no output schema, the description lacks detail on parameter usage, return format, pagination, or limits. Incomplete for correct invocation.

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

Parameters2/5

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

Schema has 0% description coverage and the tool description does not explain any of the three parameters (sport_key, event_id, markets). Only implicit understanding from context. Description fails to compensate.

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?

Description clearly states it returns historical line-movement snapshots for an event, distinguishing it from sibling tools like propline_get_odds (current odds).

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?

Mentions it's a Pro-tier endpoint and describes free tier behavior, giving context on when to use. No explicit exclusions or alternatives, but the tier distinction provides guidance.

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

propline_get_player_historyBInspect

Player prop history across recent games. Returns each prior prop this player took with line, prices, resolution, and actual value. Pro tier returns full data; free tier returns redacted resolution/actual_value with an upgrade pointer.

ParametersJSON Schema

Name	Required	Description
`sport_key`	Yes
`player_name`	Yes	Player name as it appears in box scores — e.g. 'Aaron Judge', 'Nikola Jokic'
`limit`	No	Max number of past games (default 20, max 100)
`markets`	No	Comma-separated subset of markets (e.g. 'player_points,player_rebounds')

TDQS

B3.3/5.0

Behavior3/5

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

The description discloses tier-based data redaction for free tier and mentions return fields. However, it does not address rate limits, idempotency, or other potential side effects, leaving gaps in behavioral understanding.

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?

Two sentences with no fluff. Front-loaded with key purpose, then adds tier detail. Efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 4 parameters, no output schema, and no annotations, the description explains return fields and tier behavior but lacks detail on parameter interactions and output format. Adequate but not comprehensive.

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 coverage is 75%. The description adds minimal value beyond the schema by summarizing returned data but does not clarify how parameters like 'limit' or 'markets' affect output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns player prop history with specific fields like line, prices, resolution, and actual value. It distinguishes tiers but does not explicitly differentiate from sibling tools, though the name implies uniqueness.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternative propline tools. The only context is a tier difference (pro vs free), but no prerequisites or usage scenarios are mentioned.

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

propline_get_resolution_summaryAInspect

Free-tier endpoint. Returns the factual volume of player props PropLine has graded against real box scores over the last N days (aggregated counts only): total graded/settled, games, sports covered, plus per-sport and top-market breakdowns. Useful for: 'how much graded prop data does PropLine have, what's the coverage'. A coverage proof, never a profitability claim.

ParametersJSON Schema

Name	Required	Description	Default
`days`	No	Look-back window, 1-90. Defaults to 30.

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden. It discloses it's a free-tier endpoint and returns only aggregated counts, but lacks details on rate limits, authentication, error conditions, or data freshness. This leaves some behavioral gaps.

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 concise with three well-structured sentences, front-loading the key fact 'Free-tier endpoint' and clearly listing output components. No redundant information.

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 the simple schema and no output schema, the description reasonably covers the tool's function by listing output elements. It could elaborate on the response format but is adequate for most use cases.

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 coverage is 100% with the 'days' parameter fully described (type, range, default). The description's mention of 'over the last N days' adds no new information beyond the schema, meeting the baseline for high schema coverage.

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 identifies the tool as returning aggregated counts of graded props, listing specific metrics like total graded/settled, games, sports per sport, and top-market breakdowns. It distinguishes itself from profitability claims and aligns with the tool name 'resolution_summary'.

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 explicitly states the use case: answering 'how much graded prop data does PropLine have, what's the coverage', and clarifies it is not for profitability. While it does not mention when not to use it or alternatives, the guidance is sufficient for typical scenarios.

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

propline_get_scoresAInspect

Free-tier endpoint. Returns recent and live game scores plus status (scheduled, live, final) for a sport. Useful for: 'is this game over yet, what was the final score'.

ParametersJSON Schema

Name	Required	Description	Default
`sport_key`	Yes
`days_from`	No	How many past days of completed games to include. Defaults to 1.

TDQS

A4/5.0

Behavior3/5

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

No annotations, so description carries full burden. Discloses Free-tier nature (suggests rate limits) and returned data types. However, does not specify how recent data is, max results, or if any side effects exist. Adequate but not rich.

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?

Two concise sentences plus a usage quote. Front-loaded with main purpose. No unnecessary words. Excellent structure.

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 the simplicity (2 params, no output schema), the description covers purpose and usage adequately. Could mention pagination or limits, but not essential for typical use. Slightly incomplete regarding 'recent' definition.

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 50% (only days_from documented). Description adds context that tool returns 'recent and live' scores, but does not elaborate on sport_key format or usage beyond the schema. Adequate but not exceptional.

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?

Clearly states it returns recent and live game scores plus status for a sport. Verb 'returns' and resource 'scores and status' are specific. Distinguished from siblings like 'propline_get_event_results' by focusing on live scores.

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 a concrete use case ('is this game over yet, what was the final score') that helps agent select tool. However, no explicit when-not-to-use or alternatives given, but 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.

propline_list_event_marketsAInspect

List the market types available for a specific event (e.g. h2h, spreads, totals, player_points, pitcher_strikeouts). Useful when you don't know which prop markets a given event carries.

ParametersJSON Schema

Name	Required	Description	Default
`sport_key`	Yes
`event_id`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It only states the action (list) and gives examples, but fails to disclose whether the operation is read-only, what happens with invalid inputs, or any side effects.

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 concise with two sentences: the first clearly states the purpose with examples, and the second adds a usage context. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description covers the basic purpose and a usage scenario. However, it does not specify the return format or error handling, which would be helpful for an agent.

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

Parameters2/5

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

The input schema has zero description coverage, and the tool description does not explain the meaning or format of the required parameters (sport_key, event_id). The examples in the description are for the output, not the parameters.

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 it lists market types for a specific event with concrete examples (h2h, spreads, etc.), and the verb 'list' combined with 'market types' distinguishes it from sibling tools that handle odds, results, or stats.

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 includes a usage hint ('Useful when you don't know which prop markets...'), implying when to use it. However, it does not explicitly mention when not to use it or provide alternatives among the siblings.

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

propline_list_eventsAInspect

List upcoming events for a sport. Returns each event's id, home_team, away_team, commence_time. Use the returned event_id to drill into per-event odds, props, +EV, or results.

ParametersJSON Schema

Name	Required	Description	Default
`sport_key`	Yes	Sport key from propline_list_sports — e.g. baseball_mlb, basketball_nba
`live`	No	If true, only return in-progress (live) events. Defaults to false.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, description discloses that it returns event IDs and team names, and behavior of 'live' parameter is implied. Does not mention read-only nature or potential errors, but adequate for a list tool.

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?

Two sentences, no fluff, front-loaded with purpose and return fields, then usage hint.

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?

Completeness is good for a simple list tool: explains inputs, outputs, and next steps. Missing details like ordering or pagination, but not critical.

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 covers sport_key and live with 100% description coverage; description only reiterates return fields, adding no extra parameter insight.

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?

Description clearly states it lists upcoming events for a sport and specifies return fields (id, home_team, away_team, commence_time). It distinguishes from siblings like propline_get_odds or propline_get_event_results by focusing on event listing.

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?

Description implicitly guides usage by noting to use event_id for per-event details, but lacks explicit when-to-use vs alternatives or when-not-to-use.

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

propline_list_sportsAInspect

List all sports PropLine currently polls. Returns sport keys (e.g. baseball_mlb, basketball_nba, soccer_epl) along with human titles and active status. Use this first to discover what sport_key values are valid for the other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It explains the return format (keys, titles, active status) and that it lists currently polled sports, which is sufficient for a simple read-only operation.

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?

Two concise sentences with no wasted words. The key information is front-loaded.

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?

The description fully covers the tool's purpose and usage given zero parameters, no output schema, and low complexity.

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

Parameters4/5

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

No parameters exist; baseline score of 4 applies. The description adds no parameter-specific information, which is acceptable given the lack of parameters.

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 it lists all sports PropLine polls and specifies the output includes sport keys, human titles, and active status. This distinguishes it from sibling tools which focus on events, odds, etc.

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

Usage Guidelines5/5

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

Explicitly advises to use this tool first to discover valid sport_key values for other tools, providing clear guidance on when and why to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv0.2.3May 17, 2026
- First observedpropline_get_event_ev
- First observedpropline_get_event_results
- First observedpropline_get_event_stats
- First observedpropline_get_odds
- First observedpropline_get_odds_history
- First observedpropline_get_player_history
- First observedpropline_get_resolution_summary
- First observedpropline_get_scores
- First observedpropline_list_event_markets
- First observedpropline_list_events
- First observedpropline_list_sports

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct aspect of the sports betting data lifecycle: listing sports, events, and markets; retrieving odds, EV, results, stats, historical movements, player history, scores, and resolution summaries. No two tools have overlapping purposes, and descriptions clearly differentiate them.

Naming Consistency5/5

All tools follow a consistent propline_verb_noun pattern, using 'list' for enumeration endpoints and 'get' for data retrieval. The naming is predictable and makes the action and resource easy to identify.

Tool Count5/5

With 11 tools, the server is well-scoped for a sports betting data provider. Each tool serves a clear purpose, covering discovery, odds, EV analysis, historical data, results, and stats without unnecessary bloat or gaps.

Completeness5/5

The tool surface covers the full domain: listing sports, events, markets; retrieving live odds, EV, historical movements, graded results, player history, raw stats, and a coverage summary. Essential operations are present, and no obvious dead ends exist.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

sportwizzard
com.sportwizzard
Real-time sports betting data: odds, player props, edges and arbitrage from 35+ books and DFS apps.
Sports Finance
2
Nightly MCPOAuth
io.github.bakaburg24
NBA/WNBA betting analytics: live odds, sharp fair prices, injuries, and prop verification.
Sports Finance Research & Data
1
EventEdge Oracle B
space.arakelproof.edge
Prediction-market intelligence for conservative cross-market pricing edges and live signals.
Finance Research & Data
21
ParlayAPI A
io.github.JacobiusMakes
Sports odds, player props and source coverage for AI assistants. Connect with your own API key.
Sports Data Platforms
221

Related MCP Servers

College Football MCP
Sports Search Open Data
gedin-eth
F
license
Not graded
quality
D
maintenance
Provides real-time college football game scores, betting odds, player statistics, and team performance data through integration with The Odds API and CollegeFootballData API.
Updated 9 months ago (2025-12-21 23:11 UTC)
-
Sports Betting MCP
Sports Finance Search
seang1121
A
license
A
quality
D
maintenance
Provides AI-powered sports betting intelligence including live odds, injury reports, and documented picks for NBA, NHL, and NCAAB. It enables AI agents to analyze line movements, win rates, and betting edges using real-time data from sportsbettingaianalyzer.com.
Updated 5 months ago (2026-04-08 03:01 UTC)
11
5
MIT
qune-tech/ocds-mcp
Government Data Search RAG Systems
qune-tech
A
license
A
quality
B
maintenance
MCP server for German public procurement data (OCDS). Semantic search, tender matching, and company profiles — all from your local LLM
Updated a month ago (2026-07-26 10:13 UTC)
10
5
MIT
betting-brain-v3
Sports Finance
brendadeeznuts1111
A
license
Not graded
quality
C
maintenance
Provides betting intelligence and analytics tools including exposure, CLV, sharp scoring, live betting, and Fantasy402 integration, running on Cloudflare Edge.
Updated a year ago (2025-10-09 05:39 UTC)
8
MIT

Appeared in Searches

A search for 'ol' - possibly an abbreviation or partial word

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/proplineapi/propline-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

propline-mcp

What you can ask

Hosted endpoint (no install)

Zero-config quick start

Install (with your own key)

1. Get a PropLine API key

2. Add to your MCP client

Claude Desktop

Claude Code

Any other MCP client

Configuration

Comparison with the-odds-api

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API