F
licenseNot graded
qualityD
maintenanceProvides real-time college football game scores, betting odds, player statistics, and team performance data through integration with The Odds API and CollegeFootballData API.
-
PropLine
Officialby proplineapi
propline-mcp
已在官方 MCP Registry 中列出，标识为 io.github.proplineapi/propline-mcp —— 可从 Claude Code、Claude Desktop 以及任何支持 MCP 的客户端中发现。
用于 PropLine 球员道具投注赔率 API 的 Model Context Protocol 服务器。将其接入 Claude Desktop、Claude Code 或任何兼容 MCP 的客户端，并用自然语言询问关于实时赔率、道具结算、跨博彩公司 +EV、比分和 box-score 统计数据的问题——模型会选择合适的工具、调用 API，并基于真实数据作答。
你的 AI 助手再也无法用“我需要一个 API 才能做到”来搪塞。PropLine MCP 将体育博彩研究变成一场对话。
你可以问什么
安装后，你可以向模型提出如下问题：
“今晚 Yankees 对 Red Sox 的比赛，所有博彩公司的 +EV 是多少？”
“拉取 Aaron Judge 最近 20 条道具投注历史，包含命中/未命中的结果。”
“将今天 MLB 投手的三振道具从 DraftKings 和 Pinnacle 并排列出。”
“Nikola Jokic 的得分道具昨晚命中了吗？当时的盘口是多少？”
“将 PrizePicks 的 DFS 预测与 Bovada 的今晚 NBA 赛程盘口进行比较。”
“Lakers 对 Celtics 的第一节总分是多少？哪家博彩公司的 Over 最好？”
模型会透明地使用这些工具：
工具 | 功能 |
| 发现 PropLine 目前采集哪些体育项目（今日 54 项） |
| 某个体育项目即将开赛的赛事，附带 ID |
| 某场比赛可用的市场类型 |
| 实时赔率——按体育项目批量获取，或按比赛获取全部投注项。接受 |
| Hobby+：每个结果的快照历史；支持 |
| Hobby+：每个（博彩公司、市场、结果）的开盘线 和 收盘线——CLV 辅助工具。接受 |
| Hobby+：根据收盘线对 已下注 的注单进行评级。返回收盘价、去水后的收盘公平概率（ |
| Backfill-pass / Enterprise：某个体育项目的大批量盘口变动逐笔历史（每个快照、每家博彩公司）。需要 |
| 整个赛季的期货（futures）——总冠军/分区冠军/联盟冠军、MVP + 奖项、赛季胜场总数——覆盖 Bovada/FanDuel/DraftKings/Pinnacle（免费） |
| 比赛比分 + 状态（免费） |
| PrizePicks Power/Flex 赔付表 + 每条腿（leg）的盈亏平衡胜率（免费） |
| 合成的每日 MLB Grand Salami——总得分 + 每家博彩公司的隐含盘口（免费） |
| 合成的每日 NHL 进球总数——冰球界的 Grand Salami（免费） |
| 已结算投注项数量 + 按体育项目/市场的细分（免费） |
| 原始技术统计（box-score）数据（免费，与博彩公司无关） |
| 投注项结算所依据的比赛条件——预计先发投手、阵容标志、本垒裁判、开赛时天气（免费） |
| 盘口变动 + 急动（steam）检测（跨所有博彩公司的聪明钱信号），来自逐笔历史（Hobby+） |
| Pro：每个投注项的已结算赢/输/走盘（push） |
| 球员投注项历史，包含结算结果 |
| 球员比赛日志——最近比赛，每场包含所有原始技术统计（box-score）数据，一次调用即可，无需按比赛逐个调用； |
| 命中率趋势——最近 5/10/20/50 场已结算比赛的大/小/走盘（push）分布、当前连续走势、实际平均值（可选 |
| Pro：跨博彩公司的 +EV，并给出去水（no-vig）公平线 |
| Hobby+：跨博彩公司比价——在所有可比博彩公司中，每个（市场、球员、盘口）的最佳赔率， |
| Streaming Lite+：列出 webhook 订阅（只读，密钥已掩码） |
| Streaming Lite+：某个 webhook 最近的投递尝试——状态、HTTP 代码、尝试次数、payload； |
Related MCP server: Sports Betting MCP
托管端点（无需安装）
同样的 25 个工具通过 Streamable HTTP 提供，地址为：
https://mcp.prop-line.com/mcp任何支持远程访问的客户端都能使用——无需安装，也无需运行。
客户端 | 方法 |
Claude Code |
|
Claude.ai / Claude Desktop | 设置 → 连接器 → 添加自定义连接器 → URL 填上面的地址 |
Cursor | 设置 → MCP → 添加服务器 → 类型选择 |
ChatGPT (developer mode) | 设置 → 连接器 → 创建 → MCP 服务器 URL 填上面的地址 |
任何客户端 | Streamable HTTP，端点为 |
每次请求单独认证。 将你的 PropLine 密钥作为 Authorization: Bearer <key> 发送（或使用 X-API-Key: <key>，或对于无法设置请求头的客户端使用 ?apiKey=<key>）。不提供密钥时，端点会回退到共享的免费演示密钥——所有工具都能用，付费功能会被屏蔽，限额为所有用户共享。密钥仅用于当次请求，绝不会被存储。
使用你自己的密钥的 Claude Code：
claude mcp add --transport http propline https://mcp.prop-line.com/mcp \
--header "Authorization: Bearer YOUR_KEY"下面的 stdio 构建（npx -y propline-mcp）是同一份代码；选择你的客户端更方便的那种即可。
零配置快速开始
无需密钥即可试用。服务器会回退到共享的公共演示密钥，所以直接就能用：
npx -y propline-mcp你的智能体可以立即拉取实时赔率、比分和统计数据。演示密钥属于免费层级且为共享——付费功能（结算、+EV、历史记录、导出）会返回脱敏后的预览内容，限额由所有人共同分摊。如需完整访问权限和你自己的限额，请设置 PROPLINE_API_KEY（见下文）。在 prop-line.com 获取免费的个人密钥。
安装（使用你自己的密钥）
1. 获取 PropLine API 密钥
prop-line.com — 免费层级为每天 1,000 次请求，无需信用卡。Hobby 版每月 $9，解锁结算、历史记录、收盘赔率和 +EV。Pro 版每月 $19，同样的功能集，每天 25,000 次请求。
2. 添加到你的 MCP 客户端
Claude Desktop
编辑 ~/Library/Application Support/Claude/claude_desktop_config.json（macOS）或 %APPDATA%\Claude\claude_desktop_config.json（Windows）：
{
"mcpServers": {
"propline": {
"command": "npx",
"args": ["-y", "propline-mcp"],
"env": {
"PROPLINE_API_KEY": "YOUR_KEY_HERE"
}
}
}
}重启 Claude Desktop。锤子图标下应显示 25 个 PropLine 工具。（或者跳过安装，将 https://mcp.prop-line.com/mcp 添加为自定义连接器——参见上面的托管端点。）
Claude Code
claude mcp add propline \
--env PROPLINE_API_KEY=YOUR_KEY \
-- npx -y propline-mcp任何其他 MCP 客户端
以 stdio 服务器方式运行 propline-mcp。大多数客户端都接受命令 + 环境变量的配置方式。各客户端的具体配置请参阅 MCP 规范。
配置
环境变量 | 必填 | 默认值 | 说明 |
| 否 | 共享演示密钥 | 未设置 = 共享免费演示密钥（付费功能被屏蔽，限额共享）。从 prop-line.com 获取你自己的免费密钥以解锁完整访问权限。 |
| 否 |
| 自托管部署时覆盖此地址 |
与 the-odds-api 的对比
PropLine 在响应层面与 API 兼容（bookmakers[].markets[].outcomes[] 结构相同），并增加了 the-odds-api 在任何层级都不提供的三项能力：
Prop 结算 — 比赛结束后，将每个 Over/Under 与实际技术统计（box score）数据一一核对结算
跨盘口 +EV — 以 Pinnacle 为锚的各盘口无抽水（no-vig）公平赔率，按 +EV 玩法排序，+EV 最高的排在最前
Webhooks — Streaming 层级支持推送交付，而非只能拉取
价格：免费版每天 1,000 次请求（而对方是每月 500 次），Hobby 版每月 $9，每天 5,000 次请求；Pro 版每月 $19，每天 25,000 次；Streaming 版每月 $79，每天 1,000,000 次。无需再做积分换算。
链接
托管的 MCP 端点：
https://mcp.prop-line.com/mcp（Streamable HTTP）API 文档：prop-line.com/docs
常用示例（常见任务的代码）：prop-line.com/recipes
按运动项目和市场分类的 Odds API（实时赔率、盘口、结算命中率）：prop-line.com/odds-api
Prop 结算（每个玩法都对照技术统计结算）：prop-line.com/prop-resolution-api
跨盘口 +EV：prop-line.com/ev
OpenAPI 参考：api.prop-line.com/docs
面向 AI 智能体（llms.txt、MCP 配置）：prop-line.com/for-ai-agents
Python SDK：
pip install proplineNode SDK：
npm install propline
许可证
MIT
Available Tools
11 toolspropline_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 | Default |
|---|---|---|---|
| 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 | Default |
|---|---|---|---|
| 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 | Default |
|---|---|---|---|
| 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.
11 tool updates
v0.2.3- First observed
propline_get_event_ev - First observed
propline_get_event_results - First observed
propline_get_event_stats - First observed
propline_get_odds - First observed
propline_get_odds_history - First observed
propline_get_player_history - First observed
propline_get_resolution_summary - First observed
propline_get_scores - First observed
propline_list_event_markets - First observed
propline_list_events - First observed
propline_list_sports
TDQS
A4.1/5.0
Scored across 11 tools
Disambiguation5/5
Each tool targets a distinct data layer: discovery (sports/events/markets), odds retrieval (current/history), game outcomes (scores/stats/results), and analysis (EV/player history/coverage). Even the completed-event tools are cleanly separated between raw box-score stats and graded prop resolutions.
Naming Consistency5/5
All tools share the propline_ prefix and follow a clear list_ pattern for discovery endpoints and get_ pattern for data retrieval endpoints. Noun targets are consistent and readable, with compound names like event_markets and odds_history following the same convention.
Tool Count5/5
Eleven tools is well-scoped for a sports prop data API, covering discovery, odds, scores, historical data, and resolved outcomes without unnecessary duplication. Each endpoint earns its place and supports a clear workflow.
Completeness5/5
The surface covers the full read-only lifecycle: discover sports/events/markets, fetch current and historical odds, retrieve scores and box-score stats, and access graded outcomes, player history, and +EV analysis. No obvious dead ends or missing core operations exist for the stated domain.
Maintenance
ActivityActive
ResponsivenessNo issues
Related MCP Connectors
Real-time sports betting data: odds, player props, edges and arbitrage from 35+ books and DFS apps.
Sports betting odds, player props, scores, betting splits and history from 30+ sportsbooks
NBA/WNBA betting analytics: live odds, sharp fair prices, injuries, and prop verification.
Sports odds, player props and source coverage for AI assistants. Connect with your own API key.
Related MCP Servers
- AlicenseAqualityDmaintenanceProvides 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.1125 PyPI5MIT
- AlicenseAqualityBmaintenanceMCP server for German public procurement data (OCDS). Semantic search, tender matching, and company profiles — all from your local LLM105MIT
- AlicenseNot gradedqualityDmaintenanceProvides betting intelligence and analytics tools including exposure, CLV, sharp scoring, live betting, and Fantasy402 integration, running on Cloudflare Edge.8MIT