Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

mlb_statcast_sprint_speed

Fetch Baseball Savant Sprint Speed leaderboard rows by season, position, and minimum competitive runs, then filter by team and sort locally.

Instructions

Get Baseball Savant Sprint Speed player rows. Returns player Sprint Speed rows from the Baseball Savant leaderboard. The source filters season range, position, and minimum competitive runs; team filtering and sorting are applied locally. Use mlb_discovery for every closed value set.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoLocal sort field
limitNoRows per page (1-500)
offsetNoZero-based row offset
team_idNoMLB team id
positionNoPosition code; omitted is All Positions
sort_dirNoSort direction
max_seasonNoLast season; must be >= min_season
min_seasonNoFirst season
minimum_runsNoMinimum competitive runs

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses the filtering model ('source filters season range, position, and minimum competitive runs; team filtering and sorting are applied locally'), which tells the agent where filtering happens. It is silent on pagination behavior, default sorting, return shape, and any auth/rate considerations.

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?

Three sentences, front-loaded with purpose, then filtering behavior, then the mlb_discovery pointer. Efficient and free of filler; the middle sentence carries the real information.

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

Completeness4/5

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

No output schema exists, but the description states what is returned (Sprint Speed player rows) and explains the filtering model. For a leaderboard-list tool with 100% schema coverage on its nine params, this is largely complete, though pagination and default sort behavior are left to the schema.

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. The description goes beyond the schema by clarifying which filters execute server-side at the source versus locally, adding semantic meaning about sort and team_id versus season/position/minimum_runs.

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?

States a specific verb+resource: 'Get Baseball Savant Sprint Speed player rows' and reiterates it returns 'player Sprint Speed rows from the Baseball Savant leaderboard.' The word 'player' implicitly distinguishes it from the sibling mlb_statcast_sprint_speed_teams, but it never names that sibling, so the differentiation is left to inference.

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?

Gives one concrete directive: 'Use mlb_discovery for every closed value set,' which routes the agent for enum resolution. However, it never states when to use this tool versus the closely related teams variant, and no exclusions or prerequisites are given, so usage is only partially covered.

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