Crawlora MCP

mlb_statcast_batted_ball

Read-only

Fetch Baseball Savant Batted Ball Profile rows for batters, batting teams, pitchers, pitching teams, or league totals. Filter by season, game type, split, team, date, batter/pitcher hand, pitch type, BBE thresholds, and local sort/page; use mlb_discovery for exact values. The hidden All-Star game type A is accepted by the upstream query.

Input Schema

Name	Required	Description
`min`	No	Optional minimum batted-ball events: q, 1, 5, 10, 25, 50, 100, 200, 500, or 1000. Defaults to q.
`sort`	No	Optional local sort field from mlb_discovery.
`type`	No	Optional row type: batter, batting-team, pitcher, pitching-team, or league. Defaults to batter.
`limit`	No	Optional number of rows, 1-500; defaults to 100.
`teams`	No	Optional MLB team ids from mlb_discovery; select one or more.
`offset`	No	Optional zero-based result offset, 0-10000.
`splits`	No	Optional split dimensions from mlb_discovery.
`seasons`	No	Optional seasons from 2015 through the current season; defaults to the current season.
`bat_side`	No	Optional batter side: L or R.
`date_end`	No	Optional date range end in YYYY-MM-DD format.
`sort_dir`	No	Optional sort direction: asc or desc.
`min_split`	No	Optional minimum rows per split group: 1, 5, 10, 25, 50, 100, 200, 500, or 1000. Defaults to 1.
`date_start`	No	Optional date range start in YYYY-MM-DD format.
`game_types`	No	Optional game types: R, A, F, D, L, or W. Defaults to R.
`pitch_hand`	No	Optional pitcher hand: L or R.
`split_year`	No	Optional split seasons into separate rows flag: 1 or 0. Defaults to 1.
`pitch_types`	No	Optional pitch type codes from mlb_discovery; select one or more.
`include_league_average`	No	Include the first-party league-average reference row.

Output Schema

Name	Required	Description	Default
`data`	Yes	The tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 7, 2026

addedInput schema / properties / game_types / items / description
```
Added value: +"Documented values: R, A, F, D, L, W."
```

addedInput schema / properties / pitch_types / items / description

Added value: +"Documented values: FF, SI, FC, CH, FS, FO, SC, CU, SL, ST, SV, KN."

addedInput schema / properties / seasons / items / description

Added value: +"Documented values: 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023, 2024, 2025, 2026."

addedInput schema / properties / splits / items / description

Added value: +"Documented values: api_game_date_month_text, game_type, api_pitch_type_group03, bat_side, pitch_hand."

addedInput schema / properties / teams / items / description

Added value: +"Documented values: 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 158."

First observedOct 7, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds one useful upstream quirk ('the hidden All-Star game type A is accepted by the upstream query') but says nothing about pagination limits, result volume, or the shape of the split/row output.

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 the primary action and row types, then filters, then the edge-case note. Efficient with no filler, though the final All-Star sentence is niche for the paragraph's position.

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?

With an output schema present, return values are already covered, and all 18 parameters are documented in the schema. The description supplies the discovery-routing convention and one upstream quirk, making it complete enough for correct invocation.

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%, and the schema itself already repeats 'from mlb_discovery' for teams, splits, seasons, sort, and pitch_types. The description echoes the same filter list and discovery pointer, adding little beyond the schema. Baseline 3 is appropriate.

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?

Specific verb+resource: 'Fetch Baseball Savant Batted Ball Profile rows' with enumerated row types (batters, batting teams, pitchers, pitching teams, league totals). This distinguishes it from the broader mlb_statcast and mlb_statcast_player_details siblings, though it never names a sibling to contrast against.

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?

Gives clear context: the filters available (season, game type, split, team, date, hand, pitch type, BBE thresholds) and an explicit routing rule to 'use mlb_discovery for exact values.' It does not state when NOT to use this tool or how it differs from other mlb_statcast_* endpoints, so it falls short of a full 5.

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

All Crawlora 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.