olympus-bets-analytics

get_player_props

Read-onlyIdempotent

Return the live player-props board for NFL, MLB, WNBA, NBA or NHL (MCP Connect or Pro).

Requires ``Authorization: Bearer obmcp_...`` (MCP Connect — included with
website Premium — or MCP Pro). Free and anonymous callers are denied.

Each prop row carries: player, team, game, kickoff (America/New_York),
market, line, model projection, model over/under probability, the stored
best price and book (plus other books where the odds file stores them),
edge_pct, the model's pick side, confidence tier and units where the lane
produces them, whether it is on the lane's premium board, and
``lane_status`` — the factual verdict of that lane's promotion gate
(e.g. NFL ``research_board``, WNBA ``promoted_live``, NHL
``stays_dark``, MLB per market, NBA ``per_cell``: an NBA edge is shown
only for a market x side cell the lane's gate has published).
lane_status is information, not a filter: every row is returned.

NBA and NHL also carry ``over_prob``/``under_prob`` at the row's line and
``model_prob_basis`` (how that probability was produced; ``"none"`` when
the lane has no probability for the line, and then the probability fields
are null: never interpolated or approximated).

``lines="all"`` (NBA and NHL only) returns every line a US-executable book
quotes for each player x market (main line plus the alternate rungs,
e.g. NBA points 14.5/19.5/24.5/29.5, NHL shots 2.5/3.5), one row per
line: ``is_main_line`` marks the board's main line, the best
US-executable over and under price with its book, the model's over/under
probability at that line where the lane stores one, and
``over_edge_pct``/``under_edge_pct`` = model probability minus the
price's vig-included break-even, in percentage points, only where both
exist. NBA alternates are Over-only at the books. At most 30 lines per
player x market; rows sorted by kickoff, game, player, market, line.

Prices are exactly as stored by the odds pipeline; a missing price is
``null`` (never a placeholder). MLB rows come from the daily MLB props
export: the MLB ledger stores no pick side for player props, so
``pick_side`` is null and ``edge_pct`` is the stored OVER-side edge
(``edge_side: "over"``).

Args:
    league: ``nfl``, ``mlb``, ``wnba``, ``nba`` or ``nhl`` (required).
    date: ``YYYY-MM-DD`` slate date in the live window — yesterday through
        7 days ahead (America/New_York); defaults to today. Earlier dates
        are resolved history: use ``get_player_prop_history`` (MCP Pro).
    game: Optional matchup/team filter (e.g. ``"NE@JAX"``, ``"JAX"``).
    player: Optional player-name filter (substring, accent-insensitive).
    market: Optional market filter (e.g. ``rush_yds``, ``points``,
        ``pitcher_ks``).
    limit: Max rows (1-200, default 100), sorted by edge_pct descending
        (``lines="all"``: by kickoff, game, player, market, line).
    lines: ``"main"`` (default: each lane's board) or ``"all"`` (NBA/NHL:
        one row per quoted line).

Input Schema

Name	Required	Default
`date`	No
`game`	No
`limit`	No
`lines`	No	main
`league`	Yes
`market`	No
`player`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / lines

Added value: +{
+  "default": "main",
+  "title": "Lines",
+  "type": "string"
+}

AddedSep 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations cover readOnly/idempotent, and the description adds substantial context beyond them: the required Bearer token and denial of free/anonymous callers, null-never-placeholder price semantics, the 30-line cap per player x market, sort order, and that over_prob/under_prob are null rather than interpolated. This is exactly the kind of behavioral detail the annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but dense and front-loaded: the resource and auth gate come first, then return fields, then the lines='all' branch, then args. Some prose (e.g. the extended lane_status parenthetical, the NBA alternate detail) could be tightened, but each block conveys distinct information rather than repeating the schema.

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?

An output schema exists, so return values needn't be enumerated, yet the description explains the row shape, the league-specific extras, and the semantics of edge_pct for MLB. Combined with full parameter coverage and auth disclosure, an agent has everything needed to call this correctly.

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

Parameters5/5

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

Schema coverage is 0%, so the description carries the full burden and does: league values enumerated, date window (yesterday through 7 days ahead, America/New_York, default today), game filter formats with examples, player as accent-insensitive substring, market examples, limit range (1-200, default 100) with sort semantics, and the two lines modes. Every parameter is documented beyond the bare schema types.

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?

Opens with a specific verb+resource+scope: 'Return the live player-props board for NFL, MLB, WNBA, NBA or NHL', naming the exact leagues supported and the tier gate (MCP Connect or Pro). Distinguishes it from history sibling by noting earlier dates resolve to get_player_prop_history.

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?

Explicit routing for the history case ('Earlier dates are resolved history: use get_player_prop_history (MCP Pro)') and clarifies that lane_status is informational, not a filter. No guidance on when to prefer this over board-oriented siblings like get_oracle_board or get_premium_slate, so not a full 5.

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

All olympus-bets-analytics tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.