Skip to main content
Glama
alexmillsnl

Commish MCP

by alexmillsnl
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Commish MCP

An MCP (Model Context Protocol) server for fantasy sports league commissioners — giving AI assistants league-wide context and commissioner-oriented tools.

Commish MCP is not a thin wrapper around a single fantasy API. The domain is fantasy commissioner operations: league overviews, standings, matchup results, manager activity, transactions, recaps, and storylines. Provider-specific APIs (Yahoo first) sit underneath a provider abstraction.

Current state

🚧 Early development — initial scaffolding.

  • MCP server boots over stdio and registers one example tool (get_league_overview)

  • Provider-agnostic architecture with a Yahoo skeleton in place

  • No live fantasy data yet — the Yahoo OAuth2 client and API integration are not implemented

Related MCP server: Yahoo Fantasy MCP

Planned providers

Provider

Status

Yahoo Fantasy

First — skeleton in place, integration pending

Sleeper

Future

ESPN

Potential future

Planned capabilities

Commissioner-focused tools on the roadmap (none implemented yet):

  • Weekly recaps and league storylines

  • League health and manager activity

  • Lineup auditing

  • Transaction reports

  • Playoff context and standings deep-dives

Architecture

Yahoo API
   ↓
YahooProvider            (src/providers/yahoo)
   ↓
Normalized domain models (src/domain)
   ↓
Commissioner services    (src/services)
   ↓
MCP tools                (src/tools)
   ↓
AI client

Key principles:

  • Provider independence — tools operate on normalized domain models (src/domain), never raw provider payloads. Raw Yahoo types live in src/providers/yahoo/types.ts and must not leak upward.

  • Commissioner-first — services (src/services) combine provider data into league-level views; tool handlers stay thin.

  • Strong typing — provider payloads and domain objects are separate types; no any.

Getting started

Requires Node.js 22+ (.nvmrc provided).

npm install
npm run build
npm test
npm run typecheck

Scripts

Command

Purpose

npm run build

Compile src/ → dist/

npm run dev

Run with watch mode via tsx

npm start

Run the compiled server

npm test

Run unit tests (vitest)

npm run typecheck

Type-check src/ and tests/

npm run lint

ESLint

npm run format

Prettier

Adding to an MCP client

Example Claude Desktop configuration:

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

Configuration

Copy .env.example to .env (never committed) and fill in Yahoo credentials from an app registered at developer.yahoo.com/apps:

YAHOO_CLIENT_ID=
YAHOO_CLIENT_SECRET=
YAHOO_REDIRECT_URI=http://localhost:8787/callback

All variables are optional today: without them the server runs and tools explain what is missing. OAuth2 support (authorization-code flow, token refresh, secure local token storage) is the next milestone.

Project structure

src/
├── index.ts              # stdio entrypoint
├── server/server.ts      # server assembly + tool registration
├── tools/                # MCP tools (thin handlers)
│   ├── league/
│   └── types.ts          # ToolModule / ToolContext pattern
├── services/             # commissioner services (combine provider data)
├── providers/
│   ├── provider.ts       # FantasyProvider interface
│   └── yahoo/            # client, provider, raw payload types
├── domain/               # normalized league/team/matchup/transaction models
├── config/env.ts         # zod-validated environment
└── utils/
tests/                   # vitest unit + in-memory MCP integration tests

License

MIT

Available Tools

1 tool
get_league_overviewGet League OverviewA

Get a commissioner's overview of a fantasy league: league settings and current standings.

ParametersJSON Schema
NameRequiredDescriptionDefault
league_idYesProvider-specific league identifier, e.g. a Yahoo league key like '423.l.12345'.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. The verb 'Get' implies a read-only operation and the description states the returned content (league settings and current standings). It does not disclose authentication requirements, data freshness, or response shape, but for a simple overview tool this is a reasonable baseline.

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, front-loaded sentence with no filler or redundant phrasing. Every part adds value: the actor perspective, the resource, and the included data.

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?

For a low-complexity tool with one fully documented parameter and no output schema, the description is nearly complete. It states what the tool returns and the perspective involved. Minor gaps such as authentication expectations do not meaningfully impede correct invocation.

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%, and the league_id parameter is already well described with an example format. The description does not add parameter-level meaning, but none is needed since the schema fully documents the only parameter.

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 identifies the action ('Get') and resource ('commissioner's overview of a fantasy league') and lists the included content: league settings and current standings. It is specific and unambiguous, though there are no sibling tools to differentiate from, so it does not earn the top score.

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 when the tool is useful—when a commissioner needs league settings or standings—but it does not state explicit conditions, prerequisites, or alternatives. With no sibling tools, the lack of exclusion guidance is acceptable, yet still only implicit.

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.

  1. 1 tool updatev0.1.0
    • First observedget_league_overview
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool available, there is no potential for confusion between tools. The purpose of get_league_overview is clear and unambiguous.

Naming Consistency5/5

The single tool follows a clean verb_noun pattern, which is consistent with well-named MCP tools. There are no conflicting conventions.

Tool Count2/5

A single tool is far too few for a server whose name implies commissioner functionality. While the tool itself is useful, one tool cannot reasonably cover the expected scope.

Completeness1/5

The server only provides a read-only league overview. Critical commissioner actions such as roster management, trade processing, waiver claims, or settings updates are entirely missing, leaving the surface severely incomplete.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • flaim

    jdguggs10
    A
    license
    Not graded
    quality
    B
    maintenance
    Connect ESPN & Yahoo fantasy leagues to AI assistants via MCP. Read-only tools for rosters, standings, matchups, free agents, and league info across football and baseball.
    21
    MIT

  • Yahoo Fantasy MCP

    spilchen
    A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that provides read-only access to Yahoo Fantasy Sports data, enabling AI assistants to query league standings, player stats, matchups, and rosters.
    4
    MIT

  • Yahoo Fantasy MCP

    andy78644
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude to interact with Yahoo Fantasy Baseball and Basketball leagues, allowing roster analysis, matchup tracking, free agent browsing, and player stats retrieval via natural language.
    -

  • sleeper-mcp

    draffetseder
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables AI models to manage and query fantasy sports leagues through the Sleeper API, supporting tasks like player lookups, league activity, and draft management.
    70 npm
    MIT