Skip to main content
Glama

yahoo_sports_game

Read-only

Fetch one Yahoo Sports game's boxscore with matchup, scores, line score and team stats, plus Yahoo's full source play-by-play events and win-probability points when available. Event objects retain sport-specific fields; arrays can be large and are not paginated. Use yahoo_sports_scoreboard to find games by league, yahoo_sports_team_schedule for a team's games, or yahoo_sports_soccer_scoreboard for a soccer game_url.

Tool call template

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

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

Input Schema

NameRequiredDescriptionDefault
gameNoYahoo Sports game slug from a scoreboard/team-schedule response's game url. Supply this with a direct league key, or use game_url for a soccer source link.
leagueYesRequired. Yahoo league key from yahoo-sports-leagues. Use soccer with game_url for games from the combined soccer scoreboard.
game_urlNoOptional exact game.url returned by a soccer scoreboard. Use only with league=soccer; provide this or game, not both.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / game / description
      Previous value: -"Required. Yahoo Sports game slug from a scoreboard/team-schedule response's game url, e.g. cleveland-guardians-detroit-tigers-460811106."New value: +"Yahoo Sports game slug from a scoreboard/team-schedule response's game url. Supply this with a direct league key, or use game_url for a soccer source link."
    • addedInput schema / properties / game_url
      Added value: +{
      +  "description": "Optional exact game.url returned by a soccer scoreboard. Use only with league=soccer; provide this or game, not both.",
      +  "type": "string"
      +}
    • changedInput schema / properties / league / description
      Previous value: -"Required. League key. One of nfl, nba, wnba, mlb, nhl, college-football."New value: +"Required. Yahoo league key from yahoo-sports-leagues. Use soccer with game_url for games from the combined soccer scoreboard."
    • changedInput schema / required
      Previous value: -[
      -  "league",
      -  "game"
      -]New value: +[
      +  "league"
      +]
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish read-only and open-world behavior, but the description adds important operational context beyond them: play-by-play and win-probability data are conditional ('when available'), event objects retain sport-specific fields, and arrays can be large and are not paginated. Those are exactly the behavioral traits an agent needs before calling a read-only data fetch.

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

Conciseness5/5

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

The purpose and content are front-loaded in the first sentence, the second sentence covers critical behavior (sport-specific fields, unpaginated arrays), and the third sentence handles sibling routing. All three sentences earn their place with no repetition.

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

Completeness5/5

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

With an output schema present and 100% parameter coverage, the description need not explain return structure in detail. It still supplies the operationally important caveats—conditional play-by-play, large unpaginated arrays—making the definition complete for an agent calling a single-game boxscore endpoint.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents game, league, and game_url, including mutual exclusivity and soccer handling. The description reinforces the soccer game_url path but does not add substantial new parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.

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

Purpose5/5

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

The description uses a specific verb and resource ('Fetch one Yahoo Sports game's boxscore') and enumerates the returned content (matchup, scores, line score, team stats, play-by-play, win probability). It clearly distinguishes this single-game tool from the scoreboard and schedule siblings, which return lists of games.

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

Usage Guidelines5/5

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

It explicitly names alternatives and their selection conditions: yahoo_sports_scoreboard for finding games by league, yahoo_sports_team_schedule for a team's games, and yahoo_sports_soccer_scoreboard for a soccer game_url. The agent can route between these tools without inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.