SiteCheck Agent Intel & Dev

MLB player season stats and bio from the official MLB Stats

dev_mlb_stats

Read-only

MLB player season stats (hitting or pitching) and bio from the official MLB Stats API (statsapi.mlb.com). Input is the MLB person id; season stats only, no game feed. Free public data, MLB copyright applies. Related tools on this server, for a different need: dev_mlb_statsapi when you need MLB games for one date from the official MLB Stats API; dev_nba_stats when you need NBA player season statistics, sorted leaderboard: per. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "playerId": "<playerId>"
    },
    "name": "dev_mlb_stats"
  }
}

Input Schema

Name	Required	Description
`group`	No	hitting (default) or pitching
`season`	No	Season year YYYY (default: 2025)
`playerId`	Yes	MLB person id, e.g. 660271 (Shohei Ohtani)

Output Schema

Name	Required	Description	Default
`team`	No
`group`	No
`stats`	No
`player`	No
`season`	No
`source`	No
`checkedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds material context beyond them: the data is free public MLB data with copyright restrictions, and each successful call costs $0.002 USDC via x402 across Base/Solana/Arc, with failed calls not charged. The pricing and billing-failure semantics are exactly the kind of behavioral detail an agent needs before invoking a paid endpoint.

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?

The core purpose and the source are front-loaded in the first sentence, with scope exclusions and pricing afterward. The sibling-routing clause is a bit dense and slightly enjambed, but every sentence carries information an agent would act on.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With annotations covering safety, an output schema covering return shape, and full schema coverage of three parameters, the description only needed to add scope, source, cost, and sibling differentiation — all of which are present.

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 playerId, group, and season are all documented in the schema; the description only reinforces that the input is the MLB person id and that stats are season-scoped. It adds no format or default guidance beyond what the schema already supplies, so baseline 3 is appropriate.

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 and resource — player season stats (hitting or pitching) plus bio — plus the upstream source (statsapi.mlb.com) and the identifier it consumes. It also explicitly scopes out the game feed and names the sibling dev_mlb_statsapi as the tool for games, so an agent can distinguish it from neighbors without opening the schema.

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 alternatives and the conditions that select them: dev_mlb_statsapi for MLB games on a single date, dev_nba_stats for NBA season statistics. It also states the negative case ('season stats only, no game feed'), leaving little to inference about when this tool is the right choice.

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

All SiteCheck Agent Intel & Dev tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?