Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

mlb_statcast_swing_timing

Retrieve Baseball Savant swing timing and miss distance rows for batters, pitchers, teams, or leagues, filtered by season, count, pitch type, zone, and timing flags.

Instructions

Get Baseball Savant Swing Timing and Miss Distance rows. Returns batter, batting-team, pitcher, pitching-team, or league rows with the page's season, game type, pitch-group, split, team, date, swing, contact, zone, pitch hand/type, count, timing-axis, and timing-flag filters. Sorting is local. Use mlb_discovery for exact values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoLocal sort field
typeNoRow type
flagsNoPositive timing flags
limitNoRows per page (1-500)
teamsNoOne or more MLB team ids
countsNoOne or more ball-strike counts
offsetNoZero-based row offset
splitsNoOne or more split dimensions
seasonsNoOne or more seasons
bat_sideNoBatter side
date_endNoOptional range end in YYYY-MM-DD
sort_dirNoSort direction
min_splitNoMinimum swings per split group
not_flagsNoExcluded timing flags
date_startNoOptional range start in YYYY-MM-DD
game_typesNoOne or more game types
min_swingsNoMinimum swing threshold
pitch_handNoPitcher hand
split_yearNoSplit years into separate rows
attack_zoneNoAttack zone
pitch_typesNoOne or more pitch type codes
contact_typeNoContact type
swing_timing_xNoTied-up, centered, or flailed
swing_timing_yNoEarly, on-time, or late
swing_timing_zNoUnder, lined-up, or over

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 behavioral burden. It discloses that results are batter/team/pitcher/league rows and that sorting is local, but it never explicitly states that the operation is read-only, nor does it mention pagination behavior, authentication, or rate limits.

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?

The purpose is front-loaded in the first sentence, and the description is reasonably compact despite enumerating many filter categories. The sentence 'Sorting is local' is largely redundant because the sort parameter schema already says 'Local sort field,' but the overall structure is efficient.

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?

For a 25-parameter tool with no output schema and no annotations, the description covers the main purpose, row types, filter dimensions, and one sibling alternative. It omits pagination behavior despite limit and offset parameters, does not explain returned metric fields, and leaves the relationship to mlb_statcast_swing_timing_details unstated.

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 schema already documents all 25 parameters. The description groups filter categories such as 'season, game type, pitch-group, split, team, date, swing, contact, zone, pitch hand/type, count, timing-axis, and timing-flag filters,' but it adds no syntax, enum, or default-value detail beyond what the schema provides.

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 description states a specific verb and resource: 'Get Baseball Savant Swing Timing and Miss Distance rows.' It also names the kinds of rows returned and routes exact-value lookups to mlb_discovery. However, it does not distinguish this tool from the closest sibling, mlb_statcast_swing_timing_details, so sibling differentiation is incomplete.

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?

The description gives an explicit alternative for a common need: 'Use mlb_discovery for exact values.' That tells the agent when to leave this tool for filter-value lookup. It does not provide a when-not condition or guidance for choosing between this and mlb_statcast_swing_timing_details.

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