de en es ja ko ru zh

PropLine

Name: PropLine
Author: proplineapi

Official

by proplineapi

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

propline-mcp

npm version License: MIT

Listado en el MCP Registry oficial como io.github.proplineapi/propline-mcp — visible desde Claude Code, Claude Desktop y cualquier cliente compatible con MCP.

Servidor del Model Context Protocol para la API de cuotas de apuestas de player props de PropLine. Conéctalo a Claude Desktop, Claude Code o cualquier cliente compatible con MCP y haz preguntas en lenguaje natural sobre cuotas en vivo, resolución de props, EV+ entre casas, marcadores y estadísticas de box-score — el modelo elige la herramienta correcta, llama a la API y responde con datos reales.

Se acabaron las evasivas de "necesitaría una API para eso" por parte de tu asistente de IA. PropLine MCP convierte la investigación de apuestas deportivas en un chat.

Lo que puedes preguntar

Una vez instalado, puedes pedirle al modelo cosas como:

"¿Cuál es el EV+ de Yankees vs Red Sox esta noche en todas las casas?"
"Trae el historial de las últimas 20 apuestas prop de Aaron Judge con resultados de acierto/fallo."
"Lista lado a lado los props de strikeouts de lanzadores de la MLB de hoy de DraftKings y Pinnacle."
"¿Acertó el prop de puntos de Nikola Jokic anoche? ¿Cuál era la línea?"
"Compara las proyecciones DFS de PrizePicks con las líneas de Bovada para la cartelera de la NBA de esta noche."
"¿Cuál es el total del primer cuarto en Lakers vs Celtics y qué casa tiene el mejor Over?"

El modelo utiliza estas herramientas de forma transparente:

Herramienta	Qué hace
`propline_list_sports`	Descubre los deportes que PropLine cubre (54 hoy)
`propline_list_events`	Próximos eventos de un deporte, con IDs
`propline_list_event_markets`	Tipos de mercado disponibles para un evento
`propline_get_odds`	Cuotas en directo — masivas por deporte o todas las props por evento. Acepta `period` (q1/h1/p1/f5/…) para acotar a mercados de períodos de juego.
`propline_get_odds_history`	Hobby+: historial de instantáneas por resultado; admite `period` (q1/h1/…) y filtros de ventana de tiempo (from/to, relative_from/relative_to, interval, changes_only)
`propline_get_odds_closing`	Hobby+: línea de apertura y de cierre por (book, market, outcome) — herramienta de CLV. Acepta `period` para acotar a un período específico del partido.
`propline_grade_clv`	Hobby+: califica las apuestas colocadas contra sus líneas de cierre. Devuelve el precio de cierre, el valor justo de cierre sin margen (`fair_source` = la casa más sharp al cierre, no la tuya), `clv_pct` (precio contra precio, ignorando el margen) y `ev_vs_close_pct` (el número honesto), además del resultado calificado cuando el partido se resuelve. Emparejamiento a prueba de fallos; los eventos no iniciados devuelven `closing_is_final: false` y se excluyen de los promedios.
`propline_export_odds_history`	Backfill-pass / Enterprise: historial masivo de ticks de movimiento de línea (cada instantánea, por casa) para un deporte. Requiere una ventana `since`/`until`; el resultado está limitado a 200 filas (usa el endpoint REST directamente para el archivo completo).
`propline_get_futures`	Futuros de temporada — ganadores de campeonato/división/conferencia, MVP + premios, totales de victorias de temporada — en Bovada/FanDuel/DraftKings/Pinnacle (gratis)
`propline_get_scores`	Marcadores de partidos + estado (gratis)
`propline_get_dfs_payouts`	Programa de pagos PrizePicks Power/Flex + probabilidad de ganancia en el punto de equilibrio por selección (gratis)
`propline_get_mlb_grand_salami`	Grand Salami MLB diario sintético — total de carreras + línea implícita de cada casa (gratis)
`propline_get_nhl_daily_goals_total`	Total de goles NHL diario sintético — el Grand Salami del hockey (gratis)
`propline_get_resolution_summary`	Volumen de props calificadas + desglose por deporte/mercado (gratis)
`propline_get_event_stats`	Estadísticas de box-score en bruto (gratis, independiente de la casa de apuestas)
`propline_get_event_context`	Condiciones del partido bajo las que se resuelve una prop — lanzadores probables, indicador de alineación, árbitro del plato, clima del primer lanzamiento (gratis)
`propline_get_event_movement`	Movimiento de línea + detección de steam (señal de dinero sharp en todas las casas) a partir del historial de ticks (Hobby+)
`propline_get_event_results`	Pro: ganadas/perdidas/push calificadas por prop
`propline_get_player_history`	Historial de props de jugador con resolución
`propline_get_player_games`	Registro de partidos del jugador — partidos recientes con cada estadística de box-score en bruto por partido, una llamada en lugar de una por evento; `opponent` da el cara a cara (últimos N enfrentamientos). Archivo de estadísticas en bruto, por lo que incluye partidos que ninguna casa ha cotizado
`propline_get_player_trends`	Tendencias de tasa de aciertos — desgloses over/under/push en los últimos 5/10/20/50 partidos calificados, racha, promedio real (opcional `dfs_odds_type` para acotar a una variante de PrizePicks)
`propline_get_event_ev`	Pro: +EV entre casas con líneas justas sin margen
`propline_get_best_line`	Hobby+: comparación de líneas entre casas — mejor precio por (market, player, line) entre todas las casas comparables, `all_prices` ordenados de mejor a peor; filtro `bookmakers` opcional
`propline_list_webhooks`	Streaming Lite+: lista las suscripciones de webhooks (solo lectura, secretos enmascarados)
`propline_get_webhook_deliveries`	Streaming Lite+: intentos de entrega recientes para un webhook — estado, código HTTP, intentos, payload; `before_id` pagina hacia atrás. La herramienta del "por qué no se dispara mi webhook"

Related MCP server: Sports Betting MCP

Endpoint alojado (sin instalación)

Las mismas 25 herramientas se sirven a través de Streamable HTTP en

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

Úsalo desde cualquier cliente que admita conexiones remotas — nada que instalar, nada que ejecutar.

Cliente	Cómo
Claude Code	`claude mcp add --transport http propline https://mcp.prop-line.com/mcp`
Claude.ai / Claude Desktop	Configuración → Conectores → Añadir conector personalizado → la URL de arriba
Cursor	Configuración → MCP → Añadir servidor → escribe `http`, la URL de arriba (un clic)
ChatGPT (modo desarrollador)	Configuración → Conectores → Crear → la URL del servidor MCP de arriba
Cualquier cliente	Streamable HTTP, endpoint `/mcp`; `GET /` devuelve un manifiesto JSON

La autenticación es por solicitud. Envía tu clave de PropLine como Authorization: Bearer <key> (o X-API-Key: <key>, o ?apiKey=<key> para clientes que no pueden configurar cabeceras). Sin clave, el endpoint recurre a la clave de demostración gratuita compartida — todas las herramientas funcionan, las funciones de pago están enmascaradas y los límites se comparten. Las claves se usan solo para esa solicitud y nunca se almacenan.

Claude Code con tu propia clave:

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

La versión stdio que aparece abajo (npx -y propline-mcp) es el mismo código; elige la que prefiera tu cliente.

Inicio rápido sin configuración

No necesitas clave para probarlo. El servidor recurre a una clave de demostración pública compartida, así que esto funciona directamente:

npx -y propline-mcp

Tu agente puede obtener al instante cuotas, marcadores y estadísticas en vivo. La clave de demostración es de nivel gratuito y compartida — las funciones de pago (resolución, +EV, historial, exportaciones) devuelven una vista previa con datos enmascarados, y los límites se comparten entre todos. Para acceso completo y límites propios, configura PROPLINE_API_KEY (abajo). Obtén una clave personal gratuita en prop-line.com.

Instalación (con tu propia clave)

1. Obtén una clave de API de PropLine

prop-line.com — el nivel gratuito incluye 1.000 solicitudes/día, sin tarjeta de crédito. Hobby por 9 $/mes desbloquea resolución, historial, líneas de cierre y +EV — Pro por 19 $/mes es ese mismo conjunto de funciones con 25.000 solicitudes/día.

2. Añádelo a tu cliente MCP

Claude Desktop

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

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

Reinicia Claude Desktop. El icono del martillo debería mostrar las 25 herramientas de PropLine. (O sáltate la instalación y añade https://mcp.prop-line.com/mcp como conector personalizado — consulta el endpoint alojado más arriba).

Claude Code

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

Cualquier otro cliente MCP

Ejecuta propline-mcp como servidor stdio. La mayoría de los clientes aceptan un comando y variables de entorno. Consulta la especificación MCP para la configuración específica de cada cliente.

Configuración

Variable de entorno	Requerida	Por defecto	Notas
`PROPLINE_API_KEY`	no	clave de demostración compartida	Sin definir = clave de demostración gratuita compartida (funciones de pago enmascaradas, límites compartidos). Configura tu propia clave gratuita desde prop-line.com para acceso completo.
`PROPLINE_BASE_URL`	no	`https://api.prop-line.com`	Anulación para instalaciones autoalojadas

Comparación con the-odds-api

PropLine es compatible con la API a nivel de respuesta (misma estructura bookmakers[].markets[].outcomes[]) y añade tres cosas que the-odds-api no ofrece en ningún plan:

Resolución de props — cada Over/Under evaluado contra la estadística real del box score después del partido
+EV entre casas — líneas justas sin margen ancladas a Pinnacle para cada casa, ordenadas con las jugadas +EV arriba
Webhooks — entrega push en el plan Streaming, no solo pull

Precios: gratis con 1.000 solicitudes/día (frente a sus 500/mes), Hobby por 9 $/mes con 5.000 solicitudes/día, Pro por 19 $/mes con 25.000 y Streaming por 79 $/mes con 1.000.000. Sin cálculos de créditos.

Enlaces

Endpoint MCP alojado: https://mcp.prop-line.com/mcp (Streamable HTTP)
Política de privacidad: prop-line.com/privacy
Sitio web: prop-line.com
Documentación de la API: prop-line.com/docs
Recetas (código para tareas comunes): prop-line.com/recipes
API de cuotas por deporte y mercado (línea en vivo, casas, tasa de acierto con resolución): prop-line.com/odds-api
Resolución de props (cada prop evaluado contra el box score): prop-line.com/prop-resolution-api
+EV entre casas: prop-line.com/ev
Precios: prop-line.com/pricing
Panel de control: prop-line.com/dashboard
Referencia de OpenAPI: api.prop-line.com/docs
Para agentes de IA (llms.txt, configuración de MCP): prop-line.com/for-ai-agents
SDK de Python: pip install propline
SDK de Node: npm install propline

Licencia

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.

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

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-09-09 18:46 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

Resources

Need Help?

Related Servers

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
Owls Insight
com.owlsinsight
Sports betting odds, player props, scores, betting splits and history from 30+ sportsbooks
Sports Games & Gamification Finance
1
Nightly MCPOAuth
io.github.bakaburg24
NBA/WNBA betting analytics: live odds, sharp fair prices, injuries, and prop verification.
Sports Finance Research & Data
1
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 10 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 6 months ago (2026-04-08 03:01 UTC)
11
25 PyPI
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 3 months ago (2026-07-26 10:13 UTC)
10
5
MIT
betting-brain-v3
Sports Finance
brendadeeznuts1111
A
license
Not graded
quality
D
maintenance
Provides betting intelligence and analytics tools including exposure, CLV, sharp scoring, live betting, and Fantasy402 integration, running on Cloudflare Edge.
Updated 9 days ago (2026-10-07 09:08 UTC)
8
MIT

Appeared in Searches

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