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., "@jk-mcp-wsl What are the current WSL standings?"
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.
MCP server that gives Claude live access to Women's Super League (England) data — teams, matches, standings, rosters, and schedule-strength analytics — via the ESPN public API.
Related MCP server: jk-mcp-usls
AI assistants like Claude are knowledgeable, but they have a hard cutoff date — they cannot tell you today's Women's Super League standings, last night's scores, or which teams are currently on top. This project fixes that.
It is an MCP server — a plugin that gives Claude direct access to live Women's Super League data: scores, standings, rosters, and derived schedule-strength analytics. Once installed, you can ask Claude natural-language questions about the WSL and get accurate, up-to-date answers. No subscription, no API key, and no programming required to use it.
The Women's Super League is the top flight of English women's football. In 2024 it was spun out of The FA into its own independent operating company (WSL Football Ltd), running the WSL and WSL 2 as a fully professional 14-team pyramid. This server wraps the ESPN public JSON feed, which is the cleanest freely-accessible source for the league. Rich per-player and team-season stats — historically served via api-sdp.wslfootball.com — are deferred to v2 pending discovery of the correct stats/players category enum.
The v1 surface is eleven read-only, idempotent tools split across two tiers.
Tool | Description |
| List all 14 clubs with IDs and abbreviations |
| Details for a specific team |
| Team's active roster — jersey, position, age, citizenship |
| Match scores for a single day, a date range, or the current matchweek |
| Every match for a team in the current season — past + upcoming |
| One match's full details — score, venue, attendance, goals, cards, subs |
| Current standings — single 14-team table ordered by points |
| Recent Women's Super League news articles |
Pure functions over live standings + team schedules, exposing schedule-strength context the raw table does not.
Tool | Description |
| Team's average opponent points-per-game across matches already played |
| Team's W-L-T split across current top / middle / bottom standings tiers |
| Team's raw PPG alongside an opponent-quality-adjusted PPG |
Deferred to v2+:
Player leaderboards, team season stats, and per-player heatmaps via the league's own SDP tier (api-sdp.wslfootball.com/stats/players) — the category enum required to hit the endpoint has not been discovered from public traffic yet
FA Cup and Continental Cup fixtures
Playoff / relegation bracket rendering
Related competitions (UEFA Women's Champions League match-day fixtures for WSL clubs)
git clone https://github.com/jedi-knights/jk-mcp-wsl.git
cd jk-mcp-wsl
uv syncRun the server in stdio mode (the default — used by Claude Code and Claude Desktop):
uv run python -m wsl.serverRun in HTTP mode (for networked or deployed access):
MCP_TRANSPORT=streamable-http uv run python -m wsl.serverStandings, scores, rosters:
Who is leading the WSL right now?
Show me every WSL result from this past weekend.
Who is on Arsenal's roster?
When does Aston Villa play next?
Schedule strength:
Which WSL side has played the toughest schedule so far?
Show me Manchester United's record against the current top 3 clubs.
Compare Chelsea and Manchester City on adjusted points-per-game.
All configuration is via environment variables. None are required for local use.
Variable | Default | Description |
|
| Transport mode: |
|
| Bind address (HTTP transport only) |
|
| TCP port (HTTP transport only) |
|
| URL path (HTTP transport only) |
|
| ESPN API base URL |
|
|
|
| unset | Bootstrap the OpenTelemetry SDK |
| unset | Require RS256 bearer tokens on streamable-http |
| unset | Auth-server origin (required when auth is on) |
| unset | This server's public URL for the |
Install from your local clone globally so the server is available in every project:
claude mcp add --scope user wsl -- uv run --directory /path/to/jk-mcp-wsl python -m wsl.serverReplace /path/to/jk-mcp-wsl with the absolute path to your clone. Verify with claude mcp list.
Drop --scope user to register only for the current project, or commit a .mcp.json to the repo root for collaborators:
{
"mcpServers": {
"wsl": {
"command": "uv",
"args": ["run", "--directory", "/path/to/jk-mcp-wsl", "python", "-m", "wsl.server"]
}
}
}Add the following to your Claude Desktop configuration file.
Location:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"wsl": {
"command": "uv",
"args": [
"run",
"--directory", "/path/to/jk-mcp-wsl",
"python", "-m", "wsl.server"
]
}
}
}If uv is not on Claude Desktop's PATH, use the absolute path (which uv will show it). Fully quit and relaunch Claude Desktop after saving — a window close is not enough.
Build the image:
docker build -t jk-mcp-wsl:latest .Run in stdio mode (for MCP clients that spawn a subprocess):
docker run -i --rm jk-mcp-wsl:latestRun in HTTP mode:
docker run --rm -p 8000:8000 \
-e MCP_TRANSPORT=streamable-http \
jk-mcp-wsl:latestuv syncAll common workflows are invoke tasks. Run uv run inv --list to see everything.
Task | Alias | Description |
|
| Run ruff linter and format check |
|
| Auto-fix lint violations and reformat |
|
| Run the full test suite |
|
| Run tests with coverage report (threshold: 90%) |
|
| Check cyclomatic complexity (max 7) |
|
| Build wheel and sdist into |
|
| Build the Docker image |
|
| Remove build and coverage artifacts |
src/wsl/
├── server.py # entry point, transport selection, logging setup
├── adapters/
│ ├── inbound/
│ │ ├── mcp_adapter.py # FastMCP server, health endpoints, tool registration
│ │ ├── formatters.py # domain → LLM-readable text
│ │ ├── authorization.py # inbound authz port implementations
│ │ └── tools/
│ │ ├── espn.py # 8 ESPN-backed tools
│ │ └── analytics.py # 3 schedule-strength analytics tools
│ └── outbound/
│ ├── espn_adapter.py # ESPN HTTP client
│ ├── parsers.py # ESPN JSON → domain models
│ ├── retry_adapter.py # transient-failure retry decorator
│ └── caching_adapter.py # in-process TTL cache
├── application/
│ ├── service.py # WSLService — use cases, orchestration
│ ├── _helpers.py # input validation
│ └── _analytics_helpers.py # pure math for schedule-strength tools
├── domain/
│ ├── models.py # Team, Match, Standing, etc.
│ └── exceptions.py # WSLNotFoundError, UpstreamAPIError
├── ports/
│ ├── inbound.py # Authorizer protocol
│ └── outbound.py # WSLAPIPort protocol
├── observability/ # OpenTelemetry bootstrap (opt-in)
└── security/ # JWKS token verifierThe dependency direction flows inward: adapters → ports → domain. Nothing in domain/ imports from adapters or a framework.
Fork the repository and clone your fork
Create a feature branch: git checkout -b feature/your-feature
Make your changes following the existing patterns (hexagonal architecture, TDD, conventional commits)
Verify the full check suite passes: uv run inv lint && uv run inv check-complexity && uv run inv coverage
Open a pull request against main
All CI checks (lint, complexity, tests, coverage ≥ 90%) must pass before merge.
MIT — see LICENSE.
Get a team's raw points-per-game alongside an opponent-quality-adjusted PPG.
Adjusted PPG scales raw PPG by avg_opponent_ppg / league_average_ppg,
so values above raw PPG indicate the team has earned points against a
tougher schedule than league average.
Args: team_id: ESPN numeric team ID.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=True, destructive=False, and idempotent=True, so the safety profile is clear. The description adds behavioral context by explaining the adjustment formula (avg_opponent_ppg / league_average_ppg) and how to interpret values relative to raw PPG. This goes beyond what annotations provide and helps the agent reason about the computation.
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 front-loaded with the main purpose, followed by a compact formula explanation and an arguments line. Every sentence adds value, and the structure is clean. The 'Args' block is redundant with the schema but serves as a useful inline reminder given that the schema lacks descriptions.
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 explains what the tool returns (raw and adjusted PPG) and the reasoning behind the adjustment. With an output schema present, return values do not need to be spelled out. It does not cover error conditions or rate limits, but for a simple read-only tool this is adequate. The description is complete enough for an agent to invoke it correctly.
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 only defines team_id as a string with no description (0% coverage). The description compensates by stating 'team_id: ESPN numeric team ID', which clarifies the expected format and meaning. This is sufficient for the single parameter, though it could also mention that the team must exist in ESPN systems.
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+resource ('Get a team's raw points-per-game alongside an opponent-quality-adjusted PPG') and clearly distinguishes this from sibling tools like get_standings or get_strength_of_schedule. It names the exact metric and includes a concise definition.
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 primary use case: retrieving a team's PPG with an adjustment for opponent quality. It does not explicitly discuss exclusions or alternatives, but the formula explanation gives context for when this metric is relevant. A clear alternative comparison is missing, so it does not fully reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information for a single Women's Super League match.
Returns the score, venue, attendance, and a chronological list of key events (goals, substitutions, cards). Use the match ID returned by get_scoreboard or get_team_schedule.
Args: match_id: ESPN numeric event ID (e.g. "401853883").
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds the return payload details (score, venue, attendance, events) and the expected match_id format, offering useful behavioral context without contradicting annotations.
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 plus an Args block, front-loaded with the purpose, no redundant explanations.
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 read-only lookup, the description covers purpose, parameter source/format, and return content. With output schema present and rich annotations, nothing essential is missing.
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 only says 'Match Id' string. The description specifies it as an 'ESPN numeric event ID' with example '401853883' and explains where to obtain it, fully compensating for the 0% schema description coverage.
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 it 'Get detailed information for a single Women's Super League match' and enumerates return content, distinguishing it from list-oriented siblings like get_scoreboard and get_team_schedule.
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?
It explicitly instructs to 'Use the match ID returned by get_scoreboard or get_team_schedule,' providing context for when this tool is appropriate. It lacks an explicit 'when-not' exclusion, but the purpose and source references imply the alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent Women's Super League news articles.
Returns each article's headline, publication date, summary, and link to the full ESPN story.
Args: limit: Maximum number of articles to return (default 10).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds useful context by specifying the return content (headline, publication date, summary, link to ESPN story) and the 'recent' temporal scope, which are not evident from annotations alone.
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 and front-loaded: one sentence states purpose, one sentence lists return fields, and one line documents the arg. There is no fluff or redundancy.
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 read-only tool with a single optional parameter, rich annotations, and an output schema, the description fully covers purpose, return value shape, and parameter semantics. No critical information is missing.
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 by explaining the single parameter: 'Maximum number of articles to return (default 10).' It adds semantic meaning beyond the schema's type/default by clarifying that limit controls the maximum article count.
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 starts with a specific verb and resource: 'Get recent Women's Super League news articles.' It clearly identifies the tool's scope (WSL news) and differentiates it from sibling tools like get_standings and get_teams by focusing on news articles.
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 (call this when you need recent WSL news) but does not explicitly state when to prefer it over alternatives or when not to use it. There is no exclusionary guidance, but the purpose is clear enough to infer the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a team's W-L-T splits against current top-tier, middle, and bottom-tier teams.
Tiers are derived from the live league standings: top tier_size,
bottom tier_size, and everyone in between. Lets you ask "how does
this team do against the top of the table?" without scanning every
result manually.
Args: team_id: ESPN numeric team ID. tier_size: Number of teams in each of the top and bottom tiers. Defaults to 5. Must be at least 1, and 2*tier_size must not exceed the league size.
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes | ||
| tier_size | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral detail: tiers are derived from live league standings, and tier_size has constraints (minimum 1, 2*tier_size <= league size). This goes beyond the annotations and helps the agent understand how the tool behaves at runtime.
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 and well-structured. The first sentence states the purpose, followed by a brief explanation of tier derivation, a use-case rationale, and an Args section. Every sentence contributes unique information; there is no redundancy or verbosity.
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 only 2 parameters, an output schema, and clear annotations, the description fully covers the tool's behavior. It explains the tier logic, constraints, and provides a comparison to manual scanning, which together give an agent complete context for selection and 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 must fully explain parameters. It does: team_id is identified as an ESPN numeric team ID, and tier_size is explained with its default value and validation constraints. This adds rich meaning beyond the bare schema property 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 opens with a specific verb and resource: 'Get a team's W-L-T splits against current top-tier, middle, and bottom-tier teams.' This clearly states what the tool does and uniquely distinguishes it from sibling tools like get_standings or get_team_schedule by focusing on opponent-tier splits. The purpose is precise and not tautological.
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 a clear contextual use case: 'Lets you ask "how does this team do against the top of the table?" without scanning every result manually.' This implies when to use the tool, but it does not explicitly name alternative tools or state when not to use it. Because it gives meaningful usage context without exclusions, it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the active roster for an Women's Super League team.
Returns each player's jersey number, name, position, citizenship, and age. Use the team ID returned by get_teams.
Args: team_id: ESPN numeric team ID (e.g. "18418" for Atlanta United FC).
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns active roster data and the specific player attributes, but does not discuss behavior like pagination or rate limits. This is adequate but not rich.
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 compact: three sentences plus an Args section. It front-loads the purpose, then lists return fields and prerequisite info, with no redundant or filler content. Every sentence contributes meaning.
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 read-only tool with one parameter and an output schema, the description covers the essential context: what the tool does, return fields, how to obtain the required team_id, and an example. Nothing critical is missing.
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 has no description for team_id (0% coverage), but the tool description fully compensates by explaining team_id is an ESPN numeric team ID and providing a concrete example ('18418' for Atlanta United FC). It also cross-references get_teams as the source. This completely clarifies the parameter.
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 gets the active roster for a Women's Super League team, and lists the returned fields (jersey number, name, position, citizenship, age). This verb+resource+scope combination distinguishes it from sibling tools like get_teams (list teams) or get_team (single team details).
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 clear usage context by instructing to use the team ID returned by get_teams, and includes an example team ID. It does not explicitly exclude alternative tools, but for a roster lookup this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Women's Super League match scores and status for a date or date range.
With no arguments, returns matches for the current matchweek. With
date only, returns matches for that single day. With both date
and end_date, returns every match in the inclusive range.
Args:
date: Optional start date in YYYYMMDD format (e.g. "20260418").
end_date: Optional end date in YYYYMMDD format. Requires date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| end_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description's additional details about defaulting to the current matchweek and the end_date dependency provide useful behavioral context. It does not contradict annotations.
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 and well-structured: a summary line, then a clear conditional breakdown, then an args section with precise details. Every sentence adds necessary information without redundancy.
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 an output schema present, return-value specifics are not needed. The description covers all argument combinations, date formats, and dependencies, making the tool fully comprehensible for an agent.
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?
Despite 0% schema coverage, the description fully documents both parameters, including the YYYYMMDD format, optionality, and the requirement that end_date needs date. This compensates completely for the schema's lack of descriptions.
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 ('Get') and clearly identifies the resource ('Women's Super League match scores and status') and the scope (date or date range). This distinguishes it from siblings like get_match_details and get_team_schedule.
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?
It clearly explains when to call the tool with no arguments, with only date, and with both date and end_date, including the inclusive-range behavior. It does not explicitly mention alternatives, but the usage contexts are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Women's Super League standings.
Returns the 14-team table ordered by points descending, with win/loss/tie record, goals for, goals against, and goal differential.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, open-world, idempotent, and non-destructive. The description adds valuable specifics: a 14-team table ordered by points descending, with win/loss/tie record, goals for/against, and goal differential. This exceeds the annotation baseline.
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. The first states the action, the second details the output structure. No wasted words or redundant 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?
Given the tool's simplicity (zero params), existing output schema, and annotations covering safety, the description covers all key aspects: league, table size, ordering, and statistics. Nothing significant is missing.
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 schema coverage is complete. The description appropriately says nothing about parameters. Baseline for zero-param tools is 4.
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 retrieves the current Women's Super League standings with a specific resource and verb. It distinguishes itself from siblings like get_scoreboard (scores) and get_team_schedule (fixtures) by focusing on the league table.
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 clear context (use for standings) but does not explicitly mention exclusions or alternatives. For a zero-parameter read-only tool, the purpose is self-evident, and the lack of explicit alternative guidance is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a team's strength of schedule based on opponents already faced.
Returns the average current points-per-game of every opponent the team has played in completed matches, plus a per-opponent breakdown. Useful early in the season for "who has played the tougher schedule so far?" questions.
Args: team_id: ESPN numeric team ID (e.g. "18418" for Atlanta United FC).
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by specifying it computes average points-per-game of opponents in completed matches and returns a per-opponent breakdown, going beyond what annotations provide.
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 and front-loaded with the core purpose, followed by return details and a use case. It avoids fluff and includes only valuable information, with the Args section providing a clear parameter explanation.
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, read-only tool with a full output schema and rich annotations, the description is complete. It covers purpose, scope, parameter format, and suggests when to use it, leaving no significant gaps.
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%, but the description fully compensates by explaining team_id as an 'ESPN numeric team ID' with a concrete example ('18418' for Atlanta United FC). This gives the agent all necessary context to supply the parameter correctly.
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 a specific verb and resource: 'Get a team's strength of schedule based on opponents already faced.' It further defines the output as average points-per-game plus a per-opponent breakdown, distinguishing it from sibling tools like get_standings or get_team_schedule.
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 usage context: 'Useful early in the season for "who has played the tougher schedule so far?" questions.' It does not mention exclusions or alternatives explicitly, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific Women's Super League team.
Returns full team information including display name, abbreviation, and location. Use the numeric ID returned by get_teams.
Args: team_id: ESPN numeric team ID (e.g. "18418" for Atlanta United FC).
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds useful behavioral context by stating what information is returned ('display name, abbreviation, and location') and clarifying the ID source, without contradicting annotations.
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 and well-structured: a purpose sentence, a return-content sentence, and an Args section. Every sentence earns its place, with no redundant 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?
With a single parameter, an output schema present, and comprehensive annotations, the description provides all necessary context for correct selection and invocation. The tool is simple, and the description covers purpose, parameter, and return expectations.
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 has 0% description coverage for team_id, but the description fully compensates by explaining 'ESPN numeric team ID' and providing an example ('18418' for Atlanta United FC). This clearly conveys both meaning and format.
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 'Get details for a specific Women's Super League team' with a specific verb and resource. It distinguishes from the sibling get_teams by emphasizing 'specific', implying get_teams is for lists.
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?
Provides explicit context: 'Use the numeric ID returned by get_teams' establishes a prerequisite and ties it to the sibling tool. However, it does not explicitly state when not to use other alternatives, though this is implied by 'specific'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all active Women's Super League teams.
Returns a numbered list of teams with their ID, full name, abbreviation, and home city. Use the ID or abbreviation with get_team to retrieve detailed information about a specific team.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by disclosing that only active teams are returned and that the output is a numbered list with specific fields, which goes beyond the annotation-only information.
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 three short sentences. The first states the action, the second the return format, the third provides a usage pointer. No filler or repetition, and the key information is 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?
For a zero-parameter list endpoint, this description is complete. It covers what is returned (ID, name, abbreviation, home city), notes the 'active' filter, and directs traffic to get_team for follow-up. With full annotations and an output schema present, no additional behavioral details are necessary.
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 takes no parameters, so the description rightly omits parameter details. The baseline of 4 for zero-parameter tools applies, and the description correctly focuses on output and usage.
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: 'Get all active Women's Super League teams.' It specifies the resource (teams), scope (all active, WSL), and distinguishes itself from the sibling get_team by positioning this as the list-all tool and directing users to use get_team for details.
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?
It gives explicit guidance to use the returned ID or abbreviation with get_team for detailed info, providing a clear alternative. It doesn't discuss exclusions for other sibling tools, but for a simple list-fetching tool this context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all matches for a single Women's Super League team in the current season.
Returns scheduled, in-progress, and completed matches for the team — with opponent, date, score (if played), and status.
Args: team_id: ESPN numeric team ID (e.g. "18418" for Atlanta United FC).
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return details including scheduled, in-progress, and completed matches with opponent, date, score, and status. Since annotations already mark it as read-only and idempotent, this adds useful behavioral context beyond the structured metadata. However, it does not mention pagination or potential errors, which is acceptable for a simple 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?
The description is brief and well-organized: purpose, return summary, and parameter explanation. Every sentence contributes necessary information with no redundancy.
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 (one parameter, output schema exists), and the description covers its purpose, return content, and parameter format. The questionable example team ID is a minor completeness gap, but overall it is adequate for agent 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 schema description coverage at 0%, the description compensates by explaining team_id as an ESPN numeric ID with an example. The example '18418' is attributed to Atlanta United FC, which is inconsistent with the Women's Super League context, slightly undermining clarity. Still, it clearly communicates the expected format.
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 'Get all matches for a single Women's Super League team in the current season,' which specifies a distinct action and resource. This distinguishes it from siblings like get_scoreboard (all teams) and get_match_details (single match).
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 for retrieving a team's schedule but does not explicitly state when to use it over alternatives. It lacks any mention of sibling tools or cases where another tool would be more appropriate, so it provides only indirect guidance.
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.0get_adjusted_points_per_gameget_match_detailsget_newsget_results_by_opponent_tierget_rosterget_scoreboardget_standingsget_strength_of_scheduleget_teamget_team_scheduleget_teamsScored across 11 tools
Each tool targets a distinct resource (standings, teams, team details, scoreboard, roster, match details, schedule, news, advanced stats) with clear boundaries. Even the analytical tools (strength of schedule, tier splits, adjusted PPG) are distinct in purpose.
All tools follow the same get_noun or get_phrase pattern using snake_case. The names clearly describe the return type (standings, teams, scoreboard) and are uniformly prefixed with 'get_'.
11 tools is well-scoped for a sports data server covering league tables, teams, matches, rosters, news, and derived analytics. Each tool serves a unique purpose without bloat.
The surface covers the main data consumers expect: standings, teams, rosters, matches, schedules, news, and advanced statistics. Minor gaps exist (e.g., no player-specific stats, no historical season data), but these are not critical for the apparent purpose.
Hosted MCP server for live public-data APIs and Skills for AI agents.
ESPN MCP — keyless multi-sport live scores, teams, and news via ESPN's public site API.
Sports MCP — wraps TheSportsDB API (free tier, test key 3, no auth required)
API-Football MCP — comprehensive soccer/football data