Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

mlb_statcast_catcher_framing_details

Fetch paginated pitch-event details for a Baseball Savant Catcher Framing entity_id. Use limit and offset to page through large responses; requires an entity_id from a framing leaderboard row.

Instructions

Get Baseball Savant Catcher Framing pitch-event details. Returns paginated pitch events for a Catcher Framing entity_id. Repeat the leaderboard filters used to obtain the entity; league aggregate rows have no detail feed. The upstream detail response may be large, so use limit and offset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
callNoFraming model
teamNoOptional single MLB team id
typeNoTable group; league details are unavailable
limitNoRows per page (1-500)
offsetNoZero-based row offset
bat_sideNoBatter side
date_endNoInclusive end date
entity_idYesEntity id from a Catcher Framing leaderboard row
game_typeNoGame type
date_startNoInclusive start date
pitch_handNoPitcher hand
pitch_typeNoSingle pitch type
season_endNoLast season
ball_strikeNoPitch location relative to strike zone
min_pitchesNoMinimum pitches
min_resultsNoMinimum results
season_startNoFirst season

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A4.2/5.0
Behavior3/5

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

No annotations, so the description carries the burden. It usefully discloses that the response is large and advises limit/offset, and flags that league rows produce no data. It does not state default page sizes, hard caps, or return field shapes, which leaves meaningful behavioral detail undisclosed for a 17-param read tool.

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?

Four tight sentences, front-loaded with the action, then returns, then the workflow constraint, then the pagination caveat. Each sentence carries distinct information with no filler.

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?

For a 17-parameter tool with no output schema and no annotations, the description covers action, return nature, prerequisite workflow, edge case, and pagination. Missing only low-level operational details like defaults and limits, which are a minor gap given the coverage provided.

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 baseline is 3. The description adds genuine semantics by telling the agent the filter parameters should mirror the leaderboard query used to obtain the entity, and that limit/offset drive pagination. That is meaning beyond the per-field schema descriptions.

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?

Names a specific verb (Get) and resource (Baseball Savant Catcher Framing pitch-event details), and states the return shape (paginated pitch events keyed by a Catcher Framing entity_id). This clearly separates it from the sibling leaderboard tool mlb_statcast_catcher_framing, which the agent must call first to obtain the entity_id.

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?

Provides real workflow context: the entity_id comes from a leaderboard, filters must be repeated from that leaderboard, and league aggregate rows have no detail feed. It doesn't explicitly name the sibling tool, but the when-to-use and the key exclusion are spelled out.

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