Zovo League Fixtures
Server Details
Make a round robin league schedule for 3 to 24 teams on real dates.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 1 tool
There is only one tool, so there is no possibility of selecting the wrong one. Its name and description precisely scope it to fixture/round-robin generation and explicitly state what it does not do (scores, standings, knockout brackets).
The single name generate_league_schedule follows a clear verb_noun snake_case convention. With one tool there are no conflicting conventions to break consistency.
A single tool is thin for a server, and this one is overloaded — it handles team parsing, formats, dates, blackouts, venues, time slots, and four export types at once. The scope is narrow enough that one tool is defensible, but a few companion tools (e.g. validate/regenerate, fetch a schedule) would be more usable.
For the stated purpose of generating league fixtures, coverage is strong: single/double round robin, odd-team byes, home/away balance, blackout dates, venues, time slots, and PDF/Excel/ICS exports. Gaps are acknowledged and out of scope (no score/standings tracking, no knockout brackets, no retrieval or editing of a previously generated schedule).
Available Tools
1 toolgenerate_league_scheduleGenerate league scheduleARead-onlyIdempotentInspect
Use this when the user wants a league schedule, round robin schedule, fixture list, season schedule or a home and away schedule for 3 to 24 teams ("make a schedule for my 8-team rec league", "round robin for 6 teams on Saturdays", "each team plays each other twice"). Put the team names into teams (convert a pasted list), plus start_date, play_days, format (single or double; use single when the user does not say), and optional blackout_dates, venues, time_slots or kickoff_time. When the user gives only a number of teams, call with placeholder names such as Team 1, Team 2. Each pair meets once (or twice, home and away); no team plays twice in a round; byes are even for an odd number of teams; home and away games are balanced. Returns the rounds on real dates, a printable PDF, an Excel workbook, an ICS with all games and one ICS per team. Refuses when the rounds do not fit before end_date or the venue slots are too few, and says what to change. Does not record scores or standings and does not make knockout brackets.
| Name | Required | Description | Default |
|---|---|---|---|
| teams | No | The teams, 3 to 24: ["Lions","Tigers","Bears","Wolves"] or objects with a home venue [{"name":"Lions","venue":"Riverside Park"}]. Names must be different. Convert a pasted list into this array. | |
| title | No | Optional league name printed on the schedule, e.g. "Spring U10 League". | |
| format | No | "single" (default): every pair plays once. "double": every pair plays twice, home and away (the second half repeats the pairings with home and away swapped). | |
| venues | No | Optional shared venues used by all teams, e.g. ["Field 1","Field 2"]. With time_slots, each round fills venue x time slots. Leave empty to use each team's home venue. | |
| end_date | No | Optional last allowed date, e.g. "2027-05-31". If the rounds do not fit, the tool says how many dates are missing and what to change. | |
| timezone | No | Optional IANA time zone for the calendar files, e.g. "America/Chicago". Without it, times are local clock times. | |
| page_size | No | "Letter" (default) or "A4". | |
| play_days | No | Weekday(s) with games, e.g. ["Saturday"] or ["Tuesday","Thursday"] (one round on each play date). Default: the weekday of start_date. | |
| date_order | No | Optional order for dates like 03/04/2027: "mdy" (US, default) or "dmy". | |
| start_date | No | Date of the first round, e.g. "2027-01-09". Required. | |
| teams_text | No | Fallback only: team names pasted as text, one per line or comma separated. Prefer teams. | |
| time_slots | No | Optional kickoff times on a play date, e.g. ["09:00","10:30","12:00"]. Slots rotate between rounds so no team always plays first. | |
| every_weeks | No | 1 (default) for every week, 2 for every other week, up to 4. | |
| game_minutes | No | Length of a game in the calendar files, 10 to 600 minutes. Default 90. | |
| kickoff_time | No | Optional single kickoff time for every game, e.g. "19:00" or "7pm". Ignored when time_slots is given. | |
| blackout_dates | No | Dates with no games (holidays, school breaks): ["2027-02-13", "2027-04-03 to 2027-04-10"] or [{"from":"2026-12-20","to":"2027-01-03","reason":"Winter break"}]. Rounds move to the next play date. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| title | Yes | |
| format | Yes | |
| rounds | Yes | |
| balance | Yes | |
| warnings | Yes | |
| downloads | Yes | |
| play_days | Yes | |
| last_round | Yes | |
| every_weeks | Yes | |
| first_round | Yes | |
| games_count | Yes | |
| teams_count | Yes | |
| rounds_count | Yes | |
| rounds_shown | No | |
| blackouts_skipped | Yes | |
| longest_home_or_away_run | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish a safe, read-only, idempotent operation, but the description adds substantial behavioral detail beyond them. It explains the round-robin mechanics, home/away balancing, bye handling for odd team counts, default assumptions, generated output formats, and the specific conditions under which the tool refuses and reports what to change.
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 long but front-loaded, starting with the primary use case before moving into parameters, behavior, outputs, and exclusions. The density is mostly justified by the tool's complexity, though the run-on examples and multiple parentheticals make it slightly less scannable than it could be.
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 a complex 16-parameter scheduling tool with an output schema and strong annotations, the description covers the essential context: supported inputs, defaults, scheduling guarantees, generated artifacts, refusal behavior, and explicit non-goals. Nothing material is missing for an agent to decide whether and how to call it.
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 100%, so every parameter already has its own description, and the description supplements this with useful synthesis: converting pasted team lists, using placeholder team names when only a count is given, defaulting format to single, and explaining how venues and time slots interact. It does not cover all 16 parameters individually, but it adds meaning beyond the schema for the most decision-relevant inputs.
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 states a precise verb and resource: generate a league schedule, with explicit coverage for round robin, fixtures, season, and home/away schedules for 3 to 24 teams. It also distinguishes what the tool does not do: no scores, standings, or knockout brackets.
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 concrete when-to-use triggers and quoted user phrasings such as "make a schedule for my 8-team rec league" and "round robin for 6 teams on Saturdays." It also states exclusion conditions, including knockout brackets and score/standings tracking.
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 tool update
- First observed
generate_league_schedule
Related MCP Connectors
Round-robin fixtures, standings and match-day plans for league organizers. Free.
Fair youth soccer lineups, rotations, formations, playing time, age groups and fixtures.
Make a printable weekly schedule from a list of classes, shifts or time blocks.
1Turn a written schedule into a live calendar link people subscribe to in Apple, Google, Outlook.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceGenerates a complete weekly duty-pair rotation calendar from the current week's pair, applying carry-over and fairness rules with no database or configuration needed.ISC
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to organize weekly football games by creating balanced teams and fixtures, managing squads and invites, setting games, tracking availability, entering results, and sharing vote links.1MIT
- AlicenseNot gradedqualityCmaintenanceGenerates printable scoreboard HTML files with configurable players, rounds, and titles, and writes them to a local output directory.82 npmMIT
- AlicenseAqualityCmaintenanceCalendar MCP server with atomic booking, conflict prevention, deterministic RRULE expansion, and TOON token compression for AI agents.1813MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.