Skip to main content
Glama
DanielTomaro13

sportsdata-mcp

puntersedge_racing_movers

Read-onlyIdempotent

Identify racing runners whose odds have moved significantly across multiple bookmakers, revealing steamers (firming) and drifters (drifting) for betting analysis.

Instructions

Steamers and drifters: runners whose price has moved materially since the market opened, confirmed across several books. Costs 3 credits.

Returns: [{runner, number, venue, race_number, category, country, start_time, mins_to_jump, direction:'firming'|'drifting', move_pct, open_price, current_price, books_firming, books_drifting, books_unchanged, books_quoting, books_with_history, bookmakers:[{key, open_price, current_price, move_pct, open_secs_to_jump, points, counted_in_consensus}]}] (top-level ARRAY). move_pct is NEGATIVE for a firming runner (price shortened, money has arrived) and positive for a drifter. open_price is the first price CAPTURED inside the 60-minute pre-race window, not a true market open, and how close that is to 60 minutes varies sharply by book — read each book's open_secs_to_jump rather than assuming.

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: Runners firming 15%+ on at least 4 books {"direction": "firming", "min_move_pct": 15, "min_books": 4}

Auth: needs your own key in PUNTERSEDGE_API_KEY.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMovers to return.
countryNoComma-separated ISO country codes, e.g. AU. Pair with include_unresolved=true or unconfirmed meetings drop out.
directionNoRestrict to one direction. Omit for both. One of: firming, drifting.
min_booksNoOnly report a move confirmed by at least this many books — a one-book move is usually that book, not the market.
categoriesNoComma-separated racing codes: horse, greyhound, harness. Omit for all.
min_move_pctNoMinimum consensus move, in percent.
max_mins_to_jumpNoOnly races jumping within this many minutes.
include_unresolvedNoInclude races whose country is not resolved yet (country is null).

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), yet the description adds real behavioral context: a 3-credit cost, an explicit caveat that the vendor shape is unverified, and the sign convention of move_pct. These are things the annotations cannot convey.

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 definition, then structures Returns/NOTE/Example/Auth sections. The return field enumeration is long but earns its place given no output schema; overall it is efficient though slightly dense.

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 no-output-schema tool with 8 params, an API-key requirement, and a per-call credit cost, the description covers the return shape, the unverified-shape risk, key requirements, and pricing. 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.

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, but the description adds semantics beyond the schema: the sign of move_pct, the meaning of open_price, and the warning to read open_secs_to_jump per book. The example also demonstrates combining direction, min_move_pct and min_books.

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: runners whose price has moved materially, confirmed across multiple books. It contrasts with siblings like puntersedge_racing_closing_lines and puntersedge_racing_best_odds by scoping to in-play price movement, so an agent can route 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (screening steamers/drifters) and the credit cost plus worked example help, but there is no explicit when-not or named alternative among the many racing siblings. The example query gives practical direction but doesn't route the agent away from overlapping tools.

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