skipodds

Fixture line movement

get_fixture_movement

Read-only

Time series of how one fixture's fair probabilities moved — timestamped consensus snapshots, oldest first. Use to spot line movement, steam or drift, and to answer "has this shortened since yesterday". Use get_fixture instead for the current price alone. Read-only. An unknown id returns a fixture_not_found error; a series with only one or two snapshots means the fixture was surveyed recently, not that the request failed.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Fixture id, exactly as returned by list_fixtures. Opaque — do not construct or guess one.
`hours`	No	How far back to look, in hours. Defaults to 24. Capped at 72 on free and paid tiers below Scale, 336 on Scale; a larger value is clamped rather than rejected.
`sport`	No	Which sport to query. Omit entirely for soccer, which is the default; every other sport must be named explicitly. Note "football" means American football and "rugby" covers union.

Output Schema

TableJSON Schema

Name	Required	Description
`to`	No	Probabilities at the latest capture.
`from`	No	Probabilities at the earliest capture in the window.
`delta_pct`	No	Signed change in PERCENTAGE POINTS, not percent.
`span_hours`	No	Hours actually covered, which can be less than requested.

TDQS

A4.7/5.0

Behavior5/5

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses concrete behavioral traits: results are ordered oldest first, unknown ids yield a fixture_not_found error, and a series of only one or two snapshots is a normal early-survey case (not a failure). These additions are highly useful for interpreting tool behavior and avoiding false error conclusions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, each earning its place: the first defines the resource, the second gives usage and the alternative, and the third clarifies error handling and edge-case interpretation. It is front-loaded, efficient, and free of 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?

Given the tool has an output schema (so return values need not be explained), annotations, and a moderate parameter count, the description is remarkably complete. It covers purpose, usage, alternatives, error behavior, and how to interpret small result sets, leaving no obvious gaps for an AI agent to select and invoke correctly.

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 baseline is 3. The description adds context like 'fair probabilities' but does not provide new parameter-level semantics for id, hours, or sport that the schema does not already cover. It neither compensates nor falls short, so the baseline 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?

The description opens with a precise, specific verb+resource statement: 'Time series of how one fixture's fair probabilities moved — timestamped consensus snapshots, oldest first.' This clearly distinguishes it from siblings like get_fixture (current price alone) and list_fixtures, which is the explicit alternative given.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description states when to use it: 'Use to spot line movement, steam or drift, and to answer "has this shortened since yesterday".' It also explicitly names the alternative: 'Use get_fixture instead for the current price alone.' This provides clear contextual guidance and an exclusion.

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

All skipodds tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.8/5.0

Disambiguation5/5

Each tool targets a distinct resource and action: fixture current state vs. movement, fixture listing vs. tournament/outright listings, and golf tournaments vs. soccer tournaments are explicitly separated. The descriptions cross-reference each other to prevent confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: get_fixture, get_fixture_movement, list_fixtures, list_golf_tournaments, list_tournament_outrights. The naming is predictable and clearly hierarchical.

Tool Count5/5

Five tools cover the server's purpose without bloat. The scope is focused on reading odds data, and each tool earns its place: current fixture, fixture movement, fixture list, and the two outright market lists.

Completeness5/5

The surface covers the full read-only workflow: discover fixtures, inspect current odds, examine movement, and access tournament outrights for the sports that have them. No major gaps are apparent, and the descriptions explicitly note unsupported sports to avoid dead ends.

Resources

Need Help?