Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Royals26 scout Durham Spartans"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Scouting and tactics for the Cambridge Royals (BBF Division 4, 2026), exposed to Claude as an MCP server.
All league data comes from stats.britishbaseball.org.uk, a WBSC-hosted site. This tool only ever reads from it.
Royals26 is a Model Context Protocol (MCP) server: it exposes a set of typed, read-only tools (scouting reports, matchups, lineup prediction, running-game and small-ball tendencies, playoff projection) that an LLM agent — Claude — can call on demand to reason about a live dataset it was never trained on. The model supplies the language and the judgement; the server supplies retrieval, computation and guardrails.
Tool-calling agent design — each capability is a discrete tool with a clear contract, so the model composes them itself ("scout Durham Spartans" fans out into several tool calls).
Grounded, not hallucinated — every tool returns its sample size and caveats, and the data layer is verified against a second source before anything is built on it, so the agent is kept from overclaiming on thin data.
Pipeline behind the tools — a throttled fetch/parse crawler with block
detection (fetch.py, parse.py) caches the source into SQLite (store.py),
an analysis layer computes the domain logic (analysis/), and server.py
wraps it all as MCP tools.
Related MCP server: Statcast MCP Server
python -m venv .venv && .venv/bin/pip install mcp
.venv/bin/python -m royals26.sync # first run: ~20 minutes
claude mcp add royals26 -s user -- /home/peterg/Code/Royals26/.venv/bin/python -m royals26.serverThen ask Claude things like "scout Durham Spartans", "predict the Herts Hawks lineup", "who should bat leadoff if Kung isn't available?".
→ USAGE.md is the guide to actually using it: the full tool reference, how to keep the cache current, and what not to trust. The rest of this file is about where the data comes from and how far it can be pushed.
Verified against the live site before building anything on it.
Available | Notes |
Pitch-by-pitch | One row per pitch: count, outs, runners, batter, pitcher, and a human-readable narrative. |
Pitch outcome |
|
Lineup cards | Batting slot, position and substitution flag for every player in every game. |
Handedness | Bats/throws per player, from rosters and box scores. |
Season leaderboards | An undocumented JSON endpoint returns full-season batting, pitching and fielding for all 686 players. |
Batted-ball type |
|
Platoon splits | Not from the site — computed here by joining each plate appearance to the pitcher's handedness. 1,488 PA vs LHP league-wide against 13,409 vs RHP, so vs-LHP samples are small and flagged. |
Hit location |
|
Not available | Consequence |
Pitch location |
|
Hit coordinates |
|
Pitch type |
|
Exit velocity | Never populated. |
The site's split filters | The stats page advertises 24 splits (vs_left, scoring_position, ahead_count…). Every one returns |
Anything the tools report carries its sample size. Division 4 is amateur Sunday baseball — a rate over 20 plate appearances is a hint, not a fact.
Worth knowing before reading any per-game number. League games are scheduled for five innings and teams play two of them on a game day. The playoffs are longer, and not uniformly:
Round | Date | Innings | Format |
Quarter-final | Sat 5 Sep | 9 | single game |
Semi-final | Sun 13 Sep | 9 | single game |
Final | Sat 19 – Sun 20 Sep | 7 | best of three at Farnham, two on the Sunday |
The final is shorter because two of its three games are played on the same day. A team going all the way plays up to 39 innings in 16 days, against a regular season that has never asked for more than 10 in a day.
The run-difference rule means those innings may not all be played. A game ends early once the losing side has completed this many offensive innings:
Lead | In a 9-inning game | In a 7-inning game |
10 runs | 7 | 5 |
15 runs | 5 | 4 |
20 runs | — | 3 |
Note there is no 20-run rule in a nine-inning game. This matters for pitching plans: against winning opposition the Royals' margin runs at +1.08 an inning, so roughly one game in three is on a pace to finish at the seventh — which argues for using the best arm early rather than saving it for a ninth inning that may never arrive.
Across 302 completed league games:
Innings | Games | What it means |
3 | 3 | abandoned |
4 | 105 | stopped on the time limit or the run rule |
5 | 161 | regulation |
6–7 | 33 | extras |
Two consequences. Every per-game rate the tools report — runs, steals, pitches — is a five-inning rate, so a nine-inning quarter-final is worth about 80% more of each. And a "complete game" here is five innings: nobody on the Royals' staff has thrown more than that, or more than 120 pitches, which makes a nine-inning game a three-pitcher game by arithmetic rather than by choice.
Back-tested over all 32 teams and 444 games, predicting each game from only the
games that preceded it (python -m royals26.backtest "Cambridge Royals"):
Measure | League | Cambridge Royals |
Named the right nine starters | 64% | 68% |
Put a starter in the right slot | 27% | 32% |
And the uncomfortable part: copying the previous game's card scores .268/.629 — statistically the same. The recency weighting earns almost nothing, and a tuning sweep showed nothing longer than a one-game half-life helps at all.
So: treat the nine names as a reasonable guess, the batting order as a weak one, and pay attention to the per-slot alternatives — those are what tell you where a team is unsettled. Nobody should plan a defensive alignment around slot 6.
python -m royals26.verify cross-checks two independent endpoints against each
other. Over 298 games with detail (286 of which have a box score):
final score agrees with the sum of per-player runs in 278; the eight gaps are runs their scorer never attributed to a batter, plus one officially overridden result;
plate-appearance counts derived from the play stream match the box-score column in 289;
every play resolves to a real batter and pitcher;
4 of 596 team-games list something other than nine starters;
every team's W-L in the standings matches the record computed from the game results — all 32 agree exactly.
Not documented anywhere, and it shapes every scoring number in this project. Across 3,253 half-innings the distribution of runs scored is smooth from 0 to 4, then piles up at exactly 5:
Runs in a half-inning | Innings 1 to N−1 | Final inning |
4 | 7.8% | 8.0% |
5 | 20.9% | 7.2% |
6 | 0.5% | 3.1% |
7+ | 0.1% | 5.9% |
Outside the final inning, a half-inning almost never scores more than five — 61 of the 77 six-plus innings all season are in the last inning of a game. That is a five-run cap with an open final inning, and it has two consequences worth holding onto:
It compresses scoring differences and helps the weaker side. A team whose underlying rate is 3.3 runs an inning loses 30% of them to the cap; one at 2.2 loses 19%. Being much better on offence is worth less here than the raw rates suggest.
Any simulation has to model it. Fitting runs per inning without the cap produces blowouts that cannot happen and badly overstates how often the run-difference rule fires.
hitdistance is a scorer's finger on a diagramPopulated on 99.4% of balls in play, and tempting to read as batted-ball quality. Don't. The scorer taps roughly where the ball went on a field map, and the app converts that to a distance — so the values cluster hard on a handful of numbers (179 ft appears 2,552 times, 113 ft 1,375, 94 ft 1,050) and two singles to left centre both read 179 ft whether one was scorched and the other looped.
It is coarse by construction, inconsistently applied, and per the club sometimes given lip service. Measured the same way as the called-strike problem, its game-to-game spread is 1.5× what chance allows (sd 12.9% against a binomial 8.6%, range 22.6% to 84.8% of balls reaching 150 ft).
It is not useless — it correlates sensibly with outcomes (outs average 114 ft, hits 182, doubles 230, home runs 296) and a player's figure draws on many different games, so scorer noise partly averages out. But on the sample sizes this squad produces, the confidence intervals are far too wide to separate two hitters. For contact quality, count extra-base hits instead: a double is a runner on second base, recorded as an outcome with no judgement in it.
Games are scored by different volunteers, and the distinction between a called and a swinging strike is not applied consistently. Across the 287 games with 40 or more of them:
Share scored called | mean 61.3%, sd 13.4% |
Range | 0% to 86% |
Expected sd if scoring were consistent | 6.6% — observed is 2.0× that |
Two games record zero called strikes across 46 and 59 strikes respectively. That is not baseball; it is a scorer who never pressed that button. Confirmed independently by a player whose swinging strikeout on 16 Aug is recorded as looking — in a game scored 76% called against his own season average of 61%.
What this does and does not break:
Ball versus strike is a different call and is reliable — so first-pitch strike rates, counts, walk rates and everything derived from the count are sound.
Called versus swinging is not — so whiff_per_swing, swing rates and any
"how passive is this hitter" number carry scorer noise. Treat a swing rate as
a range, not a figure. Where a claim depends on it, test it against the
unambiguous events instead: fouls and balls in play cannot be confused with
a take.
The first-pitch take/swing break-even was re-run three ways — as scored, with swinging strikes dropped, and with every swinging strike treated as a take. The break-even moves from 65.0% to 66.8% to 71.1% and the conclusion holds in all three, because it rests on ball-versus-strike rather than on how the strike was taken.
gamestatus is not a booleanWorth knowing if you touch the queries. The site uses four values, and the obvious reading of "3 means final" is wrong:
Value | Meaning | Count |
0 | fixture not yet played | 80 |
2 | final, recently played | 18 |
3 | final | 266 |
4 | forfeit — always 7-0, no box score at all | 12 |
Filtering on status = 3 silently hid 32 completed games including everything
played in the preceding fortnight, and status != 3 reported those same games
as upcoming fixtures. Use PLAYED_STATUSES for "has this been played" and
BOX_SCORE_STATUSES for "is there a box score to fetch".
The site sits behind CloudFront with a rate-based WAF rule. A full crawl at
1 request/second earned a blanket 403 across the whole site after ~270 requests
(box score pages are ~1.4 MB each). The default is now 3 seconds plus jitter,
and raw payloads are cached in raw_box, so:
a full crawl only ever happens once — parser fixes re-run offline via
sync.reparse_all();
completed games are immutable and never re-fetched;
on a 403 the sync stops immediately rather than working through the queue, and resumes where it left off.
Override with ROYALS26_REQUEST_INTERVAL=5 if you want to be gentler still.
royals26/
├── fetch.py HTTP with throttling, jitter and block detection
├── parse.py Inertia data-page extraction, roster tables
├── store.py SQLite schema and upserts
├── corrections.py Local fixes to wrong source data, re-applied on write
├── render_pdf.py reports/*.md -> print-ready A4 PDF via headless Chromium
├── sync.py Orchestration; reparse_all() works offline
└── analysis/
├── common.py Team/player resolution by id, code or name
├── lineups.py Lineup prediction, probable pitcher, batting order
├── pitching.py Stamina curves, count behaviour, hitter profiles
├── tactics.py Running game, count tendencies, small ball, splits
├── playoffs.py Bracket and seed projection
└── scouting.py The composed pre-game report
data/
├── league.db The cache
├── corrections.json Player details the site has wrong
└── playoffs.json Snapshot of the "Baseball26" Google Sheet
reports/ Game reports as markdown, plus rendered PDFsThe bracket is not on the BBF site — it lives in a Google Sheet, snapshotted to
data/playoffs.json. On standings as at 17 Aug the Royals are the 2 seed
and host QF2 on Sat 5 Sep against Bristol Buccaneers, the 7 seed — then, if
they win, host SF2 on Sun 13 Sep against whoever comes out of QF3 (Plymouth
Outlaws 1 or Durham Spartans). The home semi-final belongs to the QF1/QF2 winner
by bracket position, not by seed, so seeds 1 and 2 both host throughout.
Cambridge and Herts Hawks are both 21-1 (.955). The league handbook breaks a win-percentage tie on runs conceded, fewest first, and Herts have allowed 88 to Cambridge's 137 — so Herts take the 1 seed and Cambridge the 2.
projection() implements this: seeds sort on (-pct, runs_conceded), and the
result reports ties_settled_on_runs_conceded alongside any that are still
level on both. Before the rule was known it sorted on percentage alone, which
let ties fall out of database row order and quietly invented a seed order —
worth remembering as the failure mode of any "projection" that has no rule
behind it.
The practical consequence is the semi-final, not the quarter. Seed 2 draws Bristol (17-7) rather than Sheffield Bladerunners 2 (14-8) in the quarter, which is close to a wash — but it puts Plymouth Outlaws 1 (21-3), the strongest side outside the top two, in the same half.
The seeding rule is stated on the league's fixture sheet, which lists the quarter-finals by seed rather than by team: division winners seed 1–6 by win%, then the SWWBL and North runners-up take seeds 7–8, also by win%. Pairing is the conventional 1v8, 2v7, 3v6, 4v5, higher seed hosting.
The team names typed into the bracket page of that sheet do not follow from
this rule — Bracknell and Durham are division winners sitting where seeds 7–8
must be runners-up. They're placeholders from before the standings settled, so
playoff_projection (seed-based, off live standings) is what the tools report
and playoff_bracket flags the disagreement. Ask Claude to re-read the sheet
when it changes.
What is in the local cache and when it was last refreshed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the tool reads cache state, implying a non-destructive operation, but doesn't explicitly state it is read-only or safe, nor does it describe any side effects. The description is sparse but not misleading, warranting a middle score.
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?
The description is a single sentence that is concise and front-loaded with the key information. Every word earns its place; no fluff. It is exactly as long as needed for a parameterless tool.
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?
Given the tool's simplicity (no parameters, no output schema, likely a simple report), the description is adequate but could add more detail on what the cache affects or why an agent might need this status. It doesn't explain the return format, but with no output schema, a bit more specificity would improve completeness.
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?
The tool has zero parameters, so the schema provides no parameter semantics. The description adds context on what is reported (cache contents and last refresh time), giving some meaning. With 0 parameters, baseline is 4, and the description meets it by stating the resource's state.
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 states a specific resource ('local cache') and the action ('what is in it and when last refreshed'), which is clear enough. However, it does not differentiate from siblings; none of the sibling names suggest direct overlap with cache inspection, but the description could be more explicit about its role relative to the other tools.
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?
The description implies usage (checking cache status) but provides no explicit guidance on when to use it instead of alternatives. It doesn't mention the cache's relevance to other tools or suggest when it should be consulted, leaving that to the agent's reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a team's hitters behave by count — swing, whiff and contact rates.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
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 does disclose the core behavioral output—rates for swing, whiff, and contact—and implies a read-style analytical operation. However, it does not explain behavior when team is null, aggregation scope, or any other side-effect or data-freshness details.
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?
The description is a single compact sentence with no filler, and the key output metrics are front-loaded. It is concise and easy to parse, though it is so short that it misses opportunities to convey usage and parameter context.
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?
For a simple one-parameter query tool, the description gives enough to understand the general purpose and expected output. But without an output schema, it does not describe the return structure, count categories, or behavior when team is omitted, and it does not help an agent choose between closely related sibling stats tools.
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 0%, and the description only loosely refers to 'a team's hitters' without explaining the team parameter's format, allowed values, or null behavior. Since there is a single optional team parameter, the schema provides the type and default, but the description adds essentially no semantic value beyond the property name.
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 clearly identifies what the tool reports: swing, whiff, and contact rates by count for a team's hitters. It is not a tautology and gives a concrete subject and metric set, but it lacks an explicit verb and does not differentiate itself from sibling tools like team_batting or hitter_profile.
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?
There is no guidance on when to use this tool vs. alternatives, and no mention of when not to use it. The description does not name any sibling tool or condition that would select count_tendencies over team_batting or platoon_splits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hitter profile: season line, approach by count, contact type.
| Name | Required | Description | Default |
|---|---|---|---|
| batter | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must bear the full burden of behavioral disclosure, but it only lists output categories. It says nothing about read-only status, data recency, interpretation of 'approach by count,' or any side effects, leaving an agent to guess at the call's semantics.
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?
At one short sentence, the text is brief and front-loads the resource type, but the opening phrase 'Hitter profile' largely repeats the tool name and terms like 'season line' and 'contact type' are unexpanded jargon. It is compact without being fully informative.
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?
For a tool with one required parameter and no output schema, the description should state how to specify the batter and what shape the profile takes; it does neither. The overlap with sibling tools such as count_tendencies makes this ambiguity more costly.
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?
The input schema field name 'batter' is the only clue; the description never mentions the parameter, its accepted format, or how to identify a batter. With schema description coverage at 0%, the description fails to compensate and adds no meaning beyond the bare schema field name.
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 identifies the resource as a batter-facing profile and enumerates its content categories: season line, approach by count, and contact type. This clearly separates it from pitcher_profile, but it lacks a true verb such as 'retrieve' and does not explicitly differentiate it from count_tendencies.
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?
No guidance is provided for when to call this tool rather than similar siblings such as count_tendencies, platoon_splits, or scout_report. The phrase 'Hitter profile' implies a general lookup, but no conditions, alternatives, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
League-wide season leaderboard from the federation's stats endpoint. section is batting|pitching|fielding.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | batting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It identifies the endpoint and scope but does not state how fresh or cached the data is, what the response format looks like, whether authentication is needed, or how results are ordered and paginated.
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?
The description is two concise sentences with no filler: the main purpose is stated first, and the parameter definition is compactly delivered in the second. Every word adds necessary information.
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?
For a one-parameter stats endpoint, this is minimally viable: it names the resource, source, and section choices. However, without annotations or an output schema, it leaves out response format, ordering behavior, and usage caveats that an agent would need for robust invocation.
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?
With 0% schema description coverage, the description compensates well by defining the only parameter's allowed values ('batting|pitching|fielding'), which the schema does not provide. It fully enumerates the choices, though it leaves the precise semantics of each section implicit.
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 states a clear resource ('league-wide season leaderboard') and source ('federation's stats endpoint'), with 'section' defining the sub-category. It uses 'League-wide' to signal scope, which helps distinguish it from team-focused siblings, though it does not explicitly name or contrast alternatives like team_batting or team_pitching.
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?
The 'League-wide' qualifier implies this tool is for league-level stats rather than team-specific or projection tools, giving some contextual guidance. However, it never explicitly says when to use this tool over sibling alternatives or provides exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who the Royals could face in the playoffs, with scouting priority.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | ||
| rounds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It hints at a prioritized list of opponents, but does not disclose whether it computes probabilities, reads cached data, requires initialization, or has side effects. The behavior is largely inferred rather than described.
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?
The description is a single, front-loaded sentence with no filler words. However, its brevity contributes to the lack of context for parameters and usage, so it cannot receive full marks.
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 no output schema and no annotations, the description leaves unclear what 'scouting priority' means, what a result looks like, and how the rounds parameter changes behavior. It works as a label but not as a complete callable-tool contract.
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 0%, and the description never mentions 'team' or 'rounds'. The word 'Royals' may imply a team context, but it does not explain what the team parameter accepts or what the rounds integer controls. The description fails to compensate for the missing schema documentation.
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 reads as listing who the Royals could face in the playoffs, and it adds a distinct 'scouting priority' angle. It does not explicitly contrast this with sibling tools like playoff_projection or playoff_bracket, so it stops short of a 5.
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?
There is no guidance about when to use this tool versus playoff_projection, playoff_bracket, or matchup. 'With scouting priority' is the only implicit hint, but no exclusions, prerequisites, or use cases are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Division 4 teams with group, record and id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It clearly conveys a read-only listing operation over all Division 4 teams and specifies the returned attributes. It does not discuss ordering, pagination, or data freshness, but for a zero-parameter list tool these omissions are minor.
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?
The description is a single, front-loaded sentence with no filler. Every phrase contributes: the action, the scope, and the returned fields.
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?
For a simple zero-parameter tool with no output schema, the description is nearly complete: it states the scope and the returned fields. It could add one note about using this as a team-ID source or how it differs from standings, but nothing essential is missing for invoking the tool.
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?
The tool has zero parameters, so the baseline is 4. The description reinforces that the tool returns all teams with no filtering, which is the only parameter-related information an agent needs.
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 uses a specific verb ('List') and a clear resource ('all Division 4 teams'), and names the returned fields (group, record, id). It is immediately clear what the tool does and it is distinguishable from the more specialized sibling tools like roster, standings, and team_batting.
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?
The usage context is somewhat implied: an agent can infer it is the team-enumeration tool for getting team IDs and basic records before diving into specialized views. However, it does not explicitly state when to use this tool instead of alternatives such as standings or roster, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Head-to-head history between one batter and one pitcher.
| Name | Required | Description | Default |
|---|---|---|---|
| batter | Yes | ||
| pitcher | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals only that this is a historical lookup, but does not disclose data scope, date range, sample-size behavior, or whether an empty matchup returns an empty result. This leaves important behavioral expectations unstated.
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?
The description is a single focused sentence with no filler or redundancy. It communicates the core purpose quickly and is appropriately front-loaded.
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?
Given there is no output schema and no annotations, the description should provide more context about expected return values or usage boundaries. It does not say what the history contains, how it is formatted, or how it differs from related lookup tools, leaving the agent under-informed.
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 0%, so the description must clarify the batter and pitcher parameters. It merely echoes the parameter names without explaining what values are expected, such as player IDs, names, or how to disambiguate players.
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 clearly states the resource: head-to-head history between one batter and one pitcher. It distinguishes this tool from sibling tools like team_batting or pitcher_profile by focusing on a one-on-one matchup, though it lacks an explicit verb like 'retrieve' or 'show.'
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?
There is no guidance on when to use this tool versus alternatives such as hitter_profile, pitcher_profile, or platoon_splits. The description does not mention any exclusions, prerequisites, or context that would help an agent decide this is the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pitcher profile: season line, stamina by pitch count, first-pitch strike rate, count behaviour, batted-ball mix allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| pitcher | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It lists what data is included but does not state whether this is a read-only lookup, whether it requires a specific season context, whether it returns historical or current data, or how the profile is computed. The description is a content summary rather than a behavioral contract.
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?
The description is a single compact sentence that front-loads the resource and then lists the key data dimensions. Every phrase adds information, and there is no filler. It could be slightly more structured, but it is efficient.
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?
For a single-parameter lookup tool, the description covers the main content areas well. However, with no annotations and no output schema, it does not disclose return format, time range, or whether the profile is computed from current season or career data. The missing behavioral context prevents a higher score.
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 0%, so the description must compensate. It does not explain the 'pitcher' parameter format (e.g., name vs. ID), but the parameter name is self-explanatory and the description's listed dimensions imply the parameter selects which pitcher's profile to return. This is adequate but not rich.
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 resource (pitcher) and lists concrete data dimensions (season line, stamina by pitch count, first-pitch strike rate, count behaviour, batted-ball mix). It is clear enough to distinguish from hitter_profile and scout_report, though it does not explicitly name a sibling alternative.
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?
The description implies this is the tool to use for a pitcher's season-level and count-level profile, but it does not state when to prefer it over scout_report, probable_pitcher, or count_tendencies. No exclusions or alternative routing are provided, so the agent must infer usage from the listed data dimensions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each hitter's line against left- and right-handed pitching, computed locally from the play stream. Left-handed pitching is rare in this league so vs-LHP samples are small and flagged accordingly.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | ||
| min_pa | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key data-quality trait: 'vs-LHP samples are small and flagged accordingly.' However, it does not mention whether the operation is read-only (though implied), any rate limits, or how the output is structured. This is partial transparency but not comprehensive.
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?
The description is concise (two sentences) and front-loaded with the main purpose. The second sentence adds relevant data-quality context. However, it could have used the space more effectively to describe parameters, but it is not verbose or redundant.
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?
The description is incomplete for a tool with two optional parameters and no output schema. It doesn't explain what 'line' means (e.g., batting average, OPS), what 'flagged' entails, or how team filtering works. An agent would lack essential details to call the tool correctly and interpret results.
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 0%, and the description provides no explanation of the parameters 'team' or 'min_pa'. The tool's purpose is clear, but an agent cannot infer what these parameters control or how they affect the results. The description does not compensate for the schema gap at all.
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 clearly states the tool's function: 'Each hitter's line against left- and right-handed pitching' – a specific verb and resource. It also adds context ('computed locally from the play stream') that hints at its distinctiveness, but it does not explicitly differentiate from sibling tools like team_batting or hitter_profile. This is clear but not fully differentiated.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention specific use cases, prerequisites, or scenarios where platoon splits would be preferred over other hitting stats. The only contextual hint is that left-handed pitching is rare, but that is a data-quality note, not a usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 2026 playoff bracket as recorded in the Google Sheet snapshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description 'as recorded in the Google Sheet snapshot' only implies a read-only nature. It does not disclose side effects, return format, or any limitations, so the description carries significant burden that is largely unmet.
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?
The description is a single concise sentence with no filler. Every word contributes to identifying the resource and source, and it is appropriately short for a tool with no parameters.
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 no output schema and no parameter guidance, the description should explain what the bracket contains (e.g., teams, rounds, matchups) or when it is current. It only labels the resource as 'the 2026 playoff bracket', leaving the agent to guess its structure and behavior.
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?
The tool has zero parameters, so there is nothing for the description to add. The baseline of 4 applies because the schema already fully describes the parameter surface area.
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 clearly identifies the resource (the 2026 playoff bracket) and its source (the Google Sheet snapshot), which lets the agent distinguish it from the projection-focused sibling `playoff_projection`. However, it lacks an explicit action verb such as 'get' or 'retrieve', so the purpose is clear but not fully specified.
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?
There is no guidance about when to use this tool versus its siblings like `playoff_projection`, `standings`, or `schedule`. The description does not state contexts, exclusions, or alternatives, leaving the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recompute playoff seeds from the live standings using the 1v5/2v6/3v7/4v8 rule. Useful for week-to-week what-ifs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Recompute' implies some computation or possible state update, but the description never says whether this mutates stored data, requires permissions, or is a safe read-only projection. An agent cannot tell if invoking this tool has side effects.
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 short sentences with no filler: the first states the core action and rule, the second states the use case. Every word earns its place.
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?
For a zero-parameter tool with no output schema, the description covers the source data, the exact seed-matching rule, and the intended use case—enough for an agent to invoke it correctly. The only meaningful gap is side-effect clarity, already reflected in behavioral transparency.
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?
The tool has zero parameters, so there is no parameter semantics burden and the baseline of 4 applies. The description correctly suggests there is nothing for the caller to configure.
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 action ('Recompute'), a resource ('playoff seeds from the live standings'), and a precise rule ('1v5/2v6/3v7/4v8'). This clearly distinguishes the tool from generic siblings like standings and playoff_bracket.
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?
The phrase 'Useful for week-to-week what-ifs' gives a clear intended scenario for when to use the tool. It does not explicitly mention when not to use it or name alternatives such as playoff_bracket or likely_opponents, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Predict a team's batting order 1-9 with per-slot confidence, from their recent lineup cards.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | ||
| lookback | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core prediction behavior but does not explain what happens when 'team' is null, how 'lookback' affects the prediction, what the confidence values mean, whether data must be synced first, or what the response shape is. For a prediction tool with zero annotation support, this is insufficient.
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?
The description is a single sentence with no filler or repetition. The key meaning is front-loaded ('Predict a team's batting order 1-9'), and the data source is included efficiently. It is appropriately concise, though slightly under-specified in content.
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?
There is no output schema, no annotations, and 0% parameter coverage, so the description must provide more context. It does not explain the confidence scale, the behavior with a null team, or how 'lookback' changes results. For a tool that could easily be confused with 'suggest_batting_order', the description lacks enough surrounding context to ensure correct invocation.
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 0%, so the description must compensate, but it only indirectly references 'team' and 'recent lineup cards' (which maps to 'lookback'). It does not explain the null default for 'team', the meaning of the integer 'lookback', acceptable values, or how the parameters interact. The description adds minimal semantic value beyond parameter names.
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 uses a specific verb ('Predict') with a clear resource ('a team's batting order 1-9') and even states the output characteristic ('per-slot confidence') and data source ('recent lineup cards'). It is clear and actionable, though it does not explicitly differentiate itself from the sibling tool 'suggest_batting_order', which is similar enough that explicit contrast would help.
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?
The phrase 'from their recent lineup cards' implies the tool should be used when recent lineup data is available and a probabilistic prediction is desired. However, the description gives no explicit when-to-use versus alternatives, no exclusions, and does not mention that 'suggest_batting_order' might be the better choice in other scenarios. Usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who is likely to start on the mound, from rotation pattern and rest.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It mentions the method (rotation pattern and rest) which is useful, but it does not disclose the data source, potential staleness, or any limitations. The behavioral traits are partially transparent but leave significant gaps.
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?
The description is a single, tight sentence that conveys essential information without redundancy. It is front-loaded with the main purpose and then provides the underlying logic, making it easy to scan. There is no filler.
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?
The tool is simple with one optional parameter and no output schema, but the description lacks detail on how the 'team' parameter behaves, what the output looks like, and how it differentiates from sibling tools. Given the simplicity, it is minimally viable but not complete.
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?
The schema provides a single optional 'team' parameter without any description, and the description does not elaborate on how 'team' is used or what values it accepts. Since schema coverage is 0%, the description could add more detail, but the parameter is simple enough that the minimal guidance is somewhat adequate.
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 clearly indicates the tool's purpose: predicting a starting pitcher based on rotation pattern and rest. It uses a specific verb ('likely to start') and resource ('mound'), and the phrase 'from rotation pattern and rest' provides helpful context that distinguishes it from other tools. While it does not explicitly name a sibling, the purpose is clear and specific.
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?
The description implies when to use the tool (when needing probable starting pitcher) but does not explicitly contrast it with alternatives like 'pitcher_profile' or 'matchup'. The team parameter is optional, but the description doesn't clarify what happens when team is null, leaving a gap in usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A team's roster: handedness, position, uniform number, season line.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely lists output attributes without stating whether the operation is read-only, what the response format is, or any side effects. There is no mention of performance, authentication, or data freshness. The description is purely nominal and offers no behavioral context.
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?
The description is a single concise sentence with no filler words. It is appropriately short and to the point, but the brevity comes at the cost of missing critical information. It is front-loaded with the core purpose, but it sacrifices detail for conciseness.
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?
The tool is simple with one optional parameter, but the description is incomplete. It fails to explain the 'team' parameter, the expected input format, or the output structure. Without annotations or an output schema, the description is the only source of context, and it leaves major gaps. The description is adequate only for a very narrow interpretation, not for reliable invocation.
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 0%, so the description must compensate by explaining the 'team' parameter. It does not mention the parameter at all, leaving the agent without any semantic guidance on what 'team' means, how it should be specified (e.g., name, abbreviation), or its optional nature. This is a significant gap for a single-parameter tool.
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 clearly identifies the tool as a roster listing with specific attributes (handedness, position, uniform number, season line). While it lacks an explicit verb like 'get' or 'retrieve', the noun phrase is unambiguous and differentiates it from sibling tools like team_batting or team_pitching by focusing on roster composition.
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?
No guidance is provided on when to use this tool versus alternatives. The description gives no context about use cases, prerequisites, or situations where other sibling tools would be more appropriate. The agent must infer usage solely from the name and attribute list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A team's steal rate, main basestealers and catcher throwing.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It only states what data is returned, but does not mention whether the operation is read-only, any authentication requirements, response format, error conditions, or other behaviors. For a tool that likely performs a data fetch, this is a significant gap.
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?
The description is extremely concise (one short phrase) and uses no unnecessary words. However, it lacks any structural elements like lists or headers, and it is so underspecified that it reads more like an incomplete fragment than a well-crafted description. It earns a middle score for efficiency but loses points for lack of substance.
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?
Given the tool has one optional parameter and no output schema, the description should fully explain what the tool does and what it returns. While it mentions the data categories (steal rate, basestealers, catcher throwing), it does not clarify the output format, whether a team is required, or any edge cases. For a straightforward tool, this is insufficient for an agent to use confidently.
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 0%, so the description must compensate for the undocumented 'team' parameter. The phrase 'A team's' implicitly indicates the parameter refers to a team, but it does not specify acceptable formats (e.g., team ID, abbreviation) or whether a null value means 'all teams'. The description adds minimal meaning beyond the schema's property name.
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 states the tool provides a team's steal rate, main basestealers, and catcher throwing data. This clearly identifies the subject matter and distinguishes it from sibling tools like team_batting or team_pitching. However, it lacks an explicit verb such as 'get' or 'retrieve', making it a noun phrase rather than a clear action statement.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. With no reference to siblings or use cases, the agent has no help deciding between this and similar tools like small_ball or count_tendencies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fixtures and results. Optionally filter by team, and by whether the game has been played.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | ||
| limit | No | ||
| played | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool returns fixtures and results and can be filtered; it does not mention pagination (the 'limit' parameter), default behavior, output format, or any side effects. This is a minimal disclosure that leaves the agent guessing about important runtime behavior.
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?
The description is a single efficient sentence with no extraneous words. It front-loads the core purpose and then mentions filters. While it is terse, it is not padded, and its brevity is appropriate for a straightforward retrieval tool.
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?
Given three parameters (one with a default), no annotations, and no output schema, the description is incomplete. It fails to explain the 'limit' parameter, what a default of 30 implies, whether results are sorted, or what the response structure looks like. An agent would need to make assumptions or have external knowledge to invoke this tool reliably.
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 0%, so the description must explain parameters. It clarifies that 'team' filters by team and 'played' filters by whether the game has been played, but it completely omits the 'limit' parameter, leaving its purpose and default unknown. Even for the covered parameters, it lacks specifics like accepted formats or meaning beyond the filter intent.
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 states the tool provides 'Fixtures and results,' which clearly indicates it retrieves schedule information. It is distinct from sibling tools like 'standings' or 'roster' even though it lacks a verb like 'get' or 'fetch.' The purpose is unambiguous enough for an agent to understand the core function.
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?
The description mentions optional filters ('by team' and 'by whether the game has been played') but provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. An agent would not know if this is the right tool for a specific request without additional context, especially given the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full pre-game scouting report on an opponent: predicted lineup, probable pitchers with stamina curves, running game, count tendencies. Returns markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes | ||
| lookback | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the output format (markdown) and the scope of the report, which is useful. However, it does not disclose whether this is a read-only operation, whether it triggers a data fetch or sync, whether it can be slow or rate-limited, or what happens if the team is not in the system. The description adds some behavioral context but leaves significant gaps.
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?
The description is a single, information-dense sentence that front-loads the tool's purpose and enumerates its key content areas, ending with the return format. Every clause earns its place, and there is no repetition of schema information or filler.
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?
The tool has an output schema, so the return structure is presumably documented there, and the description's mention of markdown adds the format. However, the description does not explain the 'lookback' parameter's unit or semantics, nor does it clarify the expected format of 'team'. Given the tool's complexity (aggregating multiple scouting dimensions) and the 0% schema description coverage, the description is not fully complete for an agent to call it correctly without additional inference.
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 0%, so the description must compensate for the schema's lack of parameter documentation. The description does not explain what 'team' should be (e.g., team name, abbreviation, ID) or what 'lookback' means (e.g., number of games, days, or seasons). The default of 8 is present in the schema but its unit and effect are unexplained. The description adds no parameter-level meaning beyond the schema's bare names.
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 states a specific verb ('Full pre-game scouting report'), a clear resource ('an opponent'), and enumerates the concrete content areas (predicted lineup, probable pitchers with stamina curves, running game, count tendencies). It also notes the return format (markdown). This clearly distinguishes it from sibling tools like predict_lineup, probable_pitcher, running_game, and count_tendencies, which each cover only a subset of what scout_report aggregates.
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?
The description implies the tool is the comprehensive pre-game scouting option, and the sibling list makes it clear that more granular tools exist for individual aspects (predict_lineup, probable_pitcher, running_game, count_tendencies). However, it does not explicitly state when to choose this over those alternatives, nor does it mention any exclusions or prerequisites (e.g., whether the team must be synced first). The context is clear but the guidance is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structured (non-markdown) version of the scouting report.
| Name | Required | Description | Default |
|---|---|---|---|
| team | Yes | ||
| lookback | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It only specifies the output representation is structured/non-markdown; it discloses nothing about whether this is read-only, requires permissions, hits network, caches data, or paginates results.
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?
One short sentence with no wasted words. It efficiently puts the core distinguishing fact first, though the piece - but the brevity does it no harm. It earns its place, even though more substance is needed.
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?
For a tool with 2 parameters, no output schema, and no annotations, this description is incomplete: it never states the return value shape, how team/lookback affect results, or when to choose it over scout_report. An agent would have to guess or the schema though.
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 0% and the description names neither parameter. 'Team' and 'lookback' are left underspecified: no unit, no format, no explanation of the default 8. The description provides no value for param understanding.
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?
Names the resource (scouting report) and specifies a differentiator: 'structured (non-markdown) version'. This distinguishes it from the sibling scout_report tool. However, it relies on an implied verb rather than stating what it does directly.
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?
The phrase 'non-markdown version' hints that the markdown sibling exists, but there is no explicit when-to-use or when-not-to-use guidance, no mention of alternatives, and no conditions like 'use this when you need JSON data'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bunt, sacrifice and ground/fly tendencies for a team.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the data category (bunt, sacrifice, ground/fly tendencies) but does not disclose whether the team parameter is required, what happens when team is null, whether it returns season-to-date or projected data, or any rate-limit or data-source behavior.
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?
The description is a single short sentence with no filler, and the key content (bunt, sacrifice, ground/fly tendencies) is front-loaded. It is concise, though it sacrifices useful context for brevity.
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?
For a one-parameter tool with no annotations and no output schema, the description should at least clarify the team parameter's behavior and the tool's scope relative to siblings. It does neither, leaving an agent to guess whether null means 'all teams' or 'default team' and what the returned data looks like.
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 0%, so the description must compensate for the undocumented 'team' parameter. The description mentions 'for a team' but does not explain the accepted format (e.g., team name vs. abbreviation), the meaning of null/default, or how the parameter filters results. This is a clear gap.
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 resource ('small ball' tendencies for a team) and lists the covered behaviors (bunt, sacrifice, ground/fly tendencies), so an agent can tell it is a team-level situational-stats tool. However, it does not distinguish it from siblings like running_game or count_tendencies, and the verb is implicit rather than explicit.
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?
No guidance is given about when to use this tool versus alternatives such as running_game, count_tendencies, or team_batting. The description implies it is for team-level small-ball tendencies, but it does not state conditions, exclusions, or how it differs from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current league standings, grouped by division.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It conveys that results are current and grouped by division, which is meaningful, but it does not disclose ordering, freshness, read-only nature, or whether the data is cached.
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?
The description is a single compact sentence that front-loads the core meaning with no filler or redundant phrasing. Every word earns its place.
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?
For a zero-parameter, simple retrieval tool, the description conveys the essential return content: current standings grouped by division. However, without an output schema, it could slightly improve by specifying what a standing entry includes or how it is ordered.
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?
There are zero parameters, so the description has no parameter semantics to explain. The baseline of 4 applies here because no parameter documentation is needed beyond the empty schema.
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 clearly identifies the resource ('league standings') and the specific scope ('current', 'grouped by division'). This distinguishes it from sibling tools like schedule, roster, and playoff_projection without needing to inspect those definitions.
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?
No guidance is given on when to use this tool versus alternatives. While the zero-parameter design makes its use fairly obvious, the description does not provide context, exclusions, or mention of when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest a batting order with reasoning. Pass available as player names or ids to restrict it to who is actually turning up.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No | ||
| opponent | No | ||
| available | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It does reveal that the tool generates 'reasoning' and that the 'available' parameter restricts the suggestion to specific players. However, it does not disclose whether the tool is read-only, what kind of output is returned (e.g., ordered list, explanation format), or any potential limitations. This is insufficient for a tool with zero annotation support.
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?
The description is two short sentences with no filler. The main purpose is front-loaded, and the parameter-specific guidance is concise and directly helpful. Every sentence earns its place.
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?
Given no annotations, no output schema, and three optional parameters with 0% schema description coverage, the description is incomplete. It clarifies only one parameter and lacks any guidance on return format, data sources, or how it relates to sibling tools such as 'predict_lineup'. An agent would struggle to know whether team/opponent are needed or what the output structure looks like.
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 0%, so the description must compensate for undefined parameters. It does explain the 'available' parameter ('player names or ids'), adding real meaning beyond the schema. However, it completely ignores the 'team' and 'opponent' parameters, leaving the agent without any understanding of their expected values or purpose. This partial coverage is not enough for the tool to be used correctly in all scenarios.
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 clearly states the tool's function: 'Suggest a batting order with reasoning.' This is a specific verb and resource, and it differentiates the tool from general baseball stats tools. However, it does not explicitly distinguish itself from the sibling 'predict_lineup', which could be interpreted as a overlapping or alternative tool.
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?
The description provides some usage guidance by instructing that 'available' should be passed 'as player names or ids to restrict it to who is actually turning up.' This implies when to use the tool—when you have roster availability information—but it does not explicitly state when to prefer this tool over alternatives like 'predict_lineup' or 'lineup' tools. There is no exclusionary or conditional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the local cache from the BBF site. Slow (about 3 seconds per request, and a first run fetches every box score) and the site's CDN rate-limits, so run it weekly, not before each query.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden for this slow, rate-limited operation. It discloses the approximate per-request cost, the expensive first-run behavior, and CDN rate limits. This is unusually candid and valuable context for an agent deciding when to call the tool.
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 deliver the core action, critical performance caveats, and a usage cadence. The most important operational warnings are front-loaded, and every clause earns its place.
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?
For a simple tool with one optional parameter late dated and no output schema, the description covers timing and cost well. However, it omits the semantics of force and does not point to sync_recent as a lighter-weight alternative, leaving a notable gap in what an agent needs to make the best call.
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?
The schema defines one parameter, force, with no description coverage. The tool description never explains what force does or when to set it to true. Since schema coverage is 0%, the description needed to compensate but did not address the parameter at all.
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 states a clear verb and resource: 'Refresh the local cache from the BBF site.' This is specific and immediately signals the tool's function. It does not explicitly differentiate itself from sync_recent, a sibling that likely has a similar refresh purpose.
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?
The description gives explicit cadence guidance: 'run it weekly, not before each query.' This tells the agent when to invoke the tool and when not to. It does not name an alternative like sync_recent, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch only the missing box scores, up to a limit. Use this to work through a backlog gently after a rate-limit block.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior traits. It mentions it fetches 'only the missing box scores' and 'up to a limit,' implying it is non-aggressive and incremental, but it doesn't specify details like whether it respects rate limits, how it determines 'missing', or what happens if limit is reached. It also doesn't describe side effects or return behavior, leaving gaps.
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?
The description is two sentences, front-loading the core purpose and immediately providing usage guidance. Every word earns its place, with no redundancy or filler. It is efficient and structured well.
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?
For a simple tool with one optional parameter and no output schema, the description covers the essential purpose and usage. However, given the lack of annotations and output schema, it would be helpful to mention what the tool returns (e.g., a list of box scores) or how 'missing' is determined. Since the tool is relatively simple, the description is adequate but could be more complete.
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 0%, so the description must compensate for the parameter 'limit'. The description mentions 'up to a limit' which gives some context for the parameter's purpose, but doesn't explain the default behavior (default 20) or what happens with different values (e.g., 0 or negative). It adds minimal meaning beyond the schema's 'Limit' title.
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 clearly states the tool fetches 'only the missing box scores' up to a limit, with a specific verb and resource. While it implies catching up after rate limits, it does not explicitly differentiate from the sibling 'sync_league', which could also sync data, though the 'missing box scores' specificity helps distinguish it.
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?
The description says to use it 'to work through a backlog gently after a rate-limit block,' providing clear context for when to use it (after rate limits, for missing data). It doesn't explicitly state when not to use it or mention alternatives like 'sync_league', but the context is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Season batting line for every player on a team.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden, but it only states the returned data scope. It does not explain behavior for the null default, whether the response is per player, or any read-only/performance implications.
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?
The description is a single sentence with no filler wordsdb. It is concise but somewhat sparse, lacking supporting details that could help an agent use it correctly.
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?
Despite the low complexity, the description omits essential invocation context: no return format, no default-team behavior, and no explanation of the optional team parameter. The absence of an output schema and annotations raises the required burden, which the description does not meet.
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 0% and the only parameter, 'team', is not explained beyond the generic phrase 'on a team'. The description does not clarify allowed team identifiers, what null means, or whether the parameter is effectively required.
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 clearly identifies the resource: season batting line for every player on a team. It allows an agent to distinguish this from siblings like team_pitching and roster, though it lacks an explicit verb such as 'get' or 'list'.
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?
No guidance is given for when to choose this tool versus alternatives like team_pitching, roster, or hitter_profile. The description does not mention any exclusions, prerequisites, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Season pitching summary for a team's whole staff, with rest days.
| Name | Required | Description | Default |
|---|---|---|---|
| team | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description itself must signal the operation, and 'summary' conveys a read-only aggregated result including rest days. It does not specify the return shape or what 'rest days' encompasses, but for a simple one-parameter query the core behavior is visible.
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?
One compact sentence with no filler; the resource, scope, and additional qualifier are all front-loaded. Every word earns its place.
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?
The definition is minimally adequate for a trivial one-parameter summary: it states the output theme and team scope, but it leaves 'rest days' ambiguous and does not clarify the default null behavior or direct agents to sibling tools. Given no output schema or annotations, slightly more context would make it complete.
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 coverage is 0% and the description only alludes to the parameter with 'a team's', adding no detail about accepted values, format, or the default null behavior. The parameter name 'team' is self-explanatory, but the low coverage requires more compensation than this provides.
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 phrase 'season pitching summary' identifies an aggregate data resource, and 'whole staff' distinguishes it from individual-pitcher tools like pitcher_profile and probable_pitcher. It lacks an explicit verb, so it is clear but not maximally strong.
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?
The description implies the tool should be used when a team-level, season-wide pitching overview is needed, and 'whole staff' gestures toward why one would not use pitcher_profile. However, it never explicitly names alternatives or conditions, so this is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cache_statuscount_tendencieshitter_profileleague_statslikely_opponentslist_teamsmatchuppitcher_profileplatoon_splitsplayoff_bracketplayoff_projectionpredict_lineupprobable_pitcherrosterrunning_gameschedulescout_reportscout_report_datasmall_ballstandingssuggest_batting_ordersync_leaguesync_recentteam_battingteam_pitchingScored across 25 tools
Most tools target clearly distinct resources or analytical questions, and the descriptions help separate overlapping areas like hitting stats versus scouting. A few pairs—predict_lineup/suggest_batting_order and scout_report/scout_report_data—could cause hesitation, but their descriptions clarify the difference.
Tool names are readable and descriptive, but they mix styles: verb_noun names like list_teams and sync_recent sit alongside bare nouns like standings and roster, and compound names like small_ball or team_pitching. There is no single consistent convention, but the patterns are not chaotic.
At 25 tools the surface is on the heavy side, though the domain—standings, rosters, stats, scouting, and playoffs—is broad enough that most tools serve a distinct purpose. A few duplicative formats and cache-maintenance tools could be trimmed, but the count is not unreasonable.
The toolkit covers the core analytical workflow well: standings, schedules, rosters, batting and pitching stats, player profiles, matchup history, scouting reports, and playoff scenarios. Minor gaps exist such as no per-game box score retrieval or transaction/roster-move tools, but for a read-only analysis server this is solid coverage.
NFL analytics tools for AI agents: stats, fantasy, injuries, schedules, and advanced analysis.
Gateway between LLM agents and world data through eight tools and a bundled endpoint catalog.
Provides easy access to MLB, Baseball Savant, Statcast, and Fangraphs baseball data. Query detaile…
Calibrated world model for AI agents. 40 tools: world state, markets, trading. Kalshi + Polymarket.
