Zovo League Fixtures

Generate league schedule

generate_league_schedule

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`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	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Zovo League Fixtures tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?