Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

mlb_statcast_catcher_blocking_details

Expand a Baseball Savant Catcher Blocking leaderboard row into paginated play-location details using an entity_id from matching Cat, Pit, or Pitching Team rows.

Instructions

Get Baseball Savant Catcher Blocking play details. Expands a Catcher Blocking Cat, Pit, or Pitching Team table row into paginated play-location events. entity_id must come from the matching leaderboard rows and other filters must match that row query. League rows have no detail feed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
teamNoOptional team id or split selector from mlb_discovery
typeNoRow group
limitNoRows per page (1-500)
splitNoSplit details by season
offsetNoZero-based row offset
end_yearNoLast season, start_year through current season
entity_idYesEntity id from a Cat, Pit, or Pitching Team leaderboard row
game_typeNoGame type
start_yearNoFirst season, 2018 through current season
with_team_onlyNoFor a specific Cat or Pit team, include only rows for that team; defaults true

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A4.6/5.0
Behavior4/5

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

No annotations, so the description carries the burden, and it does disclose pagination and a meaningful precondition (league rows have no detail feed). It stops short of describing error behavior, ordering, or rate limits, so it is strong but not exhaustive for a no-annotation 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 short sentences, front-loaded with the action, followed by mechanics, preconditions, and the edge case. No filler and every sentence adds 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?

For a 10-param read tool with full schema documentation and no output schema, the description covers action, mechanics, and precondition well; it hints at returns via 'paginated play-location events' but does not sketch the response shape, which is the only real gap.

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% (baseline 3), and the description adds real semantic constraints beyond the schema: entity_id's provenance, the requirement that filters match the originating row query, and the league-row exclusion. It does not clarify the enum vs. free-text interaction between type/team/split further, keeping it from a 5.

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?

States a specific verb+resource (get Catcher Blocking play details) and explicitly differentiates itself from the sibling leaderboard tool by describing its role: expanding a leaderboard row into paginated play-location events. An agent can distinguish it from mlb_statcast_catcher_blocking and the other *_details siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit preconditions: entity_id must come from matching leaderboard rows, other filters must match that row query, and league rows have no detail feed. These are when-to-use and when-not-to-use constraints that no schema field supplies.

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