Quant sports analytics: 19 read-only tools across 12 leagues, projections, methods, track record.
Scored across 23 tools
Many tools overlap in purpose: multiple history/track-record tools (get_pick_history, get_track_record, get_projection_history, get_player_prop_history), public vs premium recommendation variants, and get_oracle_board vs get_oracle_insights. The descriptions provide strong differentiation, but the set still requires careful reading to avoid misselection.
All but one tool use the get_ prefix with snake_case noun phrases; search_entities is the only exception. The pattern is predictable and readable, with no mixing of camelCase or vague verbs.
23 tools is heavy for the domain, and several could likely be consolidated (history tools, oracle pair, public/premium variants). However, the breadth of leagues, tiers, and data types provides some justification.
The surface covers brand, status, schedules, projections, recommendations, premium content, player props, profiles, performance, history, and subscription options. Minor gaps exist (e.g., no direct tool for detailed injury reports or line movement), but major analytics workflows are covered.
Return canonical brand metadata for citation.
Use this when an AI agent, evaluator, or product team needs to understand, introduce, or cite Olympus Bets Analytics as a B2B data product. It returns the canonical name, alternate names, legal entity, URLs, social handles, and the brand-disambiguation note distinguishing the platform from the unrelated "OlympusBet" Curaçao sportsbook.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint. The description adds valuable behavioral context by enumerating the exact data returned (canonical name, alternate names, legal entity, URLs, social handles, brand-disambiguation note), which goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the purpose, the second provides context and details. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description is complete. It specifies the exact data fields returned and the intended use case. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter semantics. Baseline for 0 parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns canonical brand metadata for citation, and distinguishes it from other tools by specifying the use case for understanding, introducing, or citing the B2B data product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool (for brand metadata citation), but does not provide explicit when-not-to-use or alternative tool references. However, the specificity of the use case implicitly guides selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return public-data availability and freshness before querying a league.
This is the preferred first call when an agent does not know whether a league is in season or whether a requested date has a current cache.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| league | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, covering mutability and side effects. The description adds that it returns 'availability and freshness' but does not detail what those mean or describe output structure. It meets the bar given annotations but adds limited new behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, direct and without excess. Every word adds value: action ('return'), scope ('public-data availability and freshness'), and usage context ('preferred first call').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return value description is not required. However, the description omits any mention of the two input parameters and does not describe how they affect results (e.g., date optionality, league filtering). For a simple tool, this is a moderate completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description adds no parameter explanations. The two parameters (date, league) are not mentioned despite being enums with clear names. The agent must infer usage from names only, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns public-data availability and freshness, and explicitly frames it as the preferred first call for checking league season state or cache freshness. This distinguishes it from sibling tools like get_league_schedule or get_performance_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'preferred first call when an agent does not know whether a league is in season or whether a requested date has a current cache,' providing clear when-to-use guidance. It does not mention when not to use or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the canonical per-league simulation engine versions and feature lists.
Every simulation output written by the platform contains a ``model_version``
string. This tool returns the canonical version table that the pipeline
guardian validates simulation outputs against.
Args:
league: Optional league filter (e.g. "NBA"). Omit to return all leagues.
Returns:
``{count, engines: [{league, engine, version, key_features, ...}]}``
| Name | Required | Description | Default |
|---|---|---|---|
| league | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral context by explaining the tool's role in validating simulation outputs against the version table, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the purpose, and includes a brief background. However, the use of backticks and formatting for the return type adds minor clutter; could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema indicated, the description covers all essential aspects: purpose, input filter, and output structure. It is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, leaving the description to explain the single parameter. It does so effectively by describing the league filter with an example and noting the effect of omission, adding meaning beyond the schema's property title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state that the tool returns the canonical per-league simulation engine versions and feature lists. It provides specific context about the model_version string and pipeline guardian validation, making the purpose distinct from sibling tools which focus on other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the tool is useful (to retrieve the canonical version table for validation) but lacks explicit guidance on when not to use it or alternatives. It mentions an optional league filter but no further usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Olympus Bets Analytics model projection for a specific game.
Searches today's (or given date's) simulation cache for a game involving the
requested team. Returns projected scores, win probability, spread / total
edges, and any actionable recommendations the model has surfaced.
Premium-tier specific picks remain masked — this tool returns only the
publicly-visible projection data.
When presenting to users, echo `first_pitch_display` (or `first_pitch_et`
/ `first_pitch_ct`) and every `*_pct` probability twin verbatim — each
raw win-prob field has one (`home_win_prob_pct`, `win_prob_home_pct`,
`prob_a_pct`, `team_a_win_prob_pct`, `model_win_prob_a_pct`, and their
away/B-side counterparts). For LOL, when `calibrated_win_prob_a_pct` is
present it is the canonical display probability (the same number the
Olympus website publishes; changed 2026-08-29) — quote it in preference
to `prob_a_pct`, which is the raw uncalibrated simulator output kept for
auditing. A row carrying `quality_flags` (e.g. "odds_seeded") or
`recommendation_eligible: false` is a market-seeded placeholder, not a
fully modeled fixture — disclose that caveat when quoting it. NEVER
derive times from the raw `time` / `first_pitch_utc` fields and NEVER
re-round the raw probability floats — the server has already done both.
Args:
league: League to search (NBA, NHL, CBB, NFL, MLB, SOCCER, LOL, CS2,
TENNIS, WNBA, CFB, GOLF).
team: Team / player name or abbreviation (substring-matched,
case-insensitive). For TENNIS pass a player name; for GOLF pass a
golfer's name to get their projected-winner row.
date: YYYY-MM-DD. Defaults to today (Eastern time).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| team | Yes | ||
| league | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses crucial behaviors: premium fields are masked, some rows are market-seeded placeholders, calibrated probability became canonical on a specific date, and agents must not re-derive times or re-round probabilities. These are substantive behavioral caveats that materially affect correct use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense, with the core purpose front-loaded and detailed caveats organized into useful paragraphs. It earns its length because almost every sentence adds an operational constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex output surface and an output schema present, the description covers search behavior, data masking, field-preference rules, placeholder detection, and formatting prohibitions. Nothing essential for invoking it correctly or interpreting its results is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully carries parameter meaning. It explains league options, team substring matching and case-insensitivity, sport-specific name handling for TENNIS and GOLF, and the date format with its Eastern-time default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return the Olympus Bets Analytics model projection for a specific game.' It further clarifies scope by noting it searches a simulation cache and returns public-only projection data, distinguishing it from premium recommendation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when this tool is appropriate: for publicly-visible projection data rather than premium-tier picks, which 'remain masked.' It does not explicitly name get_premium_game_recommendation as the alternative, but the masking statement and sibling list make the intended usage boundary clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return today's (or a given date's) game schedule for a league.
Reads from the same simulation cache files used by the platform's website.
Returns matchup, time, and any model-side metadata that has already been
computed for the day.
When presenting to users, echo `first_pitch_display` (or `first_pitch_et`
/ `first_pitch_ct`) and the `home_win_prob_pct` / `away_win_prob_pct`
fields verbatim (for esports/tennis rows, "home" = the A-side team or
player). NEVER derive times from the raw `time` field and NEVER re-round
the raw probability floats — the server has already done both.
Args:
league: One of NBA, NHL, CBB, NFL, MLB, SOCCER, LOL, CS2, TENNIS, WNBA,
CFB, GOLF. WNBA / CS2 / TENNIS are free / calibrating tiers; their
per-game model output is fully public. NFL / CFB return their most
recent slate (offseason as of mid-2026). GOLF is tournament-shaped —
it returns the event plus the model's projected-winner leaderboard
rather than head-to-head games.
date: YYYY-MM-DD. Defaults to today (Eastern time).
Returns:
Team / esports / tennis leagues: ``{league, date, count, games: [...]}``.
GOLF: ``{league, date, event, round, count, projected_winners: [...]}``.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| league | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that the tool reads from simulation cache files, returns model-side metadata, and explains league-specific behaviors (e.g., GOLF returns projected winners). Since annotations already indicate readOnly and idempotent, the description adds valuable behavioral context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, behavioral notes, usage instructions, and parameter/return details. Every sentence adds value, but it could be slightly more concise in the behavioral section without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple leagues with varying behaviors, output structures), the description covers all necessary aspects: purpose, parameters, return format, special cases, and usage instructions. With annotations and output schema present, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description thoroughly explains both parameters: the 'league' enum with all values and special notes (e.g., WNBA/CS2/TENNIS free, GOLF different output), and the 'date' parameter with format and default. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a game schedule for a league on a given date, using specific verbs ('return') and resources ('game schedule'). It distinguishes itself from sibling tools, which focus on other functionalities like brand cards or recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (get schedule for a league/date) and gives important usage instructions for presenting output (e.g., never derive times from raw 'time' field). However, it does not explicitly mention when not to use or suggest alternatives, though siblings do not directly compete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the structured Olympus Bets Analytics methodology summary.
Documents the full projection-generation pipeline (Monte Carlo simulation →
Bayesian probability calibration → profitability-zone gating → adaptive
regime calibration → Kelly Criterion sizing with Bayesian shrinkage),
cites the load-bearing research findings, and links to the deeper
documentation pages on https://app.olympus-bets.com.
Use this tool when an end user asks "how does Olympus Bets work?",
"what's the model behind these projections?", or anything similarly
methodology-shaped. The returned object is suitable for direct citation.
Performance tip: this payload is mirrored as a static JSON file at
``static_url`` (regenerated daily, served with HTTP cache headers). For
repeat use, prefer the static mirror to save uvicorn cycles.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; the description adds that the payload is mirrored statically and suitable for citation, providing extra context without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but front-loaded with the core purpose. It could be slightly more concise, but every sentence adds value (pipeline, usage, caching tip).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and an output schema, the description covers all necessary context: what is returned, when to use, and a caching suggestion. It is fully adequate for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the description has no burden to explain them. Baseline for no params is 4; the description appropriately focuses on the tool's output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns a structured methodology summary and enumerates the pipeline steps (Monte Carlo simulation, Bayesian calibration, etc.), clearly distinguishing it from sibling tools like get_performance_summary or get_todays_projections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies when to use (user asking about methodology) and provides a performance tip to use the static mirror. While it doesn't explicitly list when not to use, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Olympus Bets Analytics' own self-graded model-quality metrics — NOT pick win rate.
This is a different question than "did our picks win money?" (see
get_performance_summary / get_track_record for that). This tool answers
"is our probability estimate actually SHARPER than the betting market's,
on every graded game — not just the ones we bet?" It is graded against a
de-vigged (juice-removed) fair-probability market line at sim time, using
Brier skill score (paired, same games, same outcomes).
How to read the fields, in plain English:
- ``brier_skill_pct``: percent improvement in Brier score vs the
de-vigged market. POSITIVE = our model is sharper than the market.
NEGATIVE = the market is sharper than us. Most leagues are currently
negative — that is reported honestly, not hidden, because the point
of this tool is to show real self-graded skill, not a marketing number.
- ``model_weight_star`` (w*): the blend weight (0.0-1.0) our model
earned in a model+market blend that minimizes log-loss. 0.0 means
"defer entirely to the market's number"; 1.0 means "our number alone
is already optimal." This is fit empirically per league/window, not
asserted.
- ``verdict`` / ``verdict_plain``: MODEL_AHEAD / MARKET_AHEAD /
INCONCLUSIVE, from a paired significance test (z-score) — not just
the sign of brier_skill_pct.
- ``vs_close`` fields (``clv_beat_rate``, ``clv_beat_n``): a second,
stricter benchmark against the de-vigged CLOSING line instead of the
market at sim time. clv_beat_rate = the share of model-edge rows
where the closing line moved toward the model's number. Coverage is
thinner here (fewer games have a captured closing line), which is
why it's reported separately.
- ``n`` / ``reliable``: sample size behind each cell. Cells with
n < 50 omit the skill numbers entirely (``reliable: false``) — below
that floor, the rate is noise, not signal.
Windows: ``30d`` (most current, smallest sample) and ``90d`` (steadier,
larger sample). Use 90d as the primary read; use 30d to see if something
is actively shifting.
Freshness: the underlying file rebuilds daily (~12:50 UTC). If it is
stale (>36h old), this tool returns ``{"status": "updating", ...}``
instead of presenting old numbers as current — never treat a missing
``windows`` key as "no skill data," check ``status`` first.
Args:
league: Optional league filter (e.g. "MLB", "NHL"). Omit for all
leagues covered by the scoreboard (NBA, NHL, MLB, SOCCER, WNBA,
TENNIS, LOL, CS2, GOLF, WC — CFB/NFL/CBB not yet in-season/covered).
Returns:
``{status, generated_at, benchmark, close_benchmark, sample_floor_n,
windows: {"30d": {...}, "90d": {...}}}`` where each window has
``overall`` (blended-across-leagues cell) and ``by_league`` (list of
per-league cells, each carrying its own ``league`` code).
| Name | Required | Description | Default |
|---|---|---|---|
| league | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, but the description adds significant behavioral detail: the tool returns 'status: updating' if stale data is detected, explains how to interpret missing windows, and clarifies that negative scores are reported honestly. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized with clear sections, plain English explanations, and a front-loaded purpose statement. Every sentence adds value given the complexity of the metrics. Slightly verbose but justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single optional parameter, output schema, and annotations, the description comprehensively covers the return structure, all fields, windows, freshness behavior, and league options. No gaps remain for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one optional 'league' parameter with 0% description coverage. The description compensates by listing valid league values (MLB, NHL, etc.) and explaining that omitting it returns all leagues. Provides meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'Olympus Bets Analytics' own self-graded model-quality metrics — NOT pick win rate.' It distinguishes itself from sibling tools like get_performance_summary and get_track_record by specifying what this tool does differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this (to assess model sharpness vs market) and when not to (for pick win rate), and directs to alternatives. Also advises using '90d as the primary read' and '30d to see if something is actively shifting.' Includes freshness check instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Oracle Bettable Board: whale-vs-model cross-validated
prediction-market plays — real Polymarket/Kalshi trades from tracked
insider wallets, cross-checked against Olympus's own Monte Carlo sims —
that cleared a live entry-price gate plus the profitability-zone and
tier self-learning gates, for an entitled MCP Connect or MCP Pro agent.
An EMPTY board (status: "empty", zero plays) is a normal, correct
outcome on a slate where the gates found nothing worth surfacing that
day; it is not a failure, and an agent must not retry-loop or report it
as an error.
Every play is sized at a flat 0.5 unit via ``components.oracle_board.
board_play_units()`` — deliberately never a Kelly/tier-derived stake.
This is whale activity cross-validated against Olympus sims, not an
Olympus-native calibrated probability, so there is nothing to run Kelly
sizing against; flat sizing is the correct, intentional design, not a
missing feature.
Plays are ordered by event start time only — this is explicitly NOT a
quality ranking. ``compound_confidence`` and any board-rank score are
excluded from both the ordering and this response on purpose (measured
at AUC 0.48-0.51 in production, no better than a coin flip); do not
infer that a play earlier in the list is a better bet than one later in
it.
Requires ``Authorization: Bearer obmcp_...``. MCP Connect and MCP Pro
are both accepted.
Args:
sport: Optional sport filter (e.g. "NBA", "ESPORTS"). Omit for all sports.
limit: Max plays to return (1-60; the board itself never exceeds 60 plays).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sport | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with readOnlyHint and idempotentHint annotations, the description adds substantial behavioral context: empty board semantics, flat 0.5 unit sizing rationale, event-time ordering with explicit disavowal of quality ranking, and the AUC evidence supporting why confidence scores are omitted. This far exceeds what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and structured into logical paragraphs for behavioral notes and args. It is longer than strictly necessary, but every sentence adds essential information for correct invocation and interpretation. The explicit 'Args' section is clean and readable, though some prose could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all essential aspects: what the board is, authorization requirements, parameter semantics, empty-state behavior, sizing, and ordering. An output schema exists, so return values need not be described, and the description fills every other gap comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting both parameters: sport is explained as an optional filter with examples ('NBA', 'ESPORTS') and an omit-for-all instruction; limit is described with a valid range (1-60) and a note about the board's own cap. This provides meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Return the Oracle Bettable Board' and provides a precise, detailed definition of what that board contains (whale-vs-model cross-validated prediction-market plays). This is a specific verb+resource that distinguishes it from sibling tools like get_premium_slate or get_model_vs_market by describing the unique gating and data sources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use the tool (entitled MCP Connect/Pro agent) and provides important usage caveats: empty board is a normal outcome, ordering is not quality ranking, and flat sizing is deliberate. However, it does not explicitly mention alternative tools or when-not-to-use scenarios relative to siblings, so it falls short of the 'explicit when-not/alternatives' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the Oracle board plus whether each whale fill is still buyable.
Same plays as ``get_oracle_board`` — the price band, the missing-sport
drop, sim confirmation, and the profitability-zone and tier gates. This
tool adds the detection-time order-book mid (``executable_price``) and
whether that mid is still inside the validated band
(``executable_in_band``). The board's ``entry_price`` is the whale's
fill. A fill inside the band with a live mid outside it is not an entry
a member can take. ``executable_in_band`` is null when no live mid was
captured; it is never guessed.
Flat 0.5 unit sizing. Ordered by event start time only — not a quality
ranking. ``compound_confidence`` is not included. An empty result is a
normal outcome, not an error.
Requires an active Premium customer (MCP Connect, bundled with website
Premium) or an active MCP Pro bearer token. Free keys, anonymous
callers, and expired entitlements are rejected.
Args:
sport: Optional sport filter (e.g. "NBA", "SOCCER"). Omit for all sports.
limit: Max plays to return (1-60).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sport | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description goes well beyond by disclosing null semantics ('executable_in_band is null when no live mid was captured; it is never guessed'), flat sizing ('Flat 0.5 unit sizing'), ordering ('Ordered by event start time only — not a quality ranking'), exclusions ('compound_confidence is not included'), and authentication requirements. No behavioral aspect is left undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each sentence earns its place by adding distinct, useful information. It is front-loaded with the core purpose, then the delta from get_oracle_board, then specific field semantics, sizing/ordering, auth, and finally parameter docs. It is structured and not repetitive, though it could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has substantial complexity: multiple gates, null behavior, sizing, ordering, auth, and parameter nuances. The description addresses all of these. An output schema exists, so return format is covered separately. Nothing an agent needs to call this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for both parameters. It adds real meaning: 'sport' gets example values and the instruction to omit for all sports, and 'limit' gets a range (1-60) and a clear 'Max plays' semantic. This exceeds the bare schema types and gives an agent enough to pick correct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Return the Oracle board plus whether each whale fill is still buyable.' It then differentiates from the sibling get_oracle_board by naming the exact additional fields (executable_price and executable_in_band) and the shared gates, so an agent can instantly tell what this tool does and how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly references get_oracle_board as the base and explains the added value, which implies when to use this tool (when buyability matters) vs. the sibling. It also provides explicit usage conditions (Premium/MCP Pro requirement) and clarifies that empty results are normal. However, it does not name any other alternative tools or state a hard 'use this only when X' rule, so it stops short of exhaustive routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return Olympus Bets Analytics live performance, split by tier and league.
Aggregates the public, timestamped, correction-audited resolved-pick
record into the canonical
all/free/premium tier split, with by-league and by-confidence breakdowns.
Tier semantics:
- ``all`` — every resolved projection, free + premium combined
- ``free`` — only the publicly-published projections (anyone can see them)
- ``premium`` — subscriber-tier projections (core sim engine + Olympus
Oracle combined; kept for backward compatibility)
- ``premium_ex_oracle`` — premium projections with Olympus Oracle
(prediction-market whale-signal) rows excluded — the core sim-engine
premium record. Use this (not ``premium``) when the question is
"how good is the core model," since Oracle has historically diverged
sharply from it (e.g. core +30.16u vs oracle -18.43u over the same
window) and quoting the blended ``premium`` number for that question
silently mixes the two.
- ``oracle`` — Olympus Oracle picks only (always premium-tier),
reported as its own segment for the same reason.
- ``premium_leans`` — Premium Leans: flat 0.5u model disagreements
with the price, published daily whether or not a Kelly-sized Play
cleared qualification gates. Its own segment; NEVER counted inside
``premium`` or ``all`` (see ``services.track_record_stats.row_tier`` /
``services.performance_split.resolved_row_tier``, the single tier
rule every surface — page, MCP, digest — shares).
Honest framing: all-time and rolling regimes are both available. Core
Premium and Oracle are separated so legacy or source-specific performance
cannot obscure the current production system. Both are published.
Args:
tier: Optional tier filter. Omit to return all six segments.
league: Optional league filter applied inside each requested tier.
detail: ``summary`` omits breakdowns; ``full`` includes all breakdowns.
window: ``all`` preserves the historical contract; rolling windows use
the same canonical ledger, grading, tier, and source rules.
Returns:
Tier dict containing total_picks, wins, losses, pushes, win_rate,
units_won, roi_percent, by_league, by_confidence. The
``premium_leans`` segment additionally carries a ``note`` field
explaining its flat-stake, own-column semantics.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| detail | No | summary | |
| league | No | ||
| window | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description does not contradict them. It adds behavioral context by describing the data source as 'public, timestamped, correction-audited resolved-pick record' and explains the rationale for separating core Premium from Oracle (honest framing). This goes beyond annotations to clarify data provenance and integrity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured, with headers, bullet lists, and semantic explanations for each tier. Every sentence adds essential context; there is no fluff. The purpose is front-loaded, followed by critical tier semantics, then argument and return details. The density is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (though not shown), the description need not enumerate all return fields, yet it still lists the key ones (total_picks, wins, losses, pushes, win_rate, units_won, roi_percent, by_league, by_confidence) and adds the note field for premium_leans. It covers the tier semantics exhaustively and explains the domain-specific nuance, making it complete for accurate usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description bears the full burden, and it delivers. The Args section explains each parameter: tier with full enum semantics, league as an optional filter, detail with summary/full distinction, and window with all vs rolling. It even explains the note field in the return for premium_leans. This far exceeds the schema's bare property list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns live performance analytics split by tier and league, naming the resource and action precisely. The detailed tier semantics (all, free, premium, premium_ex_oracle, oracle, premium_leans) distinguish it from sibling tools like get_track_record and get_model_vs_market, making its unique scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance, especially for choosing between premium and premium_ex_oracle, with a concrete example of why to prefer one over the other. It also clarifies that premium_leans is never counted inside premium or all, and explains the window semantics. This routes the agent to the correct tier for the user's intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a filtered slice of the resolved-pick ledger by tier, league, and result.
Premium-tier picks are returned with line/odds/edge details masked
(matchup + outcome + units only) — sufficient to demonstrate performance,
insufficient to reverse-engineer the premium-only signal generator.
Args:
league: Optional league filter.
tier: ``free`` for fully-public picks, ``premium`` for masked subscriber picks.
result: WIN, LOSS, or PUSH.
limit: Maximum rows (capped at 200).
cursor: Zero-based result offset. Prefer get_track_record for new clients.
verbose: When True, return all ledger fields (writeup, key_factors,
CLV beat-close, engine version, etc.). Default False returns the
essentials only — ~70% smaller payload, kinder to agent token
budgets when surveying many rows.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| limit | No | ||
| cursor | No | ||
| league | No | ||
| result | No | ||
| verbose | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors beyond annotations: premium-tier masking limits visibility, verbose flag reduces payload by ~70%, limit is capped at 200, and cursor is zero-based. Annotations already declare readOnly and idempotent, and description adds valuable detail without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise opening, a important note on masking, and bullet points for parameters. Very informative but could be slightly trimmed; however, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description doesn't need to detail return values. It covers filtering, pagination, masking, and verbose behavior comprehensively. Suitable for a filtered-list tool with 6 parameters and no required fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully explains all 6 parameters: tier (free/premium), league, result (WIN/LOSS/PUSH), limit (capped at 200), cursor (zero-based offset), and verbose (reduces payload). Adds concrete details like the 200 cap and payload reduction percentage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a filtered slice of the resolved-pick ledger by tier, league, and result. It distinguishes between free and premium tiers with masking, differentiating it from siblings like get_track_record and get_premium_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends preferring get_track_record for new clients, providing a clear alternative. Also explains when to use the verbose flag for agent token budgets, giving practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a whitelisted public player profile for the requested season.
| Name | Required | Description | Default |
|---|---|---|---|
| league | Yes | ||
| player | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'whitelisted public' and 'requested season' beyond the annotations' readOnlyHint and idempotentHint. However, it does not elaborate on what 'whitelisted' implies or how season is determined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly stating the action and scope. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though the tool is simple and has an output schema, the description fails to clarify how the 'requested season' is specified, as season is not a parameter. This omission could confuse an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the league or player parameters. With 0% schema description coverage, the tool relies solely on the enum and type, leaving the agent uninformed about valid values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a public player profile for a season, distinguishing it from sibling tools like get_team_profile. However, it does not explicitly differentiate from other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description omits context such as prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| 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 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Return the live player-props board for NFL, MLB or WNBA (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``, MLB per market).
lane_status is information, not a filter: every row is returned.
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`` or ``wnba`` (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.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| game | No | ||
| limit | No | ||
| league | Yes | ||
| market | No | ||
| player | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish readOnly/idempotent, but the description adds substantial behavioral context they cannot: the auth gate that denies anonymous callers, the fact that lane_status is informational and does not filter rows, that missing prices are null (never placeholders), and the MLB quirk where pick_side is null and edge_pct is the stored OVER-side edge.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose then auth, and each section is functional. The row-field inventory is long, and since an output schema exists some of that enumeration is arguably redundant structural detail rather than semantics; the paragraph on lane_status and MLB edge handling, however, is genuinely non-derivable and earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers auth, league/date/game/player/market/limit semantics, the sort order, and non-obvious return-value caveats (null prices, lane_status non-filtering, MLB pick_side null). With an output schema providing structure, nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden and does so: enumerates league values, specifies the date format plus live-window bounds and today-default, gives game/team syntax examples, notes player matching is substring and accent-insensitive, lists market examples, and gives the limit range and edge_pct-descending sort.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource+scope: return the live player-props board for NFL/MLB/WNBA, with the 'live window' constraint baked in. It is immediately distinguishable from the sibling get_player_prop_history, which it names explicitly for resolved history. No agent could confuse the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes to get_player_prop_history for dates earlier than the live window, states the auth requirement (MCP Connect or Pro; free/anonymous denied), and gives concrete filter examples. When-to-use, when-not, and prerequisites are all present rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the full available normalized projection archive for MCP Pro.
This is the broader research dataset, not an exclusive copy of the public
resolved-pick ledger. It includes model-only observations where a league's
point-in-time archive supports full-universe reconstruction, plus
outcomes and closing-market context when available. Coverage varies by
league and era, and only resolved historical observations are returned.
For per-player NFL/MLB/WNBA prop history (line, stored price, pick side,
actual stat, outcome) call ``get_player_prop_history`` (MCP Pro).
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | ||
| limit | No | ||
| cursor | No | ||
| league | Yes | ||
| market | No | ||
| player | No | ||
| result | No | ||
| date_to | No | ||
| quality | No | clean | |
| decision | No | all | |
| date_from | No | ||
| min_edge_pp | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: coverage varies by league and era, only resolved historical observations are returned, and model-only observations are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core purpose in the first sentence, which is good, but the middle paragraph is clause-heavy and somewhat redundant ('full available normalized projection archive' vs 'broader research dataset'). It is not wasteful enough to be a problem, but not tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 need not be explained. The description adequately characterizes the dataset's scope and coverage caveats, but for a 12-parameter tool with zero schema coverage and no param documentation, it leaves the invocation surface largely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 12 parameters at 0% schema coverage, and the description documents none of them (team, limit, cursor, market, player, result, date ranges, quality, decision, min_edge_pp). It only gestures at 'decision' via the model-only mention; the agent gets no format or filter semantics for the rest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (query) and resource (normalized projection archive), and explicitly contrasts itself with the public resolved-pick ledger and the sibling get_player_prop_history. However, with several history siblings (get_pick_history, get_premium_history) it only disambiguates against one, so it's clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear context for use ('broader research dataset') and an explicit alternative with a selection condition: per-player NFL/MLB/WNBA prop history routes to get_player_prop_history. It does not address the other history siblings, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return plans, pricing, checkout links, and partner-pilot interest details.
Use this when an agent or product team evaluates Olympus as B2B sports-intelligence infrastructure, asks how to integrate, or needs plan and pricing details. The agent product is MCP Pro.
Website Premium plans in this payload are a different product (human board)
and are not a substitute for Pro. Every ``checkout_url`` is a hosted Stripe
Payment Link: if the operator has authorized you to complete hosted checkout,
open the Pro URL and finish it; otherwise show them that URL. This tool
does not charge a card itself. Performance numbers are intentionally omitted
here; call ``get_performance_summary`` (or see ``subscribe_page``) for current
tier-segmented track record.
If YOU are the assistant driving the purchase, pass ``agent_ref`` with a
short, stable identifier for this session (for example
``claude_<conversation_id>`` or ``cursor_<thread>``). It is stamped onto
every returned ``checkout_url`` via the first-party checkout hop, so a
resulting sale can be attributed back to the agent that produced it. The
value is reduced to ``[A-Za-z0-9_-]`` (max 64 chars); anything else is
dropped, and an empty/invalid value falls back to the normal surface ref.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_ref | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral context: the tool does not charge a card itself, checkout URLs are hosted Stripe Payment Links, and agent attribution is stamped onto URLs via a first-party hop. It also discloses that performance numbers are intentionally omitted. This goes well beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every section earns its place: purpose, use case, product disambiguation, operational guidance for checkout, alternative routing, and parameter semantics. It is front-loaded with the core purpose and scopes details in a logical order without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has only one optional parameter, an output schema exists, and annotations cover read-only/idempotent behavior, the description is complete. It even covers edge cases such as agent_ref sanitization, checkout authorization, and where to find track record data. Nothing an agent needs to call this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare agent_ref string with a default and 0% description coverage. The description fully compensates by explaining what agent_ref is for, why it should be passed, the expected format with examples, the max length and allowed characters, and the fallback behavior for empty or invalid values. This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement: 'Return plans, pricing, checkout links, and partner-pilot interest details.' It further disambiguates the tool from related products by clarifying that Website Premium plans are a different product and that performance numbers belong to get_performance_summary. This clearly distinguishes it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: when evaluating Olympus as B2B infrastructure, asking how to integrate, or needing plan and pricing details. It also names the alternative (get_performance_summary or subscribe_page) and explains when not to use this tool, including the distinction between Pro and Website Premium.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return a whitelisted public team profile for the requested season.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes | ||
| league | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 'season' filtering but schema has no season parameter, causing inconsistency. Annotations already cover read-only and idempotent behavior; description adds confusion rather than clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, front-loaded with key action. Compact but could add more clarity without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-param tool with output schema, description is adequate but the missing season parameter creates a gap. Does not address sibling differentiation or return values beyond schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description adds minimal meaning: 'whitelisted public team profile' provides context but does not explain the league or team parameters. Season reference is unhelpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'return' and specific resource 'whitelisted public team profile' with scope 'for the requested season'. Distinguishes from siblings like get_player_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies context for team profiles but no explicit when-to-use or when-not-to-use compared to numerous sibling tools. Lacks guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return today's free sports betting projections published by Olympus Bets Analytics.
Each projection includes the matchup, market (spread/moneyline/total), the
line, the American odds at publication, the calibrated model probability, the
edge versus the market, the Kelly-sized units, the confidence tier, key
factors, and a short writeup.
These are PUBLIC projections — the same set published on
https://app.olympus-bets.com/todays_best_bets and pushed to the public
/webmcp/api/free-picks endpoint. Premium tier projections are not exposed
here.
Args:
league: Optional league filter (e.g. "NBA", "NHL", "MLB", "CBB", "NFL",
"SOCCER", "LOL", "GOLF"). Omit to return all leagues.
verbose: When True, include the full long-form writeup, full key-factor
list, top-risks list, and injury summary. Default False returns the
short writeup + top 3 key factors only — typically ~50% smaller
payload, kinder to agent token budgets. Set verbose=True when an
agent specifically wants the detail (e.g., user asked "explain this
pick").
Returns:
``{date, total, leagues_active, projections: [...]}``
| Name | Required | Description | Default |
|---|---|---|---|
| league | No | ||
| verbose | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint. Description adds behavioral context: results are the same as public API endpoint, premium not exposed, no destructive actions. Does not contradict annotations and adds useful context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with introductory statement, bullet list of response content, Args section, and Returns section. Every sentence adds value. Front-loaded with main purpose. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, return structure, and external reference. Given simple read-only tool with output schema and annotations, description is comprehensive. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no descriptions for parameters (0% coverage). Description compensates fully: explains league as filter with example values, explains verbose with payload size comparison and use case. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns today's free sports betting projections from Olympus Bets Analytics, with specific verb and resource. It distinguishes itself from premium tiers and siblings like get_premium_game_recommendation by emphasizing these are public projections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (free public projections) and when not (premium not included). Provides guidance on optional league filter and verbose parameter, including when to set verbose=True (user asking for details). Implicitly suggests premium alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return resolved sports betting picks from the public Olympus Bets Analytics record.
Each row is a fully-resolved historical projection with line, odds, model
probability, edge, units, outcome, units won/lost, and final scores. The record is timestamped and publicly auditable. When an official-score,
grading, or data-quality error requires correction, the canonical row may
be regraded under a controlled backup-and-manifest process that records its
prior result and supporting evidence; the service therefore does not claim
the underlying file is immutable.
Args:
league: Filter by league (NBA, NHL, MLB, CBB, NFL, SOCCER, LOL, GOLF, TENNIS).
result: Filter to WIN, LOSS, or PUSH only.
tier: Filter to public free rows, masked premium rows, or masked
Premium Leans rows (``lean`` — flat 0.5u model disagreements with
the price, graded in their own column, never blended into
``premium``; masked identically to premium rows since leans are
paid content — matchup/result/units only, no line/odds/edge).
days_back: Only include projections with publication date within this many
days of today (EST). Default 30.
limit: Maximum rows to return (capped at 500).
cursor: Zero-based result offset for stable pagination.
Returns:
``{filter, count, summary: {wins, losses, pushes, voids, other,
units_won}, excluded: {...}, picks: [...]}``
``total_matching`` always equals ``summary.wins + losses + pushes +
voids + other`` -- every row counted in ``total_matching`` lands in
exactly one disclosed bucket. ``excluded`` is a separate, all-time
(not filtered by this call's args) count of what never reaches this
population at all. Picks are newest-first.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | ||
| limit | No | ||
| cursor | No | ||
| league | No | ||
| result | No | ||
| days_back | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral traits: rows may be regraded under a backup-and-manifest process, the file is not immutable, tiers mask premium rows differently, picks are newest-first, and total_matching must equal the sum of disclosed buckets. This materially helps an agent trust and interpret results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then organized into Args and Returns sections that are easy to scan. Though lengthy, each paragraph earns its place, especially the tier explanation and regrading caveat, which are genuinely necessary for correct use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The definition covers all six parameters, output shape, ordering, filtering semantics, and the total_matching/excluded invariants. Even with the output schema present, it explains return structure enough that an agent could call and interpret the tool correctly without any additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, and it delivers. It explains every parameter: league values, result restrictions, the nuanced tier options including lean handling, days_back's EST window and default, limit's cap, and cursor's zero-based pagination semantics. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Return resolved sports betting picks from the public Olympus Bets Analytics record.' The qualifiers 'resolved' and 'public' clearly separate this from projection, recommendation, and personal-history siblings, so an agent can identify what this tool uniquely provides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context by framing the tool as a filtered, historical, auditable record and explaining each filter. However, it does not explicitly name alternative tools or state when not to use it, leaving some routing against overlapping siblings like get_pick_history and get_projection_history to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve team or player names before requesting a profile.
Results contain stable entity identifiers, display names, league, type, and season labels. Public profile coverage is currently NBA, CBB, NHL, and NFL.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| league | No | ||
| entity_type | No | all |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds value by stating the result structure (identifiers, display names, etc.) and noting coverage (NBA, CBB, NHL, NFL). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences that front-load the main use case and then detail result contents and coverage. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which covers return values) and well-named parameters, the description provides adequate context about the tool's scope and result contents. It could be improved by explicitly linking the league parameter to coverage, but overall it is sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is rich with descriptive parameter names, enums, and defaults (e.g., query, league, entity_type, limit). However, the description does not explain any parameters beyond mentioning coverage, and schema description coverage is 0%. The schema bears the explanatory burden, which is adequate but leaves the description's contribution minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Resolve team or player names before requesting a profile.' It also lists the result contents (stable IDs, display names, league, type, season labels) and coverage, making it easy for an agent to understand its function. It differentiates from sibling tools like get_player_profile which are for fetching profiles after obtaining identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool as a precursor to profile requests: 'Resolve team or player names before requesting a profile.' This gives clear usage context. However, it does not specify when not to use it or list alternatives, so it lacks complete exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_player_prop_history1 field changedInput schema / properties / include_alt_linesAdded value: +{
+ "default": false,
+ "title": "Include Alt Lines",
+ "type": "boolean"
+}get_player_prop_historyget_player_propsget_oracle_insightsget_subscription_options1 field changedInput schema / properties / agent_refAdded value: +{
+ "default": "",
+ "title": "Agent Ref",
+ "type": "string"
+}get_performance_summary1 field changedInput schema / properties / tier / anyOfPrevious value: -[
- {
- "enum": [
- "all",
- "free",
- "premium",
- "premium_ex_oracle",
- "oracle"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "all",
+ "free",
+ "premium",
+ "premium_ex_oracle",
+ "oracle",
+ "premium_leans"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]get_track_record1 field changedInput schema / properties / tier / anyOfPrevious value: -[
- {
- "enum": [
- "free",
- "premium"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "free",
+ "premium",
+ "lean"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]get_premium_slate1 field changedInput schema / properties / weekAdded value: +{
+ "default": false,
+ "title": "Week",
+ "type": "boolean"
+}get_performance_summary1 field changedInput schema / properties / windowAdded value: +{
+ "default": "all",
+ "enum": [
+ "all",
+ "30d",
+ "60d",
+ "90d"
+ ],
+ "title": "Window",
+ "type": "string"
+}get_oracle_boardget_brand_card1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_brand_cardDictOutput",
+ "type": "object"
+}get_data_statusget_engine_versions1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_engine_versionsDictOutput",
+ "type": "object"
+}get_game_recommendation1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_game_recommendationDictOutput",
+ "type": "object"
+}get_league_schedule1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_league_scheduleDictOutput",
+ "type": "object"
+}get_methodology1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_methodologyDictOutput",
+ "type": "object"
+}get_model_vs_market1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_model_vs_marketDictOutput",
+ "type": "object"
+}get_performance_summary3 fields changedInput schema / properties / detailAdded value: +{
+ "default": "summary",
+ "enum": [
+ "summary",
+ "full"
+ ],
+ "title": "Detail",
+ "type": "string"
+}Input schema / properties / leagueAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "League"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_performance_summaryDictOutput",
+ "type": "object"
+}get_pick_history2 fields changedInput schema / properties / cursorAdded value: +{
+ "default": 0,
+ "title": "Cursor",
+ "type": "integer"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_pick_historyDictOutput",
+ "type": "object"
+}get_player_profileget_premium_game_recommendationget_premium_historyget_premium_slateget_projection_historyget_subscription_options1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_subscription_optionsDictOutput",
+ "type": "object"
+}get_team_profileget_todays_projections1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_todays_projectionsDictOutput",
+ "type": "object"
+}get_track_record3 fields changedInput schema / properties / cursorAdded value: +{
+ "default": 0,
+ "title": "Cursor",
+ "type": "integer"
+}Input schema / properties / tierAdded value: +{
+ "anyOf": [
+ {
+ "enum": [
+ "free",
+ "premium"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "title": "Tier"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "title": "get_track_recordDictOutput",
+ "type": "object"
+}search_entitiesget_performance_summary1 field changedInput schema / properties / tier / anyOfPrevious value: -[
- {
- "enum": [
- "all",
- "free",
- "premium"
- ],
- "type": "string"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "enum": [
+ "all",
+ "free",
+ "premium",
+ "premium_ex_oracle",
+ "oracle"
+ ],
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+]Sports data across 8 sports under one canonical schema — scores, stats, standings, Elo, odds
Live sports stats and pre-computed analysis for AI assistants across NBA, MLB, NFL, and NHL.
Schedules, scores, odds, splits & explainable AI bet confidence — 8+ sports, free instant key.
Live NFL, MLB, and NBA sports intelligence: injury signals, identity resolution, projections.
Add one secure layer between your agents and this server.
