How do I use hudl-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@hudl-mcp-server Who is the leading scorer this season?" 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.

hudl-mcp-server

by nick-graves

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

hudl-mcp-server

An MCP (Model Context Protocol) server that connects Claude Desktop to Hudl, giving Claude live access to team stats, player stats, and game results through natural language.

What It Does

Ask Claude questions like:

"Who is the leading scorer this season?"
"What's our record against ranked opponents?"
"Show me player stats for our last game against Beaverton."
"How did our faceoff percentage compare between 2023 and 2024?"

Claude calls the MCP tools, retrieves live data from Hudl, and returns structured analysis — no copy-pasting, no manual exports.

Related MCP server: Discord MCP Server

How It Works

The server uses Playwright to authenticate with Hudl and retrieve data via a combination of page scraping and CSV export interception. A session cookie is cached after the first login so subsequent calls are fast. If Hudl requires 2FA, the browser launches in visible mode so you can complete it manually.

Claude Desktop  →  MCP Tools  →  Hudl (via Playwright)
                ←  JSON data  ←

Available Tools

Tool	Description
`list_seasons`	Lists all available seasons with IDs, sorted newest first
`get_game_results`	Season game results — scores, opponents, home/away, W/L
`get_player_stats`	Full player stat export — goals, assists, shots, faceoffs, turnovers, saves, and more
`get_team_stats`	Aggregated team stats — record, goals scored/allowed, win %
`get_game_stats`	Per-game player stats for a single specific game
`get_box_score`	Team-level box score comparison (AHS vs opponent) for a single game or full season
`clear_cache`	Invalidate cached data — all, by season label, or by game

All tools accept an optional season parameter to query historical seasons. All tools accept an optional refresh: true parameter to bypass cache and re-fetch from Hudl.

Project Structure

src/
  auth/
    hudlAuth.ts           — Hudl login flow, session restore, 2FA handling
  browser/
    browserManager.ts     — Playwright browser lifecycle
    networkInterceptor.ts — API endpoint discovery utilities
  cache/
    sessionCache.ts       — Read/write cached session cookies
  fetchers/
    reportsCsvFetcher.ts  — Navigate to reports page, intercept CSV export
  scrapers/
    gameResultsScraper.ts — Game results from team timeline
    gameStatsScraper.ts   — Per-game player stats with fuzzy opponent matching
    playerStatsScraper.ts — Full player stats via CSV interception
    teamStatsScraper.ts   — Team stats via CSV interception
  config.ts               — Environment variable loading
  types.ts                — TypeScript interfaces
  server.ts               — MCP server definition and tool handlers
  index.ts                — Entry point
  cli.ts                  — Interactive developer test harness

Setup

1. Install dependencies

npm install

This also runs playwright install chromium automatically.

2. Configure environment variables

Copy .env.example to .env and fill in your credentials:

HUDL_EMAIL=your@email.com
HUDL_PASSWORD=yourpassword
HUDL_TEAM_ID=your_team_id
HUDL_CACHE_DIR=C:/Users/<you>/hudl-mcp-server/.cache

To find your HUDL_TEAM_ID, navigate to your team page in Hudl — it's in the URL.

HUDL_CACHE_DIR should be an absolute path. Setting it explicitly ensures the cache is always written to the same location regardless of what directory the process is launched from.

3. Build

npm run build

4. Configure Claude Desktop

Add the server to your Claude Desktop config (%APPDATA%\Claude\claude_desktop_config.json on Windows, ~/Library/Application Support/Claude/claude_desktop_config.json on Mac):

{
  "mcpServers": {
    "hudl": {
      "command": "node",
      "args": ["C:/path/to/hudl-mcp-server/dist/index.js"]
    }
  }
}

Restart Claude Desktop. The Hudl tools will be available in your next conversation.

Testing Without Claude Desktop

A CLI lets you exercise each tool directly from the terminal:

npm run cli

Interactive menu options:

Key	Action
`1–6`	Call each MCP tool directly and inspect the raw JSON response
`c`	List all cache entries (key, age, TTL)
`ci`	Inspect a cache entry — select by number, view full JSON payload
`cc`	Clear cache — all entries, by season label, or by keyword
`w`	Warm season — bulk-fetch and permanently cache all game stats and box scores for a season
`t`	Smoke test — run all tools and report pass/fail

Warming the cache for prior seasons

After a fresh install (or account switch), run the warm command to pre-populate the cache for completed prior seasons. This avoids re-fetching 30+ games every time you run a report:

npm run cli → w → enter "2024-2025" → y (prior/completed)
npm run cli → w → enter "2023-2024" → y (prior/completed)

Takes ~10 minutes per season on first run. Subsequent runs skip already-cached entries.

Notes

First call per session may take 10–20 seconds while the browser starts and authenticates
Session is cached in .hudl-session.json — subsequent calls reuse the session without re-logging in
2FA: if Hudl prompts for verification, the browser will open visibly so you can complete it manually
Read-only: the server never modifies any data in Hudl
.env and .hudl-session.json are excluded from version control — never commit credentials

alc-lacrosse-reports — companion repo that uses this MCP server to generate branded PDF game and season reports

Available Tools

7 tools

clear_cacheA

Invalidate cached Hudl data so the next request re-fetches from Hudl. Use scope="all" to wipe everything. Use scope="season" with a season label (e.g. "2024-2025") to clear all entries for that season. Use scope="game" with a game identifier (opponent name or date) to clear a single game. Omitting scope defaults to "all". After clearing, the next tool call will re-scrape Hudl and rebuild the cache.

ParametersJSON Schema

Name	Required	Description
`list`	No	Set true to list current cache contents without clearing anything.
`scope`	No	"all" (default) = clear everything; "season" = clear one season; "game" = clear one game.
`identifier`	No	Required when scope is "season" or "game". For season: a label like "2024-2025". For game: an opponent name (e.g. "Oregon City") or date (e.g. "Mar 17").

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries burden. It explains that after clearing, the next call re-fetches and rebuilds cache. But it lacks details on synchronicity, timing, or side effects like impact on other users.

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 description is a short, well-structured paragraph without wasted words. It conveys purpose and parameter usage efficiently.

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?

Given 3 parameters, all described in schema, and no output schema, the description covers main functionality and parameter usage. Could mention error handling or prerequisites, but it's fairly complete for a simple cache-clearing tool.

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

Parameters4/5

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

Schema coverage is 100%, baseline 3. Description adds semantic value by explaining scope values with examples and clarifying default behavior, going beyond schema.

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 clearly states the tool invalidates cached Hudl data, specifying the verb (invalidate/clear) and resource (cache). It distinguishes from sibling tools that are all read-only data retrieval operations.

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 provides explicit guidance on using different scope values, defaults, and the 'list' parameter. However, it does not include when-not-to-use or direct comparison with alternatives, though sibling tools are clearly read-only.

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

get_box_scoreA

Get the team-level box score comparison between Aloha and their opponent, showing how each team performed across all statistical categories. Use game="season" to get season averages across all games, or specify a game the same way as get_game_stats: "latest" (default), opponent name (e.g. "Beaverton"), date (e.g. "May 18"), or 0-based index newest-first. Single-game results use totals; season results use per-game averages.

ParametersJSON Schema

Name	Required	Description
`game`	No	Game identifier: "latest" (default), "season" for full-season averages, opponent name, date (e.g. "May 18"), or 0-based index newest-first.
`season`	No	Season identifier. Defaults to current season.
`refresh`	No	Set true to bypass cache and re-fetch from Hudl.

TDQS

A4.5/5.0

Behavior4/5

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

Discloses key behaviors: default game value, difference between single-game totals and season averages, and refresh caching option. No contradictions with annotations (none provided).

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?

Two sentences, front-loaded with purpose, no wasted words. Efficiently conveys all necessary information.

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?

Given 3 parameters, no output schema, and no annotations, the description fully covers how to use the tool and what to expect from results (totals vs averages).

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

Parameters4/5

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

Adds significant context beyond the input schema, explaining the range of game identifiers and the behavioral difference between single-game and season results. Schema coverage is 100%, baseline 3, extra detail earns 4.

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 clearly states it gets the team-level box score comparison between Aloha and opponent, distinguishing it from sibling tools like get_game_stats and get_team_stats.

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?

Provides clear guidance on when to use (for box score comparison) and how to specify games (season, latest, opponent, date, index), but lacks explicit when-not-to-use or alternative tool mentions.

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

get_game_resultsA

Get game-by-game results: opponent, date, score, home/away, and win/loss/tie outcome.

ParametersJSON Schema

Name	Required	Description
`limit`	No	Maximum number of games to return. Omit for all games.
`season`	No	Season identifier. Defaults to current season.
`refresh`	No	Set true to bypass cache and re-fetch from Hudl.

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description must convey behavioral traits. It indicates it's a read operation ('Get') and hints at caching via the 'refresh' parameter, but does not disclose authentication needs, rate limits, or whether results are ordered. Adequate but minimal.

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 description is a single, efficient sentence that front-loads the purpose and lists the result fields. No unnecessary words or redundancy.

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?

Given no output schema, the description partially compensates by listing the output fields. It covers the core results but omits details on pagination or ordering (though 'limit' parameter exists). Fairly complete for a simple list 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% (all three parameters have descriptions in the input schema). The tool description does not add meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'Get' and the resource 'game-by-game results'. It lists the fields returned (opponent, date, score, home/away, win/loss/tie), distinguishing it from sibling tools like get_box_score or get_game_stats which are likely more detailed.

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

Usage Guidelines3/5

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

The description implies usage for basic game results but does not explicitly state when to use this tool versus alternatives (e.g., get_box_score for detailed stats). No exclusions or prerequisites are mentioned.

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

get_game_statsA

Get per-game player statistics for a single specified game: goals, assists, shots, saves, faceoffs, and turnovers for every player, filtered to that one game only. Use the game parameter to identify which game: "latest" returns the most recent game, an opponent name (e.g. "Beaverton") returns the most recent game vs that opponent, a date string (e.g. "May 18") targets that specific game, or a numeric index (0 = most recent, 1 = second most recent, etc.) selects by position. If an opponent was played multiple times in the season, a warning is logged and the most recent match is returned — use a date or index to select a specific game.

ParametersJSON Schema

Name	Required	Description
`game`	No	Game identifier: "latest" (default), opponent name, date (e.g. "May 18"), or 0-based index newest-first. Use a date when the same opponent appears multiple times.
`season`	No	Season identifier. Defaults to current season.
`refresh`	No	Set true to bypass cache and re-fetch from Hudl.

TDQS

A4.4/5.0

Behavior4/5

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 discloses caching behavior with the refresh parameter and notes that a warning is logged for multiple opponent matches. It does not mention auth needs or rate limits, but for a read-only data retrieval tool, this is adequate.

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 action and then provides detailed usage instructions. While slightly long, every sentence serves a purpose and the length is justified given the complex game identification options.

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?

No output schema is provided, but the description lists the stats returned. It covers all three parameters, explains edge cases (multiple opponents, cache), and provides default behaviors. For a tool without nested objects or enums, it is sufficiently complete.

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

Parameters5/5

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

Schema coverage is 100% for all three parameters. The description adds significant value by explaining the game parameter formats in detail, including special cases like 'latest' and numeric indices. It also clarifies defaults and behavior for ambiguous inputs, which goes well beyond the schema.

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 clearly states it retrieves per-game player statistics for a single specified game, listing specific stats (goals, assists, shots, saves, faceoffs, turnovers). This distinguishes it from siblings like get_game_results (team scores) or get_player_stats (likely overall stats).

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 provides detailed guidance on how to identify the game using various formats (latest, opponent name, date, index) and warns about ambiguous opponent names. It suggests using date or index when the same opponent appears multiple times, but does not explicitly state when not to use this tool or mention alternatives.

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

get_player_statsC

Get individual player statistics including goals, assists, points, and games played. Optionally filter by player name.

ParametersJSON Schema

Name	Required	Description
`season`	No	Season identifier. Defaults to current season.
`refresh`	No	Set true to bypass cache and re-fetch from Hudl.
`playerName`	No	Filter by player name (partial match). Omit to get all players.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as caching behavior, data freshness, authentication needs, or side effects. It merely lists fields already present in the schema.

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?

Two sentences, front-loaded with the action and key details. No unnecessary words, though additional context could be added without harming brevity.

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

Completeness3/5

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

With no output schema, the description should explain the full return structure. It lists some fields but omits others (e.g., plus/minus, shots). Also lacks information on pagination, sorting, or error handling. Adequate but not thorough.

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 coverage is 100% with descriptions for all three parameters. The description adds no new meaning beyond 'optionally filter by player name', which is redundant with the schema. Baseline score of 3 is appropriate.

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

Purpose4/5

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

The description clearly states the action ('Get individual player statistics') and lists specific fields (goals, assists, points, games played). It implies differentiation from team-level tools but does not explicitly address sibling tools.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like get_team_stats or get_box_score. Missing context about prerequisites, filters, or when to apply the optional playerName parameter.

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

get_team_statsA

Get overall team statistics for a season: win/loss/tie record, goals scored and allowed, and win percentage.

ParametersJSON Schema

Name	Required	Description	Default
`season`	No	Season identifier e.g. "2024-2025". Defaults to current season.
`refresh`	No	Set true to bypass cache and re-fetch from Hudl.

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavior. It lists returned fields but does not explain caching (though the 'refresh' parameter hints at it) or data source (Hudl mentioned only in refresh param description). No disclosure of side effects or permissions.

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?

A single sentence that is clear, front-loaded, and contains no extraneous information. Every word contributes to understanding.

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

Completeness3/5

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

The description lists key return fields, which compensates for the lack of an output schema. However, it does not specify which team's stats are retrieved (implicitly the current user's team) or whether multiple teams are supported. Minor gap in completeness.

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 coverage is 100%, so the schema already describes parameters. The description adds that season defaults to current season, which is helpful. However, it does not elaborate on the refresh parameter beyond the schema's explanation.

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 clearly states the tool's purpose: to get overall team statistics for a season, listing specific metrics (win/loss/tie record, goals, win percentage). It distinguishes itself from siblings that focus on box scores, game results, or player stats.

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

Usage Guidelines3/5

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

The description implies usage for a season but does not explicitly state when to use this tool over alternatives like get_game_stats or get_box_score. No exclusions or prerequisites are mentioned.

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

list_seasonsA

List all available seasons for the team, sorted newest first. Returns seasonId, label (e.g. "2024-2025 Season"), and seasonYear. Use the seasonId value with get_team_stats, get_player_stats, or get_game_results to retrieve data for a specific historical season.

ParametersJSON Schema

Name	Required	Description	Default
`refresh`	No	Set true to bypass cache and re-fetch from Hudl.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses caching behavior via the refresh parameter ('bypass cache and re-fetch from Hudl'). No destructive actions implied, and the read-only nature is evident. Good for a list operation.

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?

Two sentences with no filler: first states purpose and ordering, second explains output and usage with sibling tools. Every sentence is informative and earns its place.

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?

No output schema exists, but description fully explains return fields with an example label. Also covers cache behavior via refresh parameter and integrates with sibling tools. Complete for the tool's simplicity.

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

Parameters4/5

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

Schema coverage is 100% with one boolean parameter 'refresh' described. Description adds value by explaining output fields (seasonId, label, seasonYear) and their usage, going beyond the schema which only documents the 'refresh' param.

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?

Description states clear verb 'List', resource 'seasons', context 'for the team', and sorting 'newest first'. It also specifies return fields (seasonId, label, seasonYear), distinguishing it from sibling tools that consume seasonId.

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?

Explicitly advises using the returned seasonId with get_team_stats, get_player_stats, or get_game_results, guiding the agent on when to use this tool to obtain season identifiers. Missing explicit when-not-to-use statements, but the context is clear.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Jun 28, 2026
- First observedclear_cache
- First observedget_box_score
- First observedget_game_results
- First observedget_game_stats
- First observedget_player_stats
- First observedget_team_stats
- First observedlist_seasons

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-06-28 07:25 across 7 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: cache management, game-level stats, player stats, team stats, season listing, etc. No overlap that would cause confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (clear_cache, get_box_score, etc.), making them predictable and easy to understand.

Tool Count5/5

Seven tools is well-scoped for a sports statistics server—covers all essential retrieval operations without being excessive or insufficient.

Completeness4/5

Covers the main data retrieval needs: seasons, team/player stats, game results, and per-game player stats. Minor gap: no direct opponent details or filtering by date range, but core workflows are supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

cfbd-mcp-server
Sports Search
lenwood
A
license
B
quality
D
maintenance
An MCP server providing access to college football statistics sourced from the College Football Data API within Claude Desktop.
Updated a year ago (2025-05-06 19:23 UTC)
9
27
MIT
Discord MCP Server
Communication App Automation
userdeter1
F
license
Not graded
quality
C
maintenance
An MCP server that enables Claude Desktop to interact with Discord through a dedicated bot. It allows users to list channels, read message history, and send messages directly from the AI interface.
Updated 2 months ago (2026-06-28 21:35 UTC)
2
-
beast-baseball
Sports Web Scraping
mw-jeong
F
license
Not graded
quality
C
maintenance
MCP server for natural language analysis of baseball league data, enabling team statistics, standings, lineup suggestions, and scouting reports via Claude Desktop.
Updated 3 months ago (2026-06-10 08:51 UTC)
-
Odds API MCP Server
Sports Research & Data
axc9000
F
license
Not graded
quality
D
maintenance
An MCP server that connects Claude Desktop to The Odds API, giving Claude real-time access to sports odds, scores, and schedules across 80+ sports and leagues worldwide.
Updated 5 months ago (2026-04-03 19:44 UTC)
-