Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

tab_racing_futures_race

Read-onlyIdempotent

Retrieves a racecard for a futures race using its name, date, and race type, returning runners with fixed-odds prices. Use when the race is identified by name rather than a number.

Instructions

Racecard for one FUTURES market: futures URLs put the race NAME (not a number) in the race slot, so the integer-typed tab_racing_race cannot reach them.

Returns: {raceName, raceStartTime, runners:[{runnerNumber, runnerName, fixedOdds:{returnWin, returnPlace, bettingStatus}}]}

Auth: works without a key; TAB_CLIENT_ID or TAB_CLIENT_SECRET or TAB_REFRESH_TOKEN unlocks more if set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesMeeting date from the futures listing, YYYY-MM-DD. Required — part of the URL path.
raceNameYesRace name from the futures listing, e.g. "Queen Anne Stakes (All In)". Required — part of the URL path.
raceTypeYesRace code: R/G/H. Required — part of the URL path.
fixedOddsNoInclude fixed-odds prices (futures are fixed-odds only).
jurisdictionNoState jurisdiction.NSW
venueMnemonicNoFutures meeting name, e.g. "Racing Futures", "Greyhound Futures".Racing Futures

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed7 schema fields changedv0.24.0
    • addedInput schema / properties / date / description
      Added value: +"Meeting date from the futures listing, YYYY-MM-DD. Required — part of the URL path."
    • addedInput schema / properties / fixedOdds / description
      Added value: +"Include fixed-odds prices (futures are fixed-odds only)."
    • addedInput schema / properties / jurisdiction / description
      Added value: +"State jurisdiction."
    • addedInput schema / properties / raceName / description
      Added value: +"Race name from the futures listing, e.g. \"Queen Anne Stakes (All In)\". Required — part of the URL path."
    • addedInput schema / properties / raceType / description
      Added value: +"Race code: R/G/H. Required — part of the URL path."
    • addedInput schema / properties / raceType / enum
      Added value: +[
      +  "R",
      +  "G",
      +  "H"
      +]
    • addedInput schema / properties / venueMnemonic / description
      Added value: +"Futures meeting name, e.g. \"Racing Futures\", \"Greyhound Futures\"."
  2. Addedv0.1.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral context beyond those: the return shape and the auth behavior ('works without a key; ... unlocks more if set'). This gives the agent a solid understanding of what the call returns and what credentials affect.

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 compact and front-loaded with the core purpose. The return shape and auth note are provided in separate short sections with no wasted words. Every sentence earns its place.

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 has no output schema, the description compensates well by including the full return shape. It also covers auth and the differentiator from the sibling tool. It could go slightly further by pointing to tab_racing_futures_meetings as the source for obtaining the required date/raceName values, but that is not essential for correct invocation.

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%, so the baseline is 3. The description adds extra meaning by explaining why raceName is a string rather than a numeric ID and why this tool exists separately from tab_racing_race. This helps the agent populate the required parameters correctly.

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 this is a 'Racecard for one FUTURES market' and distinguishes it from the sibling tab_racing_race by explaining that futures URLs use the race NAME rather than a number. This makes the tool's purpose and scope immediately identifiable.

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 explains when this tool is needed: when dealing with futures markets where race names are used in the URL and the integer-typed tab_racing_race cannot be used. It does not explicitly list exclusions or alternative conditions for non-futures races, but the context is clear enough for an agent to route correctly.

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

Install Server

Other Tools

Latest Blog Posts

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/DanielTomaro13/sportsdata-mcp'

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