Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

puntersedge_sport_odds

Read-onlyIdempotent

Compare pre-match bookmaker odds for one sport's upcoming events, with per-book freshness, data-quality scores, and market-level prices to spot value.

Instructions

Every bookmaker's prices for one sport's upcoming events, with per-book freshness and a data-quality score. Costs 1 credit PER REQUESTED MARKET, so keep markets narrow. PRE-MATCH ONLY — there is no in-play feed.

Returns: [{id, sport_key, sport_title, competition, odds_format, commence_time, home_team, away_team, canonical_event_id, bookmakers:[{key, title, last_update, age_seconds, stale, quality:{score, status, issues, source_count, stale_after_seconds}, markets:[{key:'h2h', quality:{…}, outcomes:[{name, price, point}]}]}], data_quality, data_age_seconds, stale, stale_bookmakers}] (top-level ARRAY). Outcome name is a TEAM NAME, not home/away. An event LEAVES this endpoint the moment it starts — nothing here updates during a match. canonical_event_id joins the same fixture across books that spell the teams differently.

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: Head-to-head prices across every book for the NRL {"sport_key": "nrl", "markets": "h2h"}

Auth: needs your own key in PUNTERSEDGE_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
marketsNoComma-separated markets: h2h, spreads, totals. Billed 1 credit EACH, deduplicated before billing, and an unknown market is a free 422 rather than a paid empty list.h2h
sport_keyYessport_key from puntersedge_sports, e.g. afl, nrl, soccer_epl. There is no racing sport_key — 'horse-racing' returns 404. Required — part of the URL path.
bookmakersNoComma-separated bookmaker keys to restrict to, case-insensitive. An unrecognised key returns a free 422 naming the valid keys.
oddsFormatNoPrice format. One of: decimal, american.decimal
competitionNoFilter to one competition, case-insensitive exact match, e.g. NRLW. A value this sport has never carried returns a 422 listing the ones it has, not an empty 200.
maxAgeMinutesNoExclude bookmaker markets older than this many minutes. The default allows 3-hour supplemental feeds while hiding multi-day stale prices.
include_unknown_competitionNoWhen filtering by `competition`, also return events whose competition is null. On by default because not every bookmaker supplies one and on some sports most of the card is unlabelled — so the filter means 'this competition or unlabelled', not 'this competition'.

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 already cover readOnly/openWorld/idempotent, but the description adds genuinely new behavior: 1 credit per requested market, events leaving the endpoint at start, the caveat that the payload shape is unverified, and auth requirements. This is exactly the value-add beyond annotations.

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-loads the core purpose and cost warning, then the return shape. The return-shape block is dense but earns its place given no output schema exists. Slightly long overall but no filler.

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 7-param tool with no output schema, the description supplies the return shape, freshness/quality fields, billing model, staleness behavior, and the honesty caveat about an unverified payload. Nothing an agent needs to call it correctly 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?

Schema description coverage is 100%, so the schema already documents every parameter in detail. The description reinforces the markets-cost constraint but adds no syntax or semantics beyond what the schema fields provide; baseline 3 applies.

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 and resource ('Every bookmaker's prices for one sport's upcoming events') and immediately scopes it (pre-match only), distinguishing it from racing odds and best-odds siblings. An agent can tell what it 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?

Gives clear context: pre-match only, keep `markets` narrow, point back to puntersedge_sports for sport_key, and the example anchors usage. It doesn't explicitly name a sibling alternative (e.g. puntersedge_sport_best_odds) for the best-price use case, so it stops short of full alternative routing.

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