Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

puntersedge_racing_next_to_go

Read-onlyIdempotent

Retrieve upcoming horse, greyhound, and harness races with runners, all bookmaker win/place odds, scratchings, and per-book freshness; filter by country, venue, racing code, or bookmaker.

Instructions

The priced card: the next races with every runner and EVERY bookmaker's win and place price, plus scratchings and per-book freshness. Every country by default — pass country=AU with include_unresolved=true for an Australian card. Costs 2 credits up to 20 races, 3 for 21–60, 4 for 61–200; num_races=200 pulls every currently quoted race in one call.

Returns: [{race_id, venue, venue_id, venue_canonical, venue_site, race_number, category, start_time, country, race_name, distance_m, track_condition, race_class, scratchings:[{name, number, barrier, scratched_at}], runners:[{name, number, barrier, jockey, trainer, bookmakers:[{key, win_price, place_price, age_seconds, stale, refresh_tier, source_url}]}], data_age_seconds, freshest_age_seconds, refresh_tier, stale, stale_bookmakers}] (top-level ARRAY). Freshness is reported WORST-FIRST: data_age_seconds is the age of the OLDEST quote in the race, so read each bookmaker's own age_seconds before comparing two books.

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: Next 5 AU thoroughbred races with every book's price {"num_races": 5, "categories": "horse", "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, e.g. Randwick or Randwick,Flemington. Matched exactly after case folding, so read `venue` off an unfiltered call rather than guessing the spelling.
countryNoComma-separated ISO country codes, e.g. AU or AU,NZ. Omit for every country. Pair with include_unresolved=true or you silently lose most of an AU card.
num_racesNoRaces to return, up to 200. Pass 200 to bulk-pull every currently quoted race instead of paging.
bookmakersNoComma-separated bookmaker keys to restrict to, case-insensitive. An unrecognised key returns a free 422 naming the valid keys.
categoriesNoComma-separated racing codes: horse, greyhound, harness. Omit for all. NZ runs thoroughbred and harness only — there are no NZ greyhounds in the feed.
include_unresolvedNoInclude races whose country is not resolved yet (country is null). Most of an Australian card is unresolved until the meeting is confirmed — 58.8% of horse races in a measured window — so country=AU alone returns far fewer races than actually run.

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?

Annotations cover safety (readOnly, idempotent, openWorld), but the description adds real value beyond them: credit costs tiered by num_races, the worst-first freshness semantics of data_age_seconds, scratchings inclusion, and the auth requirement (PUNTERSEDGE_API_KEY). It also candidly flags that the return shape is unverified vendor doc.

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?

Front-loaded with the core identity sentence, then structured into returns, freshness note, caveat, example and auth. It is long but each section earns its place; only minor duplication (country=AU advice appears in both description and 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?

For a six-parameter tool with no output schema, the description supplies the return shape, the freshness reading rule, cost model, auth and an explicit accuracy caveat, so an agent has everything needed to call and interpret it.

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 100%, so the schema already documents all six parameters in detail. The description adds only marginal semantics (default-all-countries behavior, cost tiers tied to num_races) and largely restates the country=AU guidance that already lives in 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?

States a specific verb+resource: the next races with every runner and EVERY bookmaker's win and place price, plus scratchings and per-book freshness. This clearly distinguishes it from siblings like puntersedge_racing_best_odds (best price only) and the various racecard/next_to_go 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?

Gives clear context: defaults to every country, and directs to country=AU with include_unresolved=true for an Australian card, plus num_races=200 for a bulk pull. It does not explicitly contrast with sibling odds/racecard tools, so no exclusions are 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