olympus-bets-analytics

get_player_prop_history

Read-onlyIdempotent

Return resolved player props for NFL, MLB or WNBA (MCP Pro only).

Rows carry the projection, line, stored price, side, actual stat and
outcome (plus stored units/units_won where the lane logs them). The
summary counts overs and unders separately. It gives row counts only: no
units, ROI or hit-rate totals, because the site publishes no track record
for these props ledgers to match.

NFL and WNBA read each lane's props ledger. MLB reads the per-date history
shards written by the daily MLB props export; MLB rows have no stored pick
side, so their summary counts where the actual stat landed vs the line.

Args:
    league: ``nfl``, ``mlb`` or ``wnba`` (required).
    date_from / date_to: ``YYYY-MM-DD`` inclusive range, at most 31 days
        (at most 7 days for MLB without a player or market filter).
        Defaults to the 7 days ending yesterday (America/New_York).
    player: Optional player-name filter (substring, accent-insensitive).
    market: Optional market filter (substring, e.g. ``pass_yds``).
    recommended_only: Keep only rows the lane recommended. Every NFL
        ledger row is a model pick; the WNBA ledger also holds both sides
        of every graded candidate (shadow rows), so its unfiltered over and
        under counts mirror each other; MLB rows carry no pick flag, so
        this returns no MLB rows.
    limit: Page size (1-200, default 100).
    cursor: Row offset from a previous response's ``next_cursor``.
    include_alt_lines: NFL only. The NFL ledger logs one row per priced
        alternate line; by default each player-market-side play appears
        once (the line the board would publish) and the summary counts
        plays. ``true`` returns and counts every alt-line row.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`cursor`	No
`league`	Yes
`market`	No
`player`	No
`date_to`	No
`date_from`	No
`recommended_only`	No
`include_alt_lines`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / include_alt_lines

Added value: +{
+  "default": false,
+  "title": "Include Alt Lines",
+  "type": "boolean"
+}

AddedSep 28, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnly/idempotent, yet the description goes well beyond them: it discloses the exact row fields, that the summary counts overs/unders separately, that it deliberately omits units/ROI/hit-rate because no track record matches these ledgers, and that MLB rows lack a stored pick side so their summary is computed differently. This is exactly the behavioral context an agent needs.

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 first sentence states the core purpose, then return shape, then caveats, then args. Every sentence carries information, though the return-shape paragraph and args repeat some framing and could be tightened slightly.

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?

For a 9-parameter, league-varying tool with an output schema present, the description covers scope, per-league quirks, pagination, defaults, and what the summary does and does not contain. Nothing an agent needs to invoke it correctly appears to be missing.

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 description coverage is 0% across 9 parameters, and the description fully compensates: date format (YYYY-MM-DD), inclusive range and 31/7-day caps, default range (7 days ending yesterday, America/New_York), substring/accent-insensitive filters, limit bounds 1-200 default 100, cursor semantics, and the meaning of include_alt_lines and recommended_only per league.

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 and resource ('Return resolved player props') scoped to NFL/MLB/WNBA, and the word 'resolved' plus 'history' distinguishes it from the live sibling get_player_props. An agent can identify the tool's role without reading the schema.

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?

Gives substantial conditional guidance: MCP Pro only, per-league date-window limits, and league-specific behavior for recommended_only and include_alt_lines. It never explicitly names an alternative sibling (e.g., get_player_props for un-resolved props), so routing is left partly to inference.

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.