TheRundown Data MCP

List all stat definitions

v2GetAllStats

Read-onlyIdempotent

List all stat definitions Read-only Product data or price calculation. Use returned canonical IDs. Access, delay and metered usage follow your connected account; never infer coverage from an empty result. One bounded request, no background polling or automatic retry. Affiliate 27 is excluded. No wagers, account changes or guarantee of returns.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "v2GetAllStats"
  }
}

Input Schema

Name	Required	Description	Default
`query`	No

Output Schema

Name	Required	Description	Default
`data`	No
`plan`	No
`empty`	No
`error`	No
`usage`	No
`status`	No
`message`	No
`event_id`	No
`source_url`	No
`retry_after`	No
`limit_reason`	No
`retrieved_at`	No
`required_plan`	No
`remaining_points`	No
`missing_entitlement`	No
`monthly_remaining_points`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 5, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive and open-world traits, but the description adds genuinely new context: a single bounded request with no background polling or automatic retry, account-dependent access/delay/metered usage, affiliate 27 exclusion, and the warning not to infer coverage from an empty result. That empty-result caveat is especially valuable for an agent interpreting output.

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

Conciseness2/5

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

The text reads as concatenated fragments from multiple fields — 'List all stat definitions Read-only Product data or price calculation.' lacks punctuation and cohesion, and the trailing 'No wagers, account changes or guarantee of returns' is a boilerplate disclaimer. Purpose is front-loaded, but structure is poor.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and annotations cover the safety profile. The operational caveats add real value, but the missing filter semantics and absent sibling routing leave gaps for a list tool sitting among ~80 related endpoints.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes a query object with id and sport_id filters, but the description says nothing about filtering by stat ID or sport ID. With reported schema description coverage at 0% (top-level), the description was expected to compensate and does not, leaving parameter meaning entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The lead sentence 'List all stat definitions' gives a specific verb and resource, and the title reinforces it. It is implicitly distinguishable from data-oriented siblings like v2GetStatsByEvent or v2GetTeamStats, since this returns definitions rather than stat values, though it never explicitly draws that contrast.

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?

The phrase 'Use returned canonical IDs' implies this is a discovery step feeding downstream stat queries, which is useful. However, there is no explicit statement of when to call this versus the many v2GetStats* siblings, nor any exclusion guidance.

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

All TheRundown Data MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.