Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

espn_scoreboard

Retrieve scores, schedules, statuses, and odds for a sport and league from ESPN's credential-free public JSON.

Instructions

ESPN scoreboard. Returns games (scores, schedule, status, and odds when available) for a sport and league from ESPN's credential-free public JSON. The sport enum accepts football, basketball, baseball, hockey, and soccer. The league enum accepts nfl, college-football, nba, wnba, mens-college-basketball, womens-college-basketball, mlb, nhl, eng.1, esp.1, ita.1, ger.1, fra.1, usa.1, and uefa.champions; it must be valid for the chosen sport. The seasontype enum accepts 1 (preseason), 2 (regular season), 3 (postseason), and 4 (offseason).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
weekNoWeek number (football leagues)
datesNoDate or range as YYYYMMDD, YYYYMMDD-YYYYMMDD, or YYYY; defaults to the current scoreboard
sportYesSport key
leagueYesLeague key (must be valid for the sport)
seasontypeNoSeason type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.17.5
    • addedInput schema / properties / league / enum
      Added value: +[
      +  "nfl",
      +  "college-football",
      +  "nba",
      +  "wnba",
      +  "mens-college-basketball",
      +  "womens-college-basketball",
      +  "mlb",
      +  "nhl",
      +  "eng.1",
      +  "esp.1",
      +  "ita.1",
      +  "ger.1",
      +  "fra.1",
      +  "usa.1",
      +  "uefa.champions"
      +]
    • addedInput schema / properties / seasontype / enum
      Added value: +[
      +  1,
      +  2,
      +  3,
      +  4
      +]
    • addedInput schema / properties / sport / enum
      Added value: +[
      +  "football",
      +  "basketball",
      +  "baseball",
      +  "hockey",
      +  "soccer"
      +]
  2. Addedv1.5.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It usefully reveals that data comes from "ESPN's credential-free public JSON" (no auth required) and that odds are included only "when available," which is a conditional behavior. It does not cover error handling or output format, but for a read-only scoreboard these gaps 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.

Conciseness4/5

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

The description is front-loaded with the core purpose in the first sentence and then organizes parameter details clearly. The enum lists are a bit long and somewhat duplicative of the schema, but they are still scannable and every major clause contributes useful context. It is appropriately sized for a 5-parameter tool.

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

Completeness4/5

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

All required parameters (sport, league) and optional parameters (dates, week, seasontype) are adequately explained across the description and schema. The return contents are summarized in the opening sentence (scores, schedule, status, odds), and no output schema exists to expect more detail. Missing pieces like pagination or error behavior are not critical for this simple read tool.

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 baseline is 3. The description mostly repeats the enum values already present in the schema, adding only the seasontype numeric-to-name mapping and reiterating the league/sport validity constraint that the schema already states. This is marginal added value, not enough to exceed baseline.

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 opens with a specific verb and resource: "Returns games (scores, schedule, status, and odds when available) for a sport and league." It clearly identifies what the tool produces and implicitly differentiates it from siblings like espn_game_summary or espn_standings by scoping to the scoreboard domain.

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

Usage Guidelines4/5

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

The description gives clear usage context: this is the tool for fetching a scoreboard across a sport/league, with optional date, week, and season-type filters. It does not explicitly name alternative tools or when NOT to use it, but the context is unambiguous enough for an agent to select it for score/schedule/status needs.

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

Deploy Server

Other Tools