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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful fact that filter values must be sourced from mlb_discovery, but it says nothing about pagination behavior, result volume, or how the three subject types ('pitchers, pitching teams, or league') interact with the type parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the verb and resource before the filter inventory, and no filler text. The long comma-separated filter list is dense but each item maps to a real parameter, so it earns its space.

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

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

With an output schema present and annotations covering the read-only/open-world profile, the description need not explain return values. For a 17-parameter tool it adequately conveys the filtering surface and where to get valid values, leaving only minor gaps around subject-type semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented in the schema, which sets the baseline at 3. The description's enumeration of filters ('season span/split, game type, hand, runner outcome, target base, prior pickoff count, opportunity minimum...') largely restates the schema fields without adding syntax, valid values, or defaults.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Fetch'), a concrete resource ('Baseball Savant Running Game rows'), and the scoping dimension ('for pitchers, pitching teams, or league'). It is clear what the tool returns, though it never distinguishes itself from the close sibling mlb_statcast_running_game_details.

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

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

It explicitly routes the agent to mlb_discovery 'for exact values', which is genuine guidance about how to obtain valid filter inputs. However, it gives no when-to-use/when-not criteria and no comparison against sibling tools such as mlb_statcast_running_game_details or mlb_statcast_baserunning.

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