Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

puntersedge_sport_best_odds

Read-onlyIdempotent

Find best price per selection across bookmakers for a sport's upcoming events, with all prices and arbitrage flag. Costs 3 credits; invalid sport returns 404.

Instructions

Best available price per selection across all books for one sport's upcoming events, with every book's price alongside and an arbitrage flag. Costs 3 credits. An unknown sport_key returns 404 and costs nothing.

Returns: [{id, sport_key, home_team, away_team, commence_time, selections:[{name, best_price, best_bookmaker, all_prices:[{bookmaker, price}]}], arb_exists, arb_profit_pct}] (top-level ARRAY). arb_exists is true when the best prices ACROSS books beat the field; all_prices carries every book's price on that selection, so the spread is readable without a second call.

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 selection across books for the AFL {"sport_key": "afl"}

Auth: needs your own key in PUNTERSEDGE_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sport_keyYessport_key from puntersedge_sports, e.g. afl, nrl, soccer_epl. There is no racing sport_key — for racing use puntersedge_racing_best_odds. Required — part of the URL path.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.33.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations by disclosing credit cost, the no-charge 404 failure mode, and an explicit caveat that the documented response shape is unverified and should be inspected before relying on field names. That caveat is exactly the kind of risk signal an agent needs.

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 behavior, then returns, caveat, example, and auth in a logical order. It is longer than strictly minimal, but the return-shape block and the unverified-payload warning both earn their space.

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 burden and does: it documents the array return shape, the meaning of arb_exists and all_prices, cost, and auth. Nothing needed to call this one-parameter tool correctly is missing.

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% and the schema already explains sport_key's provenance and the racing exclusion, so the baseline is 3. The description's concrete example ({"sport_key": "afl"}) adds a usable call template, lifting it slightly above baseline.

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 ('Best available price per selection across all books for one sport's upcoming events') with a clearly bounded scope (one sport, upcoming events). An agent can immediately distinguish it from the racing best-odds sibling and the single-book odds tool by resource and scope.

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 operational guidance: costs 3 credits, an unknown sport_key returns 404 at no cost, and needs a key in PUNTERSEDGE_API_KEY. It does not explicitly say when to prefer this over puntersedge_sport_odds, though the schema's exclusion of racing sports provides partial 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