infersports
Server Details
Sharp Asian odds + opening-line (初盘) movement for agents: 6 Asian books + Pinnacle. Read-only.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.5/5 across 14 of 14 tools scored. Lowest: 3.9/5.
Most tools have clearly distinct purposes, but get_sharp_line overlaps with compare_lines and get_match_odds as it essentially combines fixture resolution with odds comparison, which could cause misselection. However, descriptions sufficiently clarify differences.
Most tool names follow a verb_noun pattern (e.g., compare_lines, find_match, get_match_odds), but 'match_info' deviates as a noun_noun style. This minor inconsistency does not significantly impact readability.
With 14 tools covering fixture lookup, odds retrieval, comparison, arbitrage, value detection, opening lines, results, and batch scanning, the set is well-scoped for a sports betting odds API without bloat or insufficiency.
The tool surface covers core workflows (find match, get odds, compare, arbitrage, value, results) but lacks historical odds beyond 30-day cache and does not support player props or other sports. These are minor gaps for the stated football/basketball focus.
Available Tools
14 toolscompare_linesCompare LinesARead-onlyInspect
Compare one market across all bookmakers for a match.
Returns each book's quote line-by-line, the consensus line, the best price per outcome, each
book's overround, and de-vigged fair odds from the sharpest (lowest-margin) book.
Args:
event_id: event id (e.g. "evt_…").
market_type: "1x2", "asian_handicap" (default) or "totals".
period: "full_time" (default) or "half_time".
format: display odds format (analytics are computed in decimal regardless).
verbosity: "full" (default) or "terse". "terse" drops the per-book ``books`` array (the bulk
of the payload) and returns only the worked answer (best_prices / consensus_line /
fair_odds / summary).| Name | Required | Description | Default |
|---|---|---|---|
| format | No | decimal | |
| period | No | full_time | |
| event_id | Yes | ||
| verbosity | No | full | |
| market_type | No | asian_handicap |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description details the output structure (per-book quotes, consensus, best prices, overround, fair odds) beyond what annotations provide. This adds behavioral context about the read operation and result format.
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: a lead sentence summarizing the tool, a list of return values, and a bulleted parameter list. All sentences provide unique information without redundancy, though it could be slightly more terse.
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 complexity of comparing lines across bookmakers and no output schema, the description adequately explains both inputs and outputs. It covers all parameters and return elements, though it omits potential error cases or format specifics for the 'format' parameter.
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 by explaining each parameter: event_id, market_type (with default and options), period, format, and verbosity. It clarifies defaults and an example for event_id, though it could list format options more precisely.
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 'Compare one market across all bookmakers for a match' with a specific verb and resource. It lists exact return values (quotes, consensus line, best price, overround, fair odds) which distinguishes it from siblings like get_match_odds or get_sharp_line that likely return simpler 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 provides no explicit guidance on when to use this tool versus its 13 siblings. It does not mention alternatives or when not to use it, leaving the agent to infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
explain_handicapExplain Asian HandicapARead-onlyInspect
Explain an Asian handicap line.
Splits a quarter line into its components (e.g. -0.75 → -0.5 / -1.0) and states the
full-win / half-win / push / half-loss / full-loss conditions. ``line`` must be a multiple
of 0.25.| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits beyond annotations: it explains that the tool splits quarter lines and states outcome conditions. The readOnlyHint annotation is consistent with the description.
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 very concise: two sentences, front-loaded with the main purpose, no wasted words. Each 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 the simple input (one parameter, no output schema), the description is complete. It covers what the tool does and the only constraint on the input parameter.
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 adds meaningful semantics by specifying that line must be a multiple of 0.25 and that it handles quarter-line splits. This compensates for the lack of schema details.
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 explains an Asian handicap line by splitting quarter lines and stating win/loss conditions, with a specific verb ('explain') and resource. It distinguishes itself from sibling tools like compare_lines or find_value.
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 a key constraint: 'line must be a multiple of 0.25.' While it does not explicitly contrast with sibling tools, the constraint serves as a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_arbitrageFind ArbitrageARead-onlyInspect
Find cross-book arbitrage in a fixture — a guaranteed-profit price split — in ONE call.
Resolves the fixture, then for each market/line takes the best price per outcome across books;
when the inverse prices sum to < 1 there is a locked margin regardless of result. Reports the
margin % and which book holds each leg (legs must come from ≥2 distinct books). DETECTION ONLY:
no stake sizing, no bet links — InferSports is read-only.
Args:
query: natural-language fixture, e.g. "Netherlands vs Algeria" or a single team.
markets: optional filter — any of "1x2", "asian_handicap", "totals" (default: all).
period: optional — "full_time" or "half_time" (default: both).
min_margin_pct: only report opportunities with at least this guaranteed margin (default 0).
format: odds format — decimal | hk | malay | american | indonesian | probability.
sport: optional filter — "football" or "basketball".
date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures.
On an ambiguous query, ``status`` is "ambiguous" and ``ask_user`` carries a prompt — do not guess.| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| query | Yes | ||
| sport | No | ||
| format | No | decimal | |
| period | No | ||
| markets | No | ||
| min_margin_pct | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the read-only hint from annotations and adds detail: detection only, no stake sizing, no bet links. It also explains the calculation logic and ambiguous query behavior, providing added context 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 well-structured with a clear overview, algorithmic explanation, limitation note, and parameter list. It is slightly verbose but each 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 the tool's complexity and lack of output schema, the description covers purpose, method, constraints, parameters, and edge cases. It could include more on return structure but is generally complete for a read-only detection 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?
Despite 0% schema description coverage, the description lists all parameters with clear explanations, including acceptable values and defaults (e.g., markets: '1x2', 'asian_handicap', 'totals'; format: decimal, hk, malay, etc.). This adds significant meaning.
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 finds cross-book arbitrage opportunities and explains the concept. It distinguishes from siblings like find_value and get_match_odds by focusing on guaranteed-profit price splits.
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 how the tool works and its read-only nature. It provides guidance on ambiguous queries by describing the 'ambiguous' status and instructing not to guess, though it lacks explicit when-not-to-use or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_matchFind MatchARead-onlyInspect
Find a football/basketball fixture by natural-language name.
Args:
query: e.g. "Man City vs Arsenal" or a single team name.
sport: optional filter — "football" or "basketball".
date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures.
Returns the best-matching event (with id, teams, league, kickoff, live score, the live match
``clock`` e.g. "2h 47" or "ht", and a confidence score) plus alternatives. Use the returned
``event_id`` with get_match_odds / compare_lines.
A ``decision`` block tells you whether it's ``safe_to_proceed`` and the suggested
``next_action`` (or ``ask_user`` when ambiguous).| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| query | Yes | ||
| sport | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description does not contradict. The description adds valuable behavioral context such as the decision block ('safe_to_proceed', 'next_action') and the return of alternatives, going beyond 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 sections (Args, Returns), but it is somewhat verbose with full docstring formatting. A slightly more compact style could improve conciseness.
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 output schema, the description thoroughly covers return values (id, teams, league, clock, confidence) and the decision block, and connects to sibling tools via event_id. This is complete for a search tool of moderate complexity.
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 detailing each parameter with examples and format hints ('YYYY-MM-DD'), making the semantics clear despite the schema's lack of descriptions.
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 uses specific verbs ('Find') and resources ('football/basketball fixture'), clearly defines the tool's purpose, and distinguishes it from siblings like 'get_match_odds' and 'compare_lines' by focusing on natural-language name matching.
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 explicit when-to-use guidance with examples ('e.g. Man City vs Arsenal') and mentions using the returned event_id with other tools. However, it lacks explicit when-not-to-use statements or direct comparisons to sibling tools for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_valueFind Value BetsARead-onlyInspect
Find +EV value bets in a fixture — where a book's price beats the sharp fair line — in ONE call.
Resolves the fixture, de-vigs the sharp book (Pinnacle) at each line to get the fair price, then
flags every outcome whose best available price across books exceeds that fair price. DETECTION
ONLY: this surfaces the edge and which book holds it; it does NOT size stakes or link out to bet.
Args:
query: natural-language fixture, e.g. "Netherlands vs Algeria" or a single team.
markets: optional filter — any of "1x2", "asian_handicap", "totals" (default: all).
period: optional — "full_time" or "half_time" (default: both).
min_edge_pct: only report outcomes beating fair by at least this % (default 1.0).
format: odds format — decimal | hk | malay | american | indonesian | probability.
sport: optional filter — "football" or "basketball".
date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures.
On an ambiguous query, ``status`` is "ambiguous" and ``ask_user`` carries a prompt — do not
guess. Needs the sharp book to de-vig; on the Free tier ``note`` flags that fair is approximate.| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| query | Yes | ||
| sport | No | ||
| format | No | decimal | |
| period | No | ||
| markets | No | ||
| min_edge_pct | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds significant behavioral context: it resolves the fixture, de-vigs the sharp book, flags outcomes with edge, and handles ambiguous queries with an 'ask_user' prompt. It also notes limitations on the Free tier. This adds value beyond the annotation.
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 front-loaded summary, process explanation, and a bulleted Args section. It is relatively concise given the amount of information, though some phrasing could be tightened (e.g., 'in ONE call' is slightly redundant).
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 7 parameters and no output schema, the description covers purpose, each parameter, edge cases (ambiguous query, free tier), and usage boundaries. It lacks details on the output format beyond flagging outcomes, but the core functionality is well explained.
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 has 0% description coverage, but the description compensates fully by listing each parameter (query, markets, period, min_edge_pct, format, sport, date) with clear explanations of their purpose and defaults. This adds all necessary meaning beyond the schema's titles.
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's purpose: 'Find +EV value bets in a fixture' using specific verbs and resources. It differentiates from siblings by emphasizing 'DETECTION ONLY' and explicitly noting it does not size stakes or link out to bet, which distinguishes it from tools like find_arbitrage or bet placement 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?
The description tells when to use the tool (to find value bets) and what it does not do (detection only, no stake sizing). However, it does not explicitly name alternative tools for tasks like bet placement or arbitrage, leaving room for improvement in guiding the agent to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_match_oddsGet Match OddsARead-onlyInspect
Get all current odds for a match across bookmakers.
Args:
event_id: event id from find_match / list_today_matches (e.g. "evt_…").
markets: optional filter — any of "1x2", "asian_handicap", "totals".
bookmakers: optional filter — bookmaker keys, e.g. ["pinnacle", "crown"].
period: optional — "full_time" or "half_time" (default: both).
format: odds format — decimal | hk | malay | american | indonesian | probability.| Name | Required | Description | Default |
|---|---|---|---|
| format | No | decimal | |
| period | No | ||
| markets | No | ||
| event_id | Yes | ||
| bookmakers | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by explaining the scope (all bookmakers, filters). It discloses the optional filters and return format options, providing context 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 concise and front-loaded. Each line in the Args section is informative without verbosity. Every sentence serves a 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?
The tool has 5 parameters and no output schema. The description covers all inputs and specifies the broad output (odds across bookmakers). However, it does not detail the output structure, leaving some context incomplete.
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 in detail (e.g., event_id source, market options, format list). This adds crucial 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 'Get all current odds for a match across bookmakers' with a specific verb and resource. It distinguishes from sibling tools like 'get_opening_line' and 'get_result' by focusing on all current odds.
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 does not explicitly mention when to use this tool over alternatives. It implies usage for live odds but lacks exclusions or comparisons to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_opening_lineGet Opening LineARead-onlyInspect
Get the opening odds (初盘) for a fixture, paired with the current price, in ONE call.
Resolves the fixture, then for each book returns its **true opening** (first-seen) quote alongside
the current quote — so you can read movement directly. For 1x2 that's a price move; for totals/AH
compare ``line`` (the opening line) vs ``current_line`` to read the line move (the sharp book often
opens days earlier). A market with no opening yet on file is omitted.
Args:
query: natural-language fixture, e.g. "Real Madrid vs Barcelona" or a single team.
markets: optional filter — any of "1x2", "asian_handicap", "totals".
bookmakers: optional filter — bookmaker keys, e.g. ["pinnacle", "crown"].
period: optional — "full_time" or "half_time" (default: both).
format: odds format — decimal | hk | malay | american | indonesian | probability.
sport: optional filter — "football" or "basketball".
date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures.
On an ambiguous query, ``status`` is "ambiguous" and ``ask_user`` carries a disambiguation
prompt — do not assume a match. Best-effort: a book/line with no opening on file is omitted.| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| query | Yes | ||
| sport | No | ||
| format | No | decimal | |
| period | No | ||
| markets | No | ||
| bookmakers | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true. The description adds value by explaining edge cases (ambiguous queries, omitted markets without openings) and output structure (opening vs current, line vs current_line). 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 well-structured with a summary paragraph followed by parameter details. It is front-loaded with the core purpose. While slightly long, each sentence adds value (e.g., explanation of line movement for totals/AH). Minor redundancy could be trimmed.
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 7 parameters, no output schema, and moderate complexity, the description covers all necessary context: parameter semantics, behavior on ambiguity, best-effort omission, and what the output conveys. The agent can reliably invoke this tool without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an 'Args:' section that thoroughly explains each parameter: query (natural-language), markets, bookmakers, period, format, sport, date. Format options are listed, and date's disambiguation purpose is clarified. This fully compensates for missing schema descriptions.
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 'Get the opening odds (初盘) for a fixture, paired with the current price, in ONE call.' It uses a specific verb ('Get') and resource ('opening odds'), and contrasts with siblings like get_match_odds (current only) and compare_lines (generic comparison). The explanation of 'read movement directly' reinforces 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?
Provides explicit guidance on ambiguous queries ('do not assume a match') and best-effort behavior ('a book/line with no opening on file is omitted'). However, it does not explicitly state when to use this tool versus alternatives like get_match_odds or get_sharp_line, relying on implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_resultGet ResultARead-onlyInspect
Get the cached final result for ONE finished match by event id.
Returns the final score, red cards and finished time. ``status`` is "found" or "not_found" (the
match isn't in the 30-day cache). Results-only — no odds.
Args:
event_id: event id (e.g. "evt_…") from find_match / list_results.| Name | Required | Description | Default |
|---|---|---|---|
| event_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cache duration (30-day), status values ('found'/'not_found'), and returned fields, complementing the readOnlyHint annotation. No contradictions.
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?
Extremely concise: one sentence for purpose, one for outputs, one for status, and a clean Args block. Every sentence adds value with no 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?
For a simple tool with one parameter and no output schema, the description covers all needs: inputs, outputs, caching behavior, and source of IDs, making it fully self-contained.
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, the description fully explains the event_id parameter, including its format (evt_...) and source (find_match/list_results), filling the schema 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?
Description clearly states it retrieves a cached final result for one finished match by event ID. It specifies outputs (score, red cards, finished time, status) and differentiates from odds tools, making purpose unmistakable.
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 for when to use (after find_match/list_results) and what it returns, but lacks explicit exclusions or comparisons to other sibling tools like list_results or get_match_odds, which would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sharp_lineGet Sharp LineARead-onlyInspect
Answer an odds question about a fixture in ONE call (natural language in, worked line out).
Resolves the fixture, picks the consensus line, the best price per outcome across books, and
de-vigged fair odds from the sharpest book — returning a ready-to-read ``summary`` plus the
full ``comparison``. Prefer this over chaining find_match → compare_lines.
Args:
query: natural-language fixture, e.g. "Arsenal vs Man City" or a single team.
market_type: "1x2", "asian_handicap" (default) or "totals".
period: "full_time" (default) or "half_time".
format: odds format — decimal | hk | malay | american | indonesian | probability.
sport: optional filter — "football" or "basketball".
date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures.
verbosity: "full" (default) or "terse". "terse" empties the per-book ``books`` array inside
``comparison`` to save tokens; the ``summary`` and worked numbers are kept either way.
On an ambiguous query, ``status`` is "ambiguous" and ``ask_user`` carries a disambiguation
prompt — do not assume a match; ask the user or re-call with a more specific query. A
``decision`` block (``safe_to_proceed`` / ``ask_user`` / ``next_action``) pre-computes the
go/no-go — branch on it instead of re-judging the result.| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| query | Yes | ||
| sport | No | ||
| format | No | decimal | |
| period | No | full_time | |
| verbosity | No | full | |
| market_type | No | asian_handicap |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only have readOnlyHint=true. Description adds rich behavioral detail: resolves fixture, picks consensus line, best price, de-vigged fair odds, and decision block for ambiguous queries. No contradictions.
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 summary line followed by detailed bullet-like list. Slightly long but each sentence adds value. Could be trimmed slightly but still 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?
With 7 parameters, 0% schema coverage, and no output schema, this description is comprehensive. Covers edge cases (ambiguous queries), return structure (summary, comparison, status, decision), and all parameter details.
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 0% coverage, but description provides detailed explanations for all 7 parameters, including defaults and effects (e.g., verbosity terse empties books array). Highly informative.
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 'Answer an odds question about a fixture in ONE call' with a specific verb-resource pair. Distinguishes from sibling tools (find_match, compare_lines) by recommending this over chaining.
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 'Prefer this over chaining find_match → compare_lines' and explains natural language input. However, no explicit when-not-to-use or alternative conditions beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_bookmakersList BookmakersARead-onlyInspect
List the bookmakers available on your tier.
Returns the curated catalogue (each with ``key``, ``name`` and ``class`` = "sharp" | "asian")
plus a ``note`` on tier coverage. Free tier excludes the sharp book (Pinnacle). Use the returned
``key`` values in the ``bookmakers`` filter of get_match_odds / compare_lines.| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds detail on return structure (key, name, class) and behavior (free tier excludes Pinnacle), going beyond the annotation.
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, no fluff. First sentence states purpose, second details return, third gives usage hint. Efficient and front-loaded.
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 read-only tool with no parameters and good annotations, the description covers purpose, return format, and usage integration. Nothing 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?
No parameters exist, and schema coverage is 100%. Description adds no parameter info but none is needed; baseline 4 is appropriate.
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 tool lists bookmakers for the user's tier, with specific return fields. Distinguishes from siblings like get_match_odds by focusing on bookmaker catalogue.
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 tells agents to use the returned key values in filters for get_match_odds and compare_lines. Notes tier coverage and free tier exclusion, but doesn't explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_resultsList ResultsARead-onlyInspect
Look back at finished-match scores from the 30-day results cache, most-recent-first.
Results-only: each entry is the final score, red cards and finished time (no odds). Unlike the
live tools, these survive a restart — use it for "what was the score of X?" or "yesterday's
results".
Args:
date: optional UTC kickoff date "YYYY-MM-DD" — the day the match was played.
team: optional case-insensitive substring matched against either team name.
league: optional case-insensitive substring matched against the league name.
limit: max results to return, most-recent-first (1–200, default 50).| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| team | No | ||
| limit | No | ||
| league | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint: true. The description adds valuable behavioral context: data comes from a 30-day cache, entries are most-recent-first, contain final score, red cards, and finished time (no odds), and survive restarts. 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 concise and well-structured: a clear opening sentence, a second paragraph distinguishing from live tools, and a bulleted Args list. Every sentence adds value with no 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?
Despite no output schema, the description specifies that each entry contains final score, red cards, and finished time. It also explains the 30-day cache, ordering, and parameter details. For a list tool, this is complete and eliminates 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?
Schema description coverage is 0%, but the description fully documents each parameter: date format 'YYYY-MM-DD', team and league as case-insensitive substrings, limit range 1-200 with default 50. This compensates completely for the schema 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 the tool's purpose: 'Look back at finished-match scores from the 30-day results cache, most-recent-first.' It identifies the resource (finished-match scores) and verb (list), and gives examples like 'what was the score of X?' This makes the purpose unambiguous and distinguishes from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by contrasting with live tools: 'Unlike the live tools, these survive a restart.' It also gives concrete use cases ('use it for "what was the score of X?"'). However, it does not explicitly name sibling alternatives for similar tasks (e.g., get_result), so slightly less explicit than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_today_matchesList Today's MatchesARead-onlyInspect
List today's (UTC) fixtures — "what games are on today / right now?".
Each fixture carries its status, live score, the live match ``clock`` (upstream minute text,
verbatim e.g. "1h 25" / "2h 47" / "ht") when in-running, and a ready-to-read ``summary`` (live
score & clock, or the kickoff time). Read ``clock`` for the real minute rather than estimating it
from kickoff. ``clock`` is null pre-match.
Args:
sport: optional filter — "football" or "basketball".
status: optional filter — "live", "scheduled" or "finished".
league: optional external league id ("lg_…").
limit: max fixtures to return (1–200, default 50).
timezone: optional IANA timezone (e.g. "America/New_York", "Asia/Shanghai") to render each
fixture's kickoff in its ``summary`` as local time; default UTC.| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sport | No | ||
| league | No | ||
| status | No | ||
| timezone | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses output fields (status, live score, clock, summary) and explains clock behavior (null pre-match, real minute). Annotations already indicate read-only, so description adds valuable details 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: purpose sentence, output field explanation, then parameter list. Every sentence adds value, no redundancy. Concise yet comprehensive.
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?
No output schema, but description explains return fields sufficiently. Covers edge cases (null clock pre-match). All parameters are documented. Complete for a listing tool with filters.
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 0% description coverage, but description fully compensates by listing each parameter with allowed values and defaults. Provides examples for sport ('football', 'basketball') and timezone ('America/New_York').
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 'List today's (UTC) fixtures' using a specific verb and resource. Distinguishes from sibling tools like 'find_match' or 'get_match_odds'. Provides a usage example in parentheses.
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 clear context for when to use (e.g., 'what games are on today / right now?') and explains optional filters. Lacks explicit mention of when not to use, but the context and sibling names make it clear this is for broad listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
match_infoMatch InfoARead-onlyInspect
Get the basics for a match in ONE call: the score, whether it's live, when it kicks off, and who's favored.
No betting knowledge needed — this answers "who's winning?", "what's the score?", "what time does
Brazil play (in my timezone)?", "who's the favorite?". Returns the live score + match clock, the
status, the kickoff time (in ``timezone`` if you pass an IANA name like "America/New_York"), the
favored team with a plain win probability (de-vigged from the 1x2 line), and a ready-to-read
``summary`` you can quote directly.
Args:
query: natural-language fixture or team, e.g. "Brazil vs Argentina" or just "Brazil".
timezone: optional IANA timezone (e.g. "America/New_York", "Asia/Shanghai") for the kickoff
time; default UTC.
sport: optional filter — "football" or "basketball".
date: optional UTC date "YYYY-MM-DD" to disambiguate same-name fixtures.
On an ambiguous query, ``status`` is "ambiguous" and ``ask_user`` carries a prompt — do not guess.
``favorite`` is best-effort (null when no 1x2 is on file for the fixture).| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| query | Yes | ||
| sport | No | ||
| timezone | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavior beyond the annotations: it explains the ambiguous status, best-effort favorite, timezone conversion, and de-vigged probability. The readOnlyHint annotation is consistent with the read-only nature described.
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 overview, then parameter details, and edge-case handling. It is slightly verbose but remains readable and front-loaded. A minor trim could make it more concise.
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 covers all key aspects: what is returned (score, clock, status, kickoff time, favorite, probability, summary), edge cases (ambiguous, null favorite), and parameter usage. Without an output schema, this is comprehensive enough for an agent to use effectively.
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 provides detailed meaning for all four parameters: query, timezone, sport, and date. It explains natural-language queries, IANA timezone format, optional filters, and disambiguation. This fully compensates for the schema lack.
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 gets the basics for a match in one call, including score, live status, kickoff time, and favorite. It uses specific verbs and resources and distinguishes itself from sibling tools like get_match_odds or find_match by focusing on a quick 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 provides clear context, stating no betting knowledge is needed and explaining when to use it for quick match info. It also handles ambiguous queries by instructing not to guess. However, it does not explicitly contrast with sibling tools, which would raise the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_slateScan SlateARead-onlyInspect
Scan today's whole slate in ONE call — each fixture with honest status + value/arb signal.
The batch alternative to looping find_match → get_sharp_line per match. Returns every fixture in
the filter with its status (finished is excluded from "live"), live score/clock, and a
pre-computed value/arb signal; value/arb matches are sorted to the top and the list is truncated
to ``limit`` (so truncation drops the quiet ones). Line movement is NOT included (that needs the
opening lookup) — drill into a single fixture with get_opening_line. DETECTION ONLY / read-only.
Args:
sport: optional filter — "football" or "basketball".
status: optional filter — "live" | "scheduled" | "finished".
league: optional external league id (lg_…).
markets: optional — limit the value/arb scan to "1x2"/"asian_handicap"/"totals" (default all).
period: optional — "full_time" or "half_time" (default both).
min_edge_pct: value threshold for the per-match signal (default 1.0).
min_margin_pct: arbitrage threshold for the per-match signal (default 0.0).
only_signal: if true, return only fixtures that have a value or arb signal.
format: odds format — decimal | hk | malay | american | indonesian | probability.
limit: max entries to return, signal-first (default 20, max 100).| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| sport | No | ||
| format | No | decimal | |
| league | No | ||
| period | No | ||
| status | No | ||
| markets | No | ||
| only_signal | No | ||
| min_edge_pct | No | ||
| min_margin_pct | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, and description adds key behaviors: read-only, truncation, exclusion of finished from 'live', sorting of value/arb to top, max limit 100. No contradictions.
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: high-level purpose sentence followed by parameter list. Every sentence adds value, though slightly verbose.
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 usage, limitations, and parameter meanings well. Lacks explicit return format details (e.g., structure of each fixture), but mentions key fields. Given no output schema, more detail on return shape would improve completeness.
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 0%, but description adds meaning for all 10 parameters via informal bullet list, explains default values, effects of limit, and filters. Compensates well.
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 it scans today's whole slate in one call, returns fixtures with status and value/arb signals. Distinguishes from siblings by mentioning it's the batch alternative to looping find_match→get_sharp_line and contrasts with get_opening_line for line movement.
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 (batch scan) and when not to (line movement needs get_opening_line). Mentions truncation and sorting, but could be more explicit about other alternatives.
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.
Discussions
No comments yet. Be the first to start the discussion!