Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

mlb_league_stats

Fetch ranked MLB league statistics and season stat splits for both leagues, filtered by group, season, team, league, or stat type.

Instructions

Get ranked MLB league statistics. Returns ranked MLB season stat splits across both leagues. The group enum accepts every value returned by mlb_discovery.

Input Schema

TableJSON Schema

Name	Required	Description
`group`	Yes	Stat group
`limit`	No	Results to return (1-100)
`offset`	No	Zero-based result offset (0-10000)
`season`	No	Four-digit season; defaults to current year
`team_id`	No	Optional MLB team id; discover current team ids with mlb_teams
`end_date`	No	End date for byDateRange stat types; requires start_date
`position`	No	Hitter position; use only with group=hitting
`game_type`	No	MLB game type
`league_id`	No	MLB league id
`stat_type`	No	Stats API stat type; defaults to season
`start_date`	No	Start date for byDateRange stat types; requires end_date
`player_pool`	No	Qualified-player pool
`opponent_team_id`	No	Required by vsTeam stat types
`opponent_player_id`	No	Required by vsPlayer stat types

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv1.17.7Oct 1, 2026

addedInput schema / properties / end_date

Added value: +{
+  "description": "End date for byDateRange stat types; requires start_date",
+  "type": "string"
+}

addedInput schema / properties / game_type

Added value: +{
+  "description": "MLB game type",
+  "enum": [
+    "S",
+    "R",
+    "F",
+    "D",
+    "L",
+    "W",
+    "C",
+    "P",
+    "A",
+    "I",
+    "E"
+  ],
+  "type": "string"
+}

changedInput schema / properties / group / enum

Previous value: -[
-  "hitting",
-  "pitching",
-  "fielding"
-]New value: +[
+  "hitting",
+  "pitching",
+  "fielding",
+  "catching",
+  "running",
+  "game",
+  "team",
+  "streak"
+]

addedInput schema / properties / league_id

Added value: +{
+  "description": "MLB league id",
+  "enum": [
+    "103",
+    "104"
+  ],
+  "type": "string"
+}

addedInput schema / properties / offset

Added value: +{
+  "description": "Zero-based result offset (0-10000)",
+  "type": "integer"
+}

addedInput schema / properties / opponent_player_id

Added value: +{
+  "description": "Required by vsPlayer stat types",
+  "type": "string"
+}

addedInput schema / properties / opponent_team_id

Added value: +{
+  "description": "Required by vsTeam stat types",
+  "type": "string"
+}

addedInput schema / properties / player_pool

Added value: +{
+  "description": "Qualified-player pool",
+  "enum": [
+    "QUALIFIED",
+    "ALL"
+  ],
+  "type": "string"
+}

addedInput schema / properties / position

Added value: +{
+  "description": "Hitter position; use only with group=hitting",
+  "enum": [
+    "C",
+    "1B",
+    "2B",
+    "3B",
+    "SS",
+    "LF",
+    "CF",
+    "RF",
+    "DH",
+    "OF",
+    "IF"
+  ],
+  "type": "string"
+}

addedInput schema / properties / start_date

Added value: +{
+  "description": "Start date for byDateRange stat types; requires end_date",
+  "type": "string"
+}

addedInput schema / properties / stat_type

Added value: +{
+  "description": "Stats API stat type; defaults to season",
+  "enum": [
+    "projected",
+    "projectedRos",
+    "yearByYear",
+    "yearByYearAdvanced",
+    "yearByYearPlayoffs",
+    "season",
+    "standard",
+    "advanced",
+    "career",
+    "careerRegularSeason",
+    "careerAdvanced",
+    "seasonAdvanced",
+    "careerStatSplits",
+    "careerPlayoffs",
+    "gameLog",
+    "playLog",
+    "pitchLog",
+    "pitchArsenal",
+    "outsAboveAverage",
+    "expectedStatistics",
+    "sabermetrics",
+    "sprayChart",
+    "tracking",
+    "vsPlayer",
+    "vsPlayerTotal",
+    "vsPlayer5Y",
+    "vsTeam",
+    "vsTeam5Y",
+    "vsTeamTotal",
+    "lastXGames",
+    "byDateRange",
+    "byDateRangeAdvanced",
+    "byMonth",
+    "byMonthPlayoffs",
+    "byDayOfWeek",
+    "byDayOfWeekPlayoffs",
+    "homeAndAway",
+    "homeAndAwayPlayoffs",
+    "winLoss",
+    "winLossPlayoffs",
+    "rankings",
+    "rankingsByYear",
+    "statsSingleSeason",
+    "statsSingleSeasonAdvanced",
+    "hotColdZones",
+    "availableStats",
+    "opponentsFaced",
+    "gameTypeStats",
+    "firstYearStats",
+    "lastYearStats",
+    "statSplits",
+    "statSplitsAdvanced",
+    "atGameStart",
+    "vsOpponents",
+    "sabermetricsMultiTeam",
+    "projected_Zips",
+    "projected_ZipsRos",
+    "projected_Zips2YR",
+    "projected_Zips3YR"
+  ],
+  "type": "string"
+}

addedInput schema / properties / team_id

Added value: +{
+  "description": "Optional MLB team id; discover current team ids with mlb_teams",
+  "type": "string"
+}

Changed1 schema field changedv1.17.5Sep 26, 2026
- addedInput schema / properties / group / enum
```
Added value: +[
+  "hitting",
+  "pitching",
+  "fielding"
+]
```
AddedAug 4, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It hints at a dependency on mlb_discovery for group values and what is returned, but discloses nothing about permissions, rate limits, or default behavior beyond the schema's own defaults.

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 short sentences, front-loaded with the core purpose and no filler. Each sentence contributes something (purpose, return shape, enum source).

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 14-parameter tool with no annotations and no output schema, the description covers the basic purpose and return shape but leaves behavior (auth, limits, defaults interaction) to the schema. Adequate but not complete given the tool's complexity.

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 14 parameters and their enums. The description adds only a marginal note about the group enum tying back to mlb_discovery, so the baseline of 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?

States a specific verb ('Get') and resource ('ranked MLB league statistics'), then clarifies the scope with 'ranked MLB season stat splits across both leagues.' This distinguishes it from sibling tools like mlb_team_stats and mlb_player_stats, which are team- and player-scoped. It stops short of explicitly naming those alternatives.

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

Usage Guidelines3/5

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

The note that 'the group enum accepts every value returned by mlb_discovery' implies a prerequisite discovery step, which is useful guidance. However, there is no explicit when-to-use / when-not-to-use guidance relative to siblings such as mlb_league_leaders or mlb_team_stats.

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

Deploy Server

mlb_league_stats

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools