Skip to main content
Glama

SportStatsAPI

by com.sportstatsapi
OverviewDiscussionsAdmin

get_matches

Read-only

Matches (fixtures and results) by day or date range, optionally of one league, or one team's matches in every competition (team_id; without status or dates its latest results, then live, then next matches; with status scheduled only the next ones, with finished only the latest results). Without a date or team: today (UTC). Where known: TV channels by country (where to watch) and a highlights video link.

Input Schema

NameRequiredDescriptionDefault
dateNoday YYYY-MM-DD (UTC); without date, date_from, date_to, team_id or league_id: today only (UTC)
gameNoesports: cs2, dota2, lol or valorant
langNolanguage of team, league and country names: de, es, it or fr (default English)
limitNomax matches (default 20, max 100)
sportYessport (see list_sports)
offsetNoskip this many matches (paging)
statusNoscheduled, finished or live, or a status as the API reports it, e.g. FT or NS; with team_id finished lists the latest first; with team_id and no status or date: latest results then next matches
date_toNolast day YYYY-MM-DD of a range
team_idNoonly this team's matches in every competition (team code (or number) from find_teams; not tennis); without a date all of them
date_fromNofirst day YYYY-MM-DD of a range
league_idNoleague code (or number) from find_leagues
league_nameNoexact league name, picks one division where several share a league id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / date / description
      Previous value: -"day YYYY-MM-DD (UTC)"New value: +"day YYYY-MM-DD (UTC); without date, date_from, date_to, team_id or league_id: today only (UTC)"
  2. Changed2 schema fields changed
    • changedInput schema / properties / league_id / description
      Previous value: -"league id from find_leagues"New value: +"league code (or number) from find_leagues"
    • changedInput schema / properties / team_id / description
      Previous value: -"only this team's matches in every competition (team id from find_teams; not tennis); without a date all of them"New value: +"only this team's matches in every competition (team code (or number) from find_teams; not tennis); without a date all of them"
  3. Changed2 schema fields changed
    • changedInput schema / properties / league_id / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "string"
+]
    • changedInput schema / properties / team_id / type
      Previous value: -"integer"New value: +[
+  "integer",
+  "string"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"scheduled, finished or live, or a status as the API reports it, e.g. FT or NS; with team_id finished lists the latest first"New value: +"scheduled, finished or live, or a status as the API reports it, e.g. FT or NS; with team_id finished lists the latest first; with team_id and no status or date: latest results then next matches"
  5. Changed2 schema fields changed
    • changedInput schema / properties / status / description
      Previous value: -"match status filter as the API reports it, e.g. FT or NS"New value: +"scheduled, finished or live, or a status as the API reports it, e.g. FT or NS; with team_id finished lists the latest first"
    • addedInput schema / properties / team_id
      Added value: +{
+  "description": "only this team's matches in every competition (team id from find_teams; not tennis); without a date all of them",
+  "type": "integer"
+}
  6. Changed1 schema field changed
    • changedInput schema / properties / game / description
      Previous value: -"esports: cs2, dota2 or lol"New value: +"esports: cs2, dota2, lol or valorant"
  7. Changed1 schema field changed
    • addedInput schema / properties / game
      Added value: +{
+  "description": "esports: cs2, dota2 or lol",
+  "type": "string"
+}
  8. First observed

TDQS

A3.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description goes further, disclosing return content (TV channels by country, highlights video link) and default filtering behavior when no filters are given, which is genuine added context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core scope statement is front-loaded, but the rest is a dense run-on sentence with deeply nested parentheses that is hard to parse. Information is present but structure is not optimized for quick scanning.

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?

With 12 parameters and no output schema, the description covers the main usage modes and return content adequately. However, given the tool's complexity, edge cases like paging (offset/limit) interaction and multi-filter combinations are left to the schema rather than addressed.

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 100%, so every parameter is already documented in the schema. The description reinforces the team_id/status interplay and the date-range fields but adds little syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource (matches – fixtures and results) with clear scope variants: by day/date range, by league, or one team across competitions. It is distinguishable from get_match (single) and get_live_matches (live only), though the boundaries with those siblings are only implied rather than named.

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?

Gives concrete context: no date/team defaults to today (UTC), team_id without dates returns latest results then next matches, and status interacts with the team view (scheduled/finished). It stops short of explicitly naming when to prefer get_live_matches or get_match instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All SportStatsAPI toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources