Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

by DanielTomaro13
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

puntersedge_racing_best_odds

Read-onlyIdempotent

Compare win, place, and tote prices for every runner across bookmakers to find the leading price for each, which book offers it, price spread, and market percentage under 100 for cross-book arbs.

Instructions

Best win, place and tote price per runner across all books, with the book offering it, the spread to the worst price, and a race-level market percentage under 100 when the best prices beat the field. Costs 3 credits.

Returns: [{race_id, venue, race_number, race_name, category, country, start_time, books_compared, market_percentage, runners:[{name, number, barrier, jockey, trainer, best_win:{price, bookmaker, age_seconds, stale, source_url}, best_place:{…}, best_tote:{…}, books_quoting_win, books_quoting_place, price_spread_pct}], scratchings, data_age_seconds, stale}] (top-level ARRAY). market_percentage UNDER 100 = a cross-book arb; any single book is always over 100. ⚠ best_tote is NOT comparable to best_win — a pre-race tote figure is an estimate that moves as the pool fills, and taking the max across books is upward-biased by construction (greyhound pools are thinnest and swing hardest). books_quoting_win and books_quoting_place are DIFFERENT sets.

NOTE: this shape is from the vendor's documentation and has NOT been verified against a live response (we hold no key for this provider). Treat it as approximate — inspect the actual payload before relying on a field name.

Example: Best price per runner across books on the next 5 races {"num_races": 5, "country": "AU", "include_unresolved": true}

Auth: needs your own key in PUNTERSEDGE_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
venueNoComma-separated venue names, case-insensitive. Matched exactly after case folding — read `venue` off an unfiltered call rather than guessing.
countryNoComma-separated ISO country codes, e.g. AU. Foreign races outside Hong Kong are quoted by a median of ONE book, so a cross-book comparison on them compares nothing.
num_racesNoRaces to compare, up to 150. Pass 150 to cover the whole day's card in one call.
bookmakersNoRestrict the comparison to these bookmaker keys, case-insensitive. An unrecognised key returns a free 422 naming the valid keys.
categoriesNoComma-separated racing codes: horse, greyhound, harness. Omit for all.
include_unresolvedNoInclude races whose country is not resolved yet (country is null). Off by default; leaving it off with country=AU drops most of an Australian card.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.33.0

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behavior beyond the readOnly/openWorld/idempotent annotations: a 3-credit cost, the caveat that the documented shape is unverified, the warning that best_tote is not comparable to best_win (estimate, upward-biased), and that books_quoting_win/place are different sets. This is exactly the context annotations cannot carry.

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?

Core purpose is front-loaded in the first sentence, followed by return shape, caveats, example, and auth. It is dense but each block earns its place; the return-shape dump is long but necessary given there is no output schema.

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?

With no output schema, the description carries the full return contract, including nested runner structure, market_percentage semantics, staleness fields, and auth requirements. Nothing an agent needs to call this correctly appears 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?

Schema description coverage is 100%, so parameters are already well documented in the schema, including the venue/country/bookmaker caveats. The description adds little parameter-specific meaning beyond the example, so baseline 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?

States a specific verb/resource: 'Best win, place and tote price per runner across all books.' It clearly distinguishes the resource (cross-book best-price comparison per runner) from siblings such as puntersedge_racing_next_to_go or movers. An agent can tell what this returns without opening the schema.

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 usage example (next 5 races in AU) and embeds guidance on filtering (country/foreign race caveats, include_unresolved). It does not explicitly name when to prefer a sibling (e.g. puntersedge_sport_best_odds or next_to_go), so the routing is implied rather than stated.

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

Deploy Server

Other Tools