Quant sports analytics: 19 read-only tools across 12 leagues, projections, methods, track record.
Average 4.2/5 across 19 of 19 tools scored. Lowest: 3/5.
Most tools have clearly distinct purposes, but some overlap exists (e.g., get_todays_projections vs get_game_recommendation and get_track_record vs get_pick_history vs get_performance_summary). However, the detailed descriptions help differentiate them.
All tools follow a consistent 'get_*' or 'search_*' verb_noun pattern with snake_case. The only deviation is 'search_entities', which is a natural fit for a search operation.
19 tools is well-scoped for a sports betting analytics server, covering metadata, data status, schedules, projections, performance, subscriptions, and profiles without being excessive.
The tool surface covers core analytics workflows (projections, track record, performance, methodology) plus supporting operations (brand, status, subscriptions, search). Minor gaps like league standings or team statistics are outside the primary scope.
get_brand_cardAReturn 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.
get_data_statusAReturn 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.
get_engine_versionsAReturn 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.
get_game_recommendationAReturn 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.
get_league_scheduleAReturn 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.
get_methodologyAReturn 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.
get_model_vs_marketAReturn 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.
get_oracle_boardAReturn 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.
get_performance_summaryAReturn 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.
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 five 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.
| 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?
Beyond the readOnly and idempotent annotations, the description discloses substantial behavioral context: data source is 'correction-audited', tier semantics reflect historical divergence (e.g., core +30.16u vs oracle -18.43u), and both regimes are published. This helps the agent understand the tool's internal distinctions and honest framing, going well 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?
The description is front-loaded with a clear purpose, then uses structured sections (aggregation, tier semantics, honest framing, Args, Returns) that each earn their place. Despite its length, every sentence adds necessary context for a complex multi-tier reporting tool, with 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?
Given four optional parameters and an output schema, the description covers all parameter semantics, explains return shape, and provides the broader context of why tier separation exists. It is complete for an agent to select and correctly invoke the 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?
With 0% schema description coverage, the description fully compensates by explaining each parameter: tier's enum meanings, detail's summary/full modes, window's historical vs rolling behavior, and league as a filter. The Args section adds semantic meaning that the schema lacks entirely.
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 first sentence clearly states the function: 'Return Olympus Bets Analytics live performance, split by tier and league.' This specifies the verb (return), resource (performance), and scope (split by tier and league), distinguishing it from siblings like get_track_record or get_pick_history. The detailed tier semantics further reinforce its unique purpose.
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 guidance on when to use specific tier values, e.g., 'Use this (not premium) when the question is "how good is the core model"' and explains why oracle is separated. However, it does not explicitly mention alternative tools or when not to use this tool overall, so it lacks explicit exclusion/alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_pick_historyAReturn 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.
get_player_profileCReturn 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.
get_projection_historyAQuery 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 supported player-prop markets, outcomes, and closing-market context when available. Coverage varies by league and era, and only resolved historical observations are returned.
| 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?
Adds behavioral context beyond annotations: includes model-only observations, coverage variation, only resolved historical returns. Aligns with readOnlyHint and idempotentHint 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?
Three concise sentences, front-loaded with the main action, no redundancy or unnecessary detail.
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 12 parameters and sibling tools, the description fails to explain parameter roles or when to use this tool over others. Parameter usage is completely opaque, significantly reducing completeness 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?
Schema description coverage is 0% and the description provides no meaning or guidance for any of the 12 parameters (league, team, limit, etc.), leaving the agent entirely uninformed about how to use them.
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?
Clearly states the verb 'Query' and the resource 'full available normalized projection archive'. Distinguishes from siblings by specifying it's broader than the public resolved-pick ledger and includes model-only observations, player-prop markets, etc.
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?
Provides context that this is the broader research dataset and explains coverage varies by league/era, but does not explicitly state when to use this versus alternatives like get_pick_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_subscription_optionsAReturn 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.
| 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?
Although annotations already include readOnlyHint=true and idempotentHint=true, the description adds essential behavioral details: it does not charge a card, checkout URLs are hosted Stripe Payment Links, and operator authorization is required before completing checkout. It also warns that Website Premium plans are not a substitute for Pro, preventing potential misuse of returned data. This exceeds the baseline annotation information.
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 yet comprehensive, front-loading the core purpose, then layering usage context, critical caveats, and alternative tool references. Every sentence adds value—no fluff or repetition. It is appropriately sized for the tool's complexity and clearly structured.
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 description fully covers the tool's context: it defines the intended use case, clarifes product differentiation, states operational constraints (hosted checkout, authorization), and explicitly notes what is intentionally omitted (performance numbers) and where to get it. Given the tool has no parameters and an output schema exists, the description provides sufficient contextual completeness for an agent to select and invoke it 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?
The tool has zero parameters, so the schema provides no parameter information. The description compensates by explaining the nature of the returned content (plans, pricing, checkout links, partner-pilot interest) and provides necessary context about how to handle checkout URLs. Per the rubric, zero parameters earns a baseline of 4, and the description uses this opportunity to enrich meaning without being redundant.
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 'Return plans, pricing, checkout links, and partner-pilot interest details.' It further distinguishes itself by specifying the B2B infrastructure evaluation context and clarifying that Website Premium plans are a different product, which helps differentiate from sibling tools like 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?
Explicit guidance is provided: 'Use this when an agent or product team evaluates Olympus as B2B sports-intelligence infrastructure...' It also directs users away from this tool for performance numbers, recommending 'call get_performance_summary (or see subscribe_page) for current tier-segmented track record.' This clearly explains when to use the tool and what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_team_profileBReturn 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.
get_todays_projectionsAReturn 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.
get_track_recordAReturn 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 or masked premium rows.
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?
The description adds significant behavioral context beyond the annotations: it explains the regrading process for corrections, the controlled backup-and-manifest procedure, and that the service does not claim immutability. This is valuable for an agent to understand the data's integrity and auditability, going beyond the readOnlyHint and idempotentHint 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 well-structured with a main paragraph and Args/Returns sections. It is detailed but some sentences (e.g., the regrading process) are lengthy yet necessary for transparency. Overall, it is efficient and front-loaded with the core purpose.
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 has 6 parameters, an output schema exists, and no nested objects, the description covers all essential aspects: parameter meanings, return format (filter, count, summary, excluded, picks), pagination details, and special behaviors like regrading and excluded buckets. It is thorough for an agent to use 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?
With schema description coverage at 0%, the description fully compensates by explaining each parameter's purpose, filter options, defaults (e.g., days_back default 30, limit capped at 500, cursor for pagination), and behavior. This provides meaning beyond the bare schema types and names.
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 resolved sports betting picks from the public Olympus Bets Analytics record, including detailed fields and filtering parameters. It distinguishes from sibling tools like get_pick_history by specifying 'fully-resolved historical projections' and mentioning 'public' and 'auditable', making the purpose distinct.
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 implies usage for retrieving filtered track record data but does not explicitly compare to alternatives like get_pick_history or get_performance_summary. No guidance on when to use this tool over others is provided, only the parameter explanations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_entitiesAResolve 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.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.