Quant sports analytics: 19 read-only tools across 12 leagues, projections, methods, track record.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
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). 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?
The description adds significant behavioral context beyond annotations: it searches a simulation cache, returns masked premium data, and gives specific display instructions (e.g., not to derive times from raw fields or re-round floats). Annotations already indicate readOnly and idempotent, but the description enriches transparency.
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 and bullet points for arguments. It is slightly verbose with display instructions, but every sentence adds value. Efficient for the amount of information conveyed.
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 (3 parameters, one enum, output schema present), the description covers purpose, parameters, behavior, and return values comprehensively. No gaps remain for an agent to select and invoke 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 coverage is 0%, but the description compensates fully with a detailed Args section explaining league enum, team substring matching, and date format. This provides meaning that the schema lacks.
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 model projection for a specific game' with specific outputs like projected scores, win probability, and edges. It distinguishes from siblings by noting that premium picks are masked, differentiating from get_premium_game_recommendation.
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 the tool searches a simulation cache for a game involving the requested team and details parameters. It mentions that premium picks are masked, implying this tool is for public data, but it does not explicitly name alternatives or state when not to use it.
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: as of April 2026, the free tier is currently outperforming
the premium tier (the April 2026 profitability-zone tightening is in
recalibration). Both numbers are published transparently.
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.
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 |
| 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 true, but description adds value by explaining the data is 'public, timestamped, correction-audited resolved-pick record', ensuring agent understands data integrity. No 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-organized with sections and bullet-like list for tiers. Front-loaded with purpose. Slightly long (~250 words) but every sentence adds value for a complex tool.
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?
Output schema exists and description mentions return fields (total_picks, wins, etc.). However, league parameter lacks allowed values and output schema is not fully described; still complete enough given annotations and schema presence.
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 compensates well for tier (detailed semantics for each enum), detail (summary vs full), but league is minimally described as 'optional filter' without listing possible values. Considered adequate but not perfect.
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 verb 'Return' and the resource 'Olympus Bets Analytics live performance', specifying it is split by tier and league. It distinguishes itself from siblings like get_track_record by focusing on tier/league breakdowns with detailed semantics.
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?
Includes explicit guidance on when to use each tier, especially premium_ex_oracle vs premium for core model questions, and an honest framing about free outperforming premium. Provides alternatives and context for selection.
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. Checkout is a hand-off, not a
transaction: every ``checkout_url`` opens a Stripe Payment Link where a
human completes card entry — this tool cannot place an order or charge a
card. 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?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses the critical hand-off behavior: checkout_url opens a Stripe Payment Link and the tool cannot place orders or charge cards. It also notes intentional omission of performance numbers, adding valuable context.
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 sentences, each earning its place: first states the output, second provides usage context, third adds behavioral caveat and alternative. Front-loaded and well-structured 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 zero parameters, existing output schema, and comprehensive annotations, the description fully covers purpose, usage timing, behavioral nuances, and alternatives. No significant gaps remain for an agent to invoke this 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?
The tool has zero parameters, and the schema coverage is trivially 100%, so the baseline is 4. The description adds no parameter-specific details, but none are needed; it focuses on return content and usage context.
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 plans, pricing, checkout links, and partner-pilot interest details, specifying a unique resource among many get_* siblings. It distinguishes itself by focusing on subscription options and integration, not performance 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?
Explicitly states when to use: when evaluating Olympus as B2B infrastructure or needing plan/pricing details. It also directs users away from this tool for performance numbers, naming get_performance_summary and subscribe_page as alternatives, providing clear exclusions.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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!
Sign in to create a connector for this server.