Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mlb_statcast_home_runs

Retrieve Baseball Savant home run tracking rows for batters or pitchers by season, team, and minimum home runs, then sort and paginate results.

Instructions

Get Baseball Savant Home Runs Tracking. Returns Batter or Pitcher Home Runs Tracking rows. Year, team id, minimum home runs, and Standard/Adjusted mode are first-party filters. The first-party table sorts client-side; this endpoint applies a named local sort and pagination. Use mlb_discovery for the exact filter sets. Per-player home-run plays are available from mlb-statcast-home-runs-details; trajectory images, video media, and CSV downloads are separate representations.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
catNoTrajectory mode
minNoMinimum home run total
sortNoLocal sort column
teamNoMLB team id; blank selects all teams
yearNoSeason
limitNoRows per page (1-500)
offsetNoZero-based row offset
sort_dirNoLocal sort direction
player_typeNoTable type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

TDQS

A3.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the first-party table sorts client-side whereas this endpoint applies a named local sort plus pagination, which is real behavior beyond the schema. However it says nothing about read-only nature, permissions, rate limits, or the shape of returned rows, leaving meaningful gaps.

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?

Purpose and scope are front-loaded in the first two sentences, and each remaining sentence adds routing or behavioral value. It is dense and occasionally clunky in citing sibling identifiers, but there is little dead weight.

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?

There is no output schema and no annotations, so the description must carry the load; it tells the agent what kinds of rows come back and where richer per-play/media representations live. It could be stronger on return fields and any access requirements, but for a filtered stat table it is largely sufficient.

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 seven of nine parameters are enums, so the schema already explains cat, min, sort, team, year, limit, offset, sort_dir, and player_type. The description adds only framing (that year/team/min/cat are 'first-party filters' and sort is local) without new syntax or semantics, so the baseline 3 applies.

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?

Specific verb ('Get') plus resource ('Baseball Savant Home Runs Tracking') and an explicit statement of what rows it returns (Batter or Pitcher Home Runs Tracking). It actively distinguishes itself from siblings by naming mlb-statcast-home-runs-details and mlb_discovery, so an agent can route without opening any schema.

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?

It routes the agent to alternatives explicitly: 'Use mlb_discovery for the exact filter sets' and points to mlb-statcast-home-runs-details for per-player plays, plus notes trajectory images/video/CSV are separate representations. It stops short of stating when NOT to use this tool, but the alternative-routing is clear and actionable.

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