Sports MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
The two provider prefixes (odds_ and sm_) create overlapping functionality: odds_get_odds, odds_get_event_odds, sm_odds_prematch, and sm_odds_inplay all provide odds, while odds_get_scores and sm_livescores both give scores. Although descriptions mention the source API, agents may struggle to pick the right tool when multiple options serve the same purpose.
Naming Consistency2/5
The odds_ tools follow a verb_noun pattern (get_sports, get_events, get_odds), but the sm_ tools use bare nouns (livescores, fixtures, leagues) without verbs. This split between two naming conventions within one server is inconsistent, and compound names like sm_team_squads and sm_expected_xg further deviate from a clear pattern.
Tool Count2/5
With 28 tools, the server is heavy and exceeds the typical 25-tool threshold. While it integrates two major sports APIs, the high count increases selection overhead and includes overlapping endpoints that could be consolidated or parameterized.
Completeness4/5
The server covers a broad spectrum of sports data: odds (prematch, inplay, historical, props), scores, fixtures, standings, statistics, predictions, and more. Minor gaps exist, such as no unified search across both providers, but for the stated sports data domain the coverage is nearly complete.
Average 3.7/5 across 28 of 28 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It only says 'Get football players' and 'Rich data with includes,' implying a read operation but omitting important behaviors like pagination, default mode, output shape, or how includes affect the response. This is minimal transparency for a data-retrieval tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action and resource. Both sentences are purposeful and free of filler, though the second sentence is terse and vague about what 'rich data' entails.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no output schema, and no annotations, but the description only scratches the surface. It doesn't clarify mode-specific requirements, pagination, or return data, so an agent cannot reliably construct a correct invocation without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'include' is described), and the description fails to compensate. It lists modes but omits the 'all' mode present in the schema, and gives no explanation of id, page, countryId, searchQuery, or which parameters apply to which mode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get football players' with a specific verb and resource, and adds mode variants. It distinguishes the tool from sibling tools focused on teams, standings, or odds, though it doesn't explicitly contrast with overlapping tools like sm_team_squads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists modes ('by_id', 'by_country', 'search') but provides no guidance on when to use each or how they differ. It also doesn't mention alternatives such as sm_team_squads for player squads, so an agent gets little help choosing between this and related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers no behavioral details beyond listing. Since there are no annotations, it fails to disclose potential pagination, output structure, authentication requirements, or how the different modes (all, by_id, search, by_fixture) affect behavior. The only additional hint is that returned IDs are used with odds endpoints, but that is not transparency about this tool's own behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no wasted words. The first sentence states the core purpose; the second adds an important usage pointer. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, an enum, multiple modes), the description is far too minimal. It does not cover the meaning of the modes, how search works, or what the output contains. With no output schema, the agent is severely under-supported.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description provides no explanation of the 'id', 'mode', 'fixtureId', or 'searchQuery' parameters. The agent is left to infer semantics from the schema alone, which is insufficient for correctly using modes and filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'available bookmakers in SportMonks', making the primary function unambiguous. It is distinct from sibling tools which focus on odds, events, or standings, though it does not explicitly reference a sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The sentence 'Use bookmaker IDs with odds endpoints' provides clear integration context, telling the agent that this tool is a prerequisite for odds-related workflows. However, it does not specify when to prefer this over other listing tools or provide exclusions, so it falls short of explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden for behavioral disclosure. It only states the high-level purpose without describing return format, pagination, error handling, or side effects. The mode mention hints at behavior but doesn't disclose what each mode actually returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise with two sentences, front-loading the primary purpose and immediately adding a relevant workflow note. No words are wasted, and the structure helps quickly orient the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, and no output schema, this description is too sparse. It leaves major gaps: what 'all' mode does, how include works, the interplay between id/seasonId and modes, and what the response shape is. Reliable invocation would require additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must clarify parameter meaning. It explains the mode values (though omitting 'all') and implies the id parameter's role for standings, but it does not clarify seasonId or include semantics. The incomplete explanation falls short of compensating for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Get round information') and differentiates among modes ('by_season', 'by_id'), which helps distinguish it from sibling tools like standings. However, it omits the 'all' mode defined in the schema, making the purpose slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a contextual hint that round IDs are needed for standings by round, implying a common use case. But it doesn't explicitly state when to use this tool versus alternatives or mention the 'all' mode, leaving usage guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get match schedules' and mentions modes, but does not reveal pagination behavior, return format, required permissions, or any side effects. This is a significant gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences that are front-loaded. The first sentence states the core action, and the second adds a practical use case. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no annotations, and no output schema, the description is too thin to be complete. It does not explain how modes interact with parameters like teamId and seasonId, nor does it indicate what the response will contain. It provides a minimal overview but leaves major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does very little to compensate. It labels the mode values ('by_season', 'by_team', 'by_season_team') but these are already in the schema enum. Parameters like teamId, seasonId, page, and include are left completely unexplained, so the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get match schedules.' It also lists the three modes, which adds specificity about how schedules can be retrieved. However, it does not differentiate this tool from the sibling 'sm_fixtures,' which likely also handles match schedules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for planning which fixtures to track' offers a general usage context, implying this tool is for browsing schedules in advance. It does not explicitly state when to prefer this over alternatives like sm_fixtures, nor does it mention exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool outputs team IDs and has multiple modes, but it fails to mention pagination behavior (despite a page parameter), response structure, rate limits, or any side effects. This is a significant gap for a read-like tool with no annotation safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and gets straight to the point: what the tool does and an important note about team IDs. No wasted words, front-loaded the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, no annotations, and low schema coverage, this description is too brief. It lacks details on mode-parameter mappings, output format, pagination, and usage context. It provides only a high-level purpose, which is inadequate for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters but only 14% description coverage, and the tool description does not explain any parameter semantics beyond listing mode options. It does not clarify that by_id requires id, by_country requires countryId, or what searchQuery does, leaving the agent to infer relationships. This is insufficient given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Get football teams') and lists the supported modes, distinguishing it from sibling tools by noting that it returns team IDs used across all endpoints. However, it does not explain what each mode does beyond its name, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Returns team IDs used across all endpoints' implies this is the tool to use when you need team IDs for other API calls, but it does not explicitly name alternatives or state when not to use it. No exclusions or alternative guidance is provided, so it falls short of a high score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral disclosure. It mentions the xG add-on plan requirement, which is a useful prerequisite, but omits other behavioral traits such as read-only status, rate limits, or what happens if the add-on is missing. The description is too sparse to adequately inform an agent about side effects or access constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words. It front-loads the main action and costs minimal tokens. However, it is so brief that it sacrifices necessary details, keeping it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 3 parameters with minimal schema coverage, the description is incomplete. It fails to explain the return format, the meaning of 'include', or detailed parameter behavior. An agent would likely need to guess or experiment to use this tool correctly, especially with the undocumented 'include' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'id' is described). The description's 'by team or player' hint partially clarifies the 'id' and 'mode' purpose, but the 'include' parameter is completely unexplained in both the schema and description. The description does not sufficiently compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Expected Goals (xG) data, with the ability to filter by team or player. This specific verb+resource combination distinguishes it from sibling tools like sm_statistics or sm_predictions, which may cover broader or different stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when xG data is needed and mentions the add-on plan requirement, but it does not explicitly state when alternatives should be used or provide exclusions. The 'by team or player' phrasing gives some context on input modes, but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only restates the function and does not address return format, parameter requirements, limitations, or whether it is read-only. The description adds no behavioral context beyond what is evident from the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler, front-loading the core purpose and adding a brief use-case note. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no annotations, and no output schema, the description is too sparse. It does not explain the different modes, the 'include' parameter, or how to combine the various IDs, leaving significant gaps for an agent to know how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, and the description adds no meaningful parameter semantics beyond the schema. It does not explain the 'include' parameter or how the 'mode' affects other parameters, and the participantId reference merely duplicates the schema's existing description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves statistics for a participant (team or player) across season/stage/round, using a specific verb and resource. It does not explicitly differentiate from sibling tools like sm_topscorers or sm_predictions, though the focus on participant statistics is fairly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Essential for form and performance analysis' provides a clear context for when to use the tool. However, it lacks explicit exclusions or mentions of alternatives, so it is a clear context without comprehensive usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The word 'Get' hints at a read-only operation, but it does not explicitly confirm that no data is modified, nor does it disclose how modes affect the response, pagination behavior, or potential errors. The mode list provides minimal behavioral context but is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the core purpose and then lists the modes. Every word serves a function, with no unnecessary detail or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters, no output schema, and no annotations, the description is too sparse to be complete. It does not explain the return format, how modes affect the data, or which parameters are required for each mode. The tool is moderately complex, and the description does not provide enough context for correct invocation without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter understanding. It merely repeats the mode enum values from the schema without explaining how parameters like fixtureId, marketId, bookmakerId, page, and include relate to each mode. The parameter names are self-explanatory, but the description adds no meaning beyond the schema, leaving interactions between modes and parameters ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('live in-play odds from SportMonks'). It distinguishes this from sibling tools like sm_odds_prematch by specifying 'in-play', and the mode list further defines its capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving live in-play odds but does not explicitly state when to use this tool versus alternatives, nor does it explain which mode to choose for different scenarios. There is no mention of exclusions or conditions, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Get' and lists modes without mentioning pagination, required parameters per mode, response format, or potential limitations. This falls short of the burden on an annotation-less tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and compactly lists modes. Every phrase earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and low parameter coverage, the description is insufficient. It fails to explain the interplay between modes and parameters, output structure, or error behavior, leaving significant gaps for a tool with multiple modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%), but the description explains the 'mode' enum values, adding meaning beyond the raw schema. However, it does not clarify how page, include, or fixtureId relate to each mode, nor that fixtureId is likely required for by_fixture modes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves SportMonks predictions, with explicit modes ('probabilities', 'by_fixture', 'value_bets', 'value_bets_by_fixture') that define scope. This distinguishes it from sibling odds/livescore tools by the resource being predictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implied usage context via the phrase 'Great for model cross-reference' and enumerates modes, but does not explicitly state when to use this tool over sibling tools or provide exclusion criteria. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The verb 'List' implies a safe read-only operation, and the cross-reference to other tools adds behavioral context (IDs are useful downstream). However, it doesn't disclose pagination, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second gives cross-tool usage. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters with a mode enum, but the description omits these modes and doesn't clarify output format or differentiate from odds_get_event_markets. It covers the primary listing function but misses important operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the id, mode, or searchQuery parameters. It only mentions market IDs in the output, not how inputs control listing behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'List available betting markets in SportMonks' - a clear verb+resource. It adds downstream context by noting IDs are for use with sm_odds_prematch and sm_odds_inplay, but doesn't explicitly differentiate from sibling odds_get_event_markets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use market IDs with sm_odds_prematch and sm_odds_inplay' tells the agent when to use this tool. Lacks exclusions or alternative tool mentions, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full transparency burden. It does not disclose conditional parameter requirements (e.g., live mode needs leagueId, by_round likely needs roundId) or describe response characteristics, leaving the agent uncertain about correct invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the core purpose front-loaded. The modes are listed efficiently, and only the phrase 'Essential for form analysis' is mildly non-operational, but overall it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description should compensate by clarifying per-mode required parameters and return value shape. It does neither, leaving significant gaps for an agent trying to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (80%), so the baseline is 3. The description adds minimal value by noting 'live standings by league', which hints at the leagueId parameter, but does not explain other parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get league standings / tables', which is a specific verb+resource. It lists the three modes, further clarifying scope. This distinguishes it from sibling tools like sm_fixtures or sm_topscorers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Essential for form analysis' provides a clear when-to-use context. The mode list implies different invocation scenarios, though no alternatives are explicitly named or excluded.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral expectations. It only states the action without disclosing response format, ordering, data volume, or any side effects or limitations. This is a significant gap for a tool that likely returns a list of players with goals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler words. It is front-loaded and every word earns its place, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters and no output schema, the description leaves out critical information about required parameter combinations (e.g., seasonId for by_season, stageId for by_stage), default behavior, and the shape of the returned data. The tool is complex enough to require more context, but the description provides none.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only the 'include' parameter has a description). The description itself does not elaborate on parameter semantics, such as how mode relates to seasonId/stageId or what include accepts. Agents must infer the relationship from the enum and parameter names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('top scorers'), scoped to 'a season or stage,' which clearly distinguishes it from sibling tools like sm_standings or sm_players. It is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying the target scope ('season or stage'), implying when to use the tool (when top scorer data is needed). However, it does not explicitly mention alternatives or situations where this tool should not be used, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists modes without disclosing data freshness, pagination, error behavior, or side effects. The read-only nature is only implied by 'Get', not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists modes and a use case. Dense and front-loaded with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic purpose and modes, but lacks guidance on mapping modes to parameters, response format, or pagination. With six parameters and no output schema, more detail would materially improve usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% and the description lists mode values that hint at parameter combinations (fixture, bookmaker, market). However, it does not explain which parameters each mode requires or add semantics beyond the schema's enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb phrase 'Get pre-match odds from SportMonks', clearly identifying the resource and scoping it to pre-match. The list of four modes adds further specificity and differentiates from sibling sm_odds_inplay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete use case: 'Useful for comparing with The Odds API data'. It implies when to use by the 'pre-match' qualifier, though it does not explicitly exclude in-play or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It reveals the available modes and the downstream dependency, but it does not mention pagination, output format, or any read-only nature. Since 'Get' implies a read operation and the modes give a sense of behavior, it is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two sentences: the first states the purpose and modes, the second explains the downstream need. Every word adds value, and the most critical information is front-loaded. There is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, a two-sentence description is incomplete. It does not explain pagination via 'page', the role of 'include', the expected response structure, or how the different modes behave in detail. The description only covers the basic purpose and one dependency, leaving significant gaps 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain the parameters, but it only lists mode values. It implicitly suggests that 'by_id' uses 'id', 'by_team' uses 'teamId', and 'search' uses 'searchQuery', but it does not explicitly define parameters like 'page', 'include', or 'id'. Most parameter semantics are left entirely to the schema property names, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get football seasons', which is a specific verb+resource that clearly states the tool's function. It also lists the four modes ('all', 'by_id', 'by_team', 'search'), adding precision and distinguishing it from sibling tools like sm_leagues or sm_standings by focusing specifically on the season entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Season IDs are needed for standings, statistics, and topscorers' explicitly tells the agent when this tool is relevant—whenever season IDs are required for downstream endpoints. However, it does not explicitly mention when not to use it or name alternative tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It adds useful behavioral info ('whitelist of known participants' and 'Cost: 1 quota'), which goes beyond a trivial restatement. However, it omits details such as authentication requirements, error behavior, or return format, so it only partially discloses the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence plus a cost note. Every word earns its place, with no padding or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is quite complete: it states the purpose, the input scope, a qualification ('whitelist'), and a cost. It lacks an explicit output shape, but the verb 'List' implies an array, and there is no output schema to obligate further detail. It covers the essential context for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the single 'sport' parameter as 'Sport key', and the description merely says 'for a sport', adding no new semantic information. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List teams/players') and the resource ('for a sport'), with the clarifying phrase 'whitelist of known participants' that distinguishes it from other list tools like odds_get_sports. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to get participants for a sport) but does not explicitly compare to sibling tools like sm_teams or sm_players, nor provide any exclusions or alternative-use guidance. It's a clear but not fully elaborated usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get' (implying read-only) and lists modes, but provides no details on pagination behavior, response format, rate limits, or data freshness. This is a significant gap for a tool with 12 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences with the verb-led purpose first, a compact list of supported modes, and a closing positional statement. Every word earns its place with no fluff or repetition, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with 12 parameters and six modes, but the schema's per-parameter descriptions already cover syntax and associations. The description adds the 'core endpoint' context and a mode overview, which is enough given the schema richness. It could mention pagination or includes, but schema covers those, so this is slightly above average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, so the baseline is 3. The description's mode list adds a high-level overview but is mostly redundant with the schema's enum and per-parameter notes. It adds no extra semantic depth beyond the schema, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get football fixtures' with a specific verb and resource, and enumerates six distinct query modes (by ID, by date, etc.). This clearly differentiates it from sibling tools like sm_livescores or sm_schedules, and 'core endpoint for match data' reinforces its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing all supported modes, and calling it 'the core endpoint' signals it is the primary fixtures tool. However, it does not explicitly state when to use alternatives or exclude sibling tools, so it lacks full comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the name: cost formula ('Cost: 10 × markets × regions'), plan restriction ('PAID PLANS ONLY'), and data availability/interval specifics. These are meaningful behavioral traits. It does not mention potential errors or response format, but the cost and plan info are significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear purpose sentence, followed by availability data, then cost/plan constraints. It front-loads the main action and uses every sentence productively, without any fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters and no output schema, the description covers the key contextual aspects: purpose, availability, cost, and access restriction. It doesn't describe the return structure, but the name and purpose imply a snapshot of odds. Given the moderate complexity, the description is fairly complete, though it could benefit from a brief note on response format and sibling alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%), so the description must compensate. It mentions 'markets' and 'regions' only in the cost formula, giving some indirect meaning. However, it does not explain the other parameters (bookmakers, oddsFormat) or provide details on valid values, formats, or relationships. The description adds minimal parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get a snapshot of odds at a specific historical timestamp'. It uses a specific verb ('Get'), a clear resource ('snapshot of odds'), and a specific qualifier ('historical timestamp'). This distinguishes it from sibling tools like odds_get_odds (current odds) and odds_get_historical_events, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for historical odds with the phrase 'historical timestamp' and provides availability constraints ('from June 2020, 5-min intervals from Sep 2022'). It also states a prerequisite ('PAID PLANS ONLY'). However, it does not explicitly contrast with alternatives like odds_get_odds for current odds, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by explaining 'live' as 'leagues currently in play' and noting the return purpose. However, it does not disclose behavior around pagination, optional include expansions, or how modes map to required parameters beyond the mode names, leaving some behavioral aspects untold.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose. The mode list is compact and informative, and every word earns its place. No redundant fluff or repetition of schema field names.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, 6 modes, no output schema, and no annotations, the description covers the basic purpose and mode taxonomy but omits details about pagination (page), include expansion, parameter combined usage, and typical response structure beyond mentioning league IDs. It is sufficient for simple use but not fully complete for a multi-mode tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, which is moderate. The description enhances parameter understanding by correlating modes with parameters: 'by_id' implies id, 'by_team' implies teamId, 'by_country' implies countryId, and 'search' implies searchQuery. This adds meaning beyond the plain schema property descriptions, though it does not explain 'page' or 'include' semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get football leagues' with a specific verb and resource. It further enumerates distinct modes ('all', 'by_id', 'live', by_country', 'by_team', 'search'), which distinguishes it from sibling tools like odds_get_sports that focus on sports or sm_livescores on live scores. The note about returning league IDs for other endpoints clarifies its role as a prerequisite tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing modes and stating league IDs are needed for other endpoints, but it does not explicitly say when to use this tool versus alternatives or provide exclusionary guidance. For example, it does not mention that to get scores, one would use sm_livescores. The context is clear but lacks explicit 'when-to-use' or 'when-not-to-use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read operation via 'Get' but does not disclose response format, potential errors, pagination, or the meaning of the 'include' parameter beyond what the schema provides. This adds only basic transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose without redundancy. It is appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description leaves out what a squad entails (e.g., player details) and does not mention the 'include' parameter, which lets users request associated data. Given no output schema, this omission makes the description only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are fully described in the schema (100% coverage), so the description need not add much. It reinforces the role of seasonId by stating 'current squad or squad for a specific season', which matches the schema's description. No additional semantics are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with a specific resource, 'a team's current squad', and clarifies the optional season parameter with 'or squad for a specific season'. This clearly distinguishes it from sibling tools like sm_teams (team information) and sm_players (player data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it is for retrieving a team's squad, either current or for a specific season. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It adds useful behavioral context: 'Cost: 1 quota' and 'PAID PLANS ONLY' indicate cost and access restrictions. The phrase 'as they appeared' also implies snapshot semantics. However, it does not mention rate limits, response format, or data retention.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus two short clauses for cost and plan restriction. Every phrase earns its place, and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the core purpose is clear, the tool has 5 parameters and no output schema. The description does not explain the optional filter parameters (eventIds, commenceTimeTo, commenceTimeFrom) or hint at the response structure. For a moderately complex tool, this leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40% (sport and date have descriptions, eventIds, commenceTimeTo, commenceTimeFrom do not). The description elaborates on the 'date' parameter by calling it a 'historical timestamp', but it fails to give any meaning to the three undocumented optional parameters. With such low schema coverage, the description should compensate more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List events as they appeared at a historical timestamp', which specifies the verb, resource, and temporal scope. It also explicitly frames the use case ('Use to find event IDs for historical event odds'), distinguishing it from current-event tools like odds_get_events and other historical odds tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use to find event IDs for historical event odds' provides a clear scenario for when to use the tool. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explains the three modes and suggests the include parameter, but does not disclose any side effects, permissions, response format, or limitations. The description essentially repeats schema information, adding only the general statement that include enriches data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and packs the mode definitions and include guidance without extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool with no output schema, the description adequately covers the core functionality and mode options. However, it omits any mention of the response structure or edge cases, leaving minor gaps for an agent expecting return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for both parameters. The description adds the phrase 'Use include param for enriched data,' which is a minor usage hint but does not introduce new syntax or semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves live football/soccer scores and enumerates three distinct modes (inplay, all, latest), which differentiates it from sibling tools like sm_fixtures or sm_schedules that handle scheduled matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use each mode: 'inplay' for currently playing, 'all' for today's livescores, 'latest' for recently updated. It also hints at using the include parameter for enriched data, but it does not explicitly compare against alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost model ('Cost = unique markets returned × regions') and the restriction to a single event, which are meaningful behavioral traits. It does not cover error handling or rate limits, but the concrete cost and scope disclosures earn a solid score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: what the tool does, how to get the required eventId, and cost implications. There is zero redundancy and all sentences add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the primary purpose, prerequisite, and cost, it does not explain the return format or any response details, and there is no output schema to compensate. For a 6-parameter tool with no annotations, this is a notable gap, but the cost model and single-event focus provide essential context, so it's above minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 67%, and the schema already documents sport, eventId, markets, and regions. The description reinforces the markets flexibility ('any available market') and the eventId source, but adds no new meaning for bookmakers or oddsFormat. With moderate schema coverage and no significant extra parameter details, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get odds for a SINGLE event with any available market', specifying the action, resource, and scope. It distinguishes from siblings by emphasizing 'SINGLE' and mentioning player props, alternate lines, and period markets, which differentiates it from broader odds tools like odds_get_odds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite: 'Use odds_get_events to find event IDs first.' It also implies the single-event scope, which contrasts with potential multi-event sibling tools. However, it does not explicitly name alternatives or state when not to use this tool, so it's clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the operation is a listing (read-only), mentions the absence of quota cost, and specifies the returned data fields. While it does not discuss pagination or error behavior, it covers the essential behavioral traits for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and resource. Every clause adds useful information: scope, return payload, cost transparency, and a pointer to a related tool. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description explicitly lists the returned fields (event IDs, teams, commence times). The four parameters are fully documented in the schema. It could mention how 'live' events are handled or whether results are paginated, but for a list tool with high schema coverage, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with detailed descriptions for all four parameters, including example sport keys and filter semantics. The description adds value by mentioning that sport keys come from odds_get_sports but does not add new parameter meaning beyond the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource ('upcoming and live events for a sport') and states the outputs ('event IDs, teams, and commence times'). It distinguishes itself from siblings like odds_get_scores and odds_get_historical_events by focusing on upcoming/live event listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on when to use the tool: to list events for a sport, and explicitly references odds_get_sports for obtaining valid sport keys. It also notes 'Free — no quota cost,' which helps the agent choose it. It does not explicitly compare to alternatives like odds_get_odds, but the guidance is sufficient for likely use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return type (bookmaker odds for specified markets/regions) and the cost behavior (quota calculation). But it omits other behavioral traits like rate limits, pagination, or whether filters override each other, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. Four short sentences deliver purpose, scope, primary usage, and cost without any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (8 parameters) and absence of output schema/annotations, the description covers the essential context: what it does, when to use it, and cost implications. It does not explain the return structure or edge cases, but the schema provides enough parameter-level detail for an agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 75% of parameters with descriptions. The description adds valuable semantic context beyond the schema by explaining the quota relationship ('Cost = markets × regions') and clarifying the tool's scope ('upcoming and live'). This helps the agent understand the trade-offs between markets and regions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('upcoming and live game odds for a sport'). It also distinguishes itself as 'the primary endpoint for pre-game odds analysis', which differentiates it from sibling tools like odds_get_event_odds or sm_odds_prematch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context by calling itself the 'primary endpoint for pre-game odds analysis' and mentions cost implications ('Cost = markets × regions'). However, it does not explicitly exclude alternatives or mention when to use other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the ~30s update cadence and cost behavior, which is valuable. However, the opening statement 'recently completed game scores' conflicts with the later 'Use daysFrom (1-3) to include completed games' and the schema's 'Without this, only live + upcoming are returned', creating ambiguity about whether completed games are included by default. This internal inconsistency undermines clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose. Each sentence earns its place: purpose, refresh rate, and parameter/cost guidance. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacking an output schema and annotations, the description provides essential context: update rate, cost, and daysFrom behavior. It is slightly incomplete due to the ambiguity around 'recently completed' and the lack of any return-format indicators, but for a scores tool it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds cost semantics to daysFrom (cost 1 without, 2 with) and reinforces that daysFrom controls inclusion of completed games. It does not add meaning to sport or eventIds beyond the schema, but those are already adequately described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Get live scores and recently completed game scores', using a specific verb and resource. It clearly distinguishes from sibling tools like odds_get_odds or odds_get_events, and the update-frequency detail further clarifies the live-scores aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use daysFrom (1-3) to include completed games and even notes the cost difference (1 vs 2 credits). However, it does not explicitly name alternative tools or provide exclusionary guidance (e.g., 'use odds_get_odds for odds instead').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful non-schema information by stating the tool is 'Free — no quota cost' and that it returns sport keys, which helps an agent understand cost implications and output relevance. This goes beyond the schema's parameter details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that immediately state the action and then provide key context about output and cost. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is complete: it states what is returned (sport keys), where they are used (other endpoints), and cost behavior. The 'all' parameter is covered by the schema, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single boolean param 'all' with a clear description. The tool description does not add any additional meaning about this parameter, so the baseline of 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List all available sports from The Odds API' with a specific verb and resource. It also distinguishes from sibling tools by noting it returns sport keys used in other endpoints, making its role unique among the odds_get_* group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to discover available sports and obtain sport keys for use in other endpoints. It does not explicitly name alternatives, but the note about sport keys makes the intended usage evident, which is sufficient for this simple list operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the cost ('Cost: 1 quota') and states the outcome ('which market keys are available'), which is important behavioral context. However, it does not mention any side effects, limitations, or return format nuances, preventing a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, usage guideline, and cost. It is front-loaded with the primary action and contains no filler, achieving excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description does explain the return value conceptually (market keys per bookmaker). It provides context for when to use it relative to the sibling tool, and mentions the quota cost. It does not elaborate on response structure or edge cases, but for a discovery tool with moderate complexity, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only 'sport' and 'eventId' have simple descriptions ('Sport key', 'Event ID'), while 'regions' and 'bookmakers' lack descriptions. The description adds no additional parameter details beyond the 'each bookmaker' hint, which only partially explains the 'bookmakers' parameter. This does not compensate for the missing schema information, but the required parameters are at least minimally described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Discover') and clearly states the resource ('market keys available for a specific event from each bookmaker'). It distinguishes from the sibling tool 'odds_get_event_odds' by explicitly noting its role as a precursor, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use: 'Use this before odds_get_event_odds to know which markets to request.' This provides a clear usage sequence and identifies the alternative tool, fulfilling the when-to-use criteria perfectly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses important behavioral traits: cost formula ('Cost: 10 × markets × regions'), plan requirement ('PAID PLANS ONLY'), and a feature limitation ('player props (available after 2023-05-03)'). This goes beyond basic purpose, though it does not mention response format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: stating the core function, noting market support and a date constraint, and providing cost/plan information. There is no redundancy or filler; every sentence adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, cost, plan restrictions, and market support, which is adequate for a historical-odds retrieval tool. Lacking an output schema and annotations, it could add more on response format or limitations, but given its straightforward nature and clear sibling distinctions, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (43%) with descriptions only for `date`, `sport`, and `eventId`. The description adds semantic value by explaining cost scaling related to `markets` and `regions`, and by noting that 'all markets' including player props are supported (relevant to `markets`). It does not explain `bookmakers` or `oddsFormat`, but `oddsFormat` has an enum in the schema, providing some self-documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get historical odds for a SINGLE event at a specific timestamp,' specifying the verb, resource, and scope. 'SINGLE event' differentiates it from `odds_get_historical_odds` which likely handles multiple events, and 'specific timestamp' distinguishes it from current-odds tools like `odds_get_event_odds`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by emphasizing 'SINGLE event' and 'specific timestamp,' indicating when this tool is appropriate (historical odds for one event at a precise time). It does not explicitly name alternatives or provide exclusion criteria, but the emphasis on single event offers enough contextual guidance. 'PAID PLANS ONLY' also signals access requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sports-mcp-server MCP server](https://glama.ai/mcp/servers/killautsav-tech/sports-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/killautsav-tech/sports-mcp-server)

Score Badge

Copy to your README.md:

[![sports-mcp-server MCP server](https://glama.ai/mcp/servers/killautsav-tech/sports-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/killautsav-tech/sports-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/killautsav-tech/sports-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server