Fair youth soccer lineups, rotations, formations, playing time, age groups and fixtures.
Scored across 5 tools
Each tool targets a distinct part of the youth soccer workflow: age eligibility, playing-time math, lineup rotation, fixtures, and formations. The only mild overlap is between calculate_playing_time and generate_fair_lineup, since both can output minutes, but the descriptions clarify one is a pre-check and the other is a full generator.
Four of five tools use a clear verb_noun pattern: calculate_playing_time, generate_fair_lineup, generate_round_robin, and recommend_formation. The lone noun-phrase name, age_group, is a minor deviation but remains readable and predictable.
Five tools map cleanly to the core jobs in fair youth lineup planning, with no obvious filler or redundancy. The scope feels well matched to the server's purpose.
The set covers age eligibility, playing-time calculation, fair lineup generation, round-robin fixtures, and formation selection, which addresses the stated domain well. It lacks explicit roster/team storage or retrieval, but the deterministic generators and share links provide a workable surface.
Find the age group for a birth date, governing body and season from published official cutoff rules. Covers US Youth Soccer, AYSO, The FA and Canada Soccer from 2026. Returns the cutoff source and calculator link. USYS and AYSO use the revised August–July window from 2026–27.
| Name | Required | Description | Default |
|---|---|---|---|
| dob | Yes | Date of birth as YYYY-MM-DD. | |
| body | Yes | Slug (us-youth-soccer, ayso, the-fa, canada-soccer) or common name: US Youth Soccer, USYS, AYSO, The FA, FA, Canada Soccer. Case-insensitive. | |
| seasonStartYear | No | Season start year, or year of play for Canada. Defaults to the current season for the body. |
| Name | Required | Description |
|---|---|---|
| age | Yes | |
| body | Yes | |
| note | Yes | |
| label | Yes | |
| cutoff | Yes | |
| season | Yes | |
| pageUrl | Yes | |
| bodyName | Yes | |
| rulesUrl | Yes | |
| sourceUrl | Yes | |
| formatNote | Yes | |
| formatAgeBand | Yes | |
| retrievedDate | Yes | |
| typicalFormat | Yes | |
| seasonStartYear | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds the useful scope constraint ('from 2026') and notes the USYS/AYSO August–July window change, but says nothing about what happens for an unsupported body or a pre-coverage birth date.
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?
Three sentences, front-loaded with the core purpose and coverage, then return content and a rule note. Efficient overall, though the trailing USYS/AYSO August–July sentence is arguably domain trivia the tool itself would return and edges toward filler.
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 read-only lookup with a full schema and an output schema present, the description supplies everything needed to select and invoke it, including coverage limits. It never states error behavior for out-of-scope bodies or dates, which is the only real gap.
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 description coverage is 100%, so the schema already documents dob format, the body slug/name aliases, and the seasonStartYear default and range. The description only restates the parameter concepts and does not add format or edge-case detail beyond the schema.
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?
States a precise verb+resource (find the age group for a birth date, governing body and season) and names the source of truth (published official cutoff rules). It is trivially distinguishable from the siblings (lineup/formation/round-robin tools), which share no purpose.
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 bounds the applicable domain explicitly: four named bodies and coverage 'from 2026', which implicitly tells the agent when this tool is not applicable (other bodies, earlier seasons). It does not name an alternative or spell out the failure case for unsupported inputs, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate minutes and percentage per player, bench size, a simple segment length and whether equal shares meet a 50% minimum. This is an equal-share calculation, before any goalkeeper constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | ||
| rosterSize | Yes | ||
| gameMinutes | Yes |
| Name | Required | Description |
|---|---|---|
| percent | Yes | |
| benchSize | Yes | |
| calculatorUrl | Yes | |
| segmentLength | Yes | |
| minutesPerPlayer | Yes | |
| meets50PercentMinimum | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent/non-destructive, so the bar is low; the description still adds real substance by enumerating the computed outputs and defining the scope boundary (equal-share math, no goalkeeper adjustments). It doesn't mention error or edge-case behavior, but the boundary statement is meaningful added context.
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 tight sentences, front-loaded with the computed outputs and closed with the scoping caveat. No filler or repetition of the title.
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?
An output schema exists, so return values needn't be explained, and the annotations cover the safety profile. The gap is that with 0% parameter coverage, nothing in the description compensates for the undocumented format/rosterSize/gameMinutes inputs.
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 description coverage is 0%, so the schema gives only types, ranges, and one enum with no explanation. The description never mentions format (7v7/9v9/11v11), gameMinutes, or rosterSize, so the agent gets no help on what the format enum means or how roster size interacts with bench size.
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?
Specific verb (calculate) plus resource (playing time) and an explicit enumeration of outputs: minutes, percentage per player, bench size, segment length, and 50% minimum check. The closing clause hints it differs from generate_fair_lineup by excluding goalkeeper constraints, though it doesn't name that sibling directly.
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 phrase 'before any goalkeeper constraints' implies a sequencing relationship with lineup/constraint siblings, but there is no explicit statement of when to call this instead of generate_fair_lineup or recommend_formation. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a deterministic rotation with balanced minutes, goalkeeper duties and preferred positions. Returns each substitution window, player minutes and a shareable printable link. Duplicate names receive numbered suffixes. Without designated goalkeepers, everyone is available in goal.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | 7v7, 9v9 or 11v11; also accepts numbers 7, 9, 11 and strings "7", "9", "11". | |
| periods | No | 2 halves (default) or 4 quarters. | |
| players | Yes | ||
| formation | No | Full formation including GK, for example 1-2-3-1. Omit for the recommended formation. | |
| gameMinutes | No | Defaults: 7v7 50, 9v9 60, 11v11 70 minutes. | |
| goalkeepers | No | Roster names in keeper rotation order; combined with canPlayGK flags. | |
| rotateGoalkeeper | No | Designated keepers rotate at period breaks by default if more than one. Without designated keepers, defaults to keeping the current keeper until benched; true requests segment rotation, false fixes the first player in goal. | |
| segmentsPerPeriod | No | Equal substitution windows per period; default aims for about 8 minutes per segment. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| format | Yes | |
| minutes | Yes | |
| periods | Yes | |
| segments | Yes | |
| shareUrl | Yes | |
| formation | Yes | |
| gameMinutes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds real behavioral context beyond them: deterministic output, numbered suffixes for duplicate names, the printable-link artifact, and the goalkeeper fallback rule. It stops short of describing pagination or error conditions for invalid rosters (e.g., fewer than 7 players).
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?
Three tight sentences, front-loaded with the core action, then outputs, then edge-case rules. No filler and nothing repeated from the title or schema.
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, the description needn't explain return values, and it covers the key edge cases (duplicate names, missing keepers). For an 8-parameter tool with several conditional behaviors, it is nearly complete, though it says nothing about validation failures for out-of-range rosters or how preferred positions resolve conflicts.
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 88%, so the baseline is 3, and the description adds meaningful parameter-level behavior on top: duplicate names get numbered suffixes (players), and 'without designated goalkeepers, everyone is available in goal' clarifies how goalkeepers/canPlayGK interact. It does not explain periods, formation, gameMinutes or segmentsPerPeriod beyond what the schema already documents.
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?
States a specific verb and resource: 'Create a deterministic rotation with balanced minutes, goalkeeper duties and preferred positions,' and names the concrete outputs (substitution windows, player minutes, printable link). It is clearly a lineup generator rather than a time calculator or formation recommender, but it never names the closest sibling (calculate_playing_time) to draw the boundary explicitly.
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?
Usage is implied by the youth-soccer framing and the conditional clauses ('Without designated goalkeepers, everyone is available in goal'), which do tell the agent how the tool behaves under different roster setups. There is no explicit when-to-use-this-vs-sibling guidance, so an agent must infer that it wants this tool rather than calculate_playing_time or recommend_formation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create deterministic weekly fixtures for 3–24 teams with balanced home/away games and odd-team byes. Double round-robin reverses the round order and swaps home/away for the return leg. Returns fixtures, team counts, a Markdown table and a share link.
| Name | Required | Description | Default |
|---|---|---|---|
| teams | Yes | ||
| weekday | No | 0 Sunday through 6 Saturday, or an English weekday name or 3-letter abbreviation (case-insensitive), for example Saturday or sat. Requires startDate; first round is on or after that date. | |
| startDate | No | First possible match date, YYYY-MM-DD. | |
| doubleRoundRobin | No |
| Name | Required | Description |
|---|---|---|
| byes | Yes | |
| summary | Yes | |
| fixtures | Yes | |
| shareUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered; the description adds genuine non-annotation behavior — determinism, balanced home/away, byes for odd team counts, and the exact double round-robin transformation (reversed round order plus home/away swap on the return leg). It stops short of error/prerequisite behavior (e.g. uniqueness of team names, invalid weekday handling).
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?
Three dense sentences with the core purpose front-loaded, then the algorithm variant, then the outputs. No filler and nothing repeated needlessly.
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?
An output schema exists so return values need not be enumerated, and annotations carry the safety profile; the description nonetheless names the returned artifacts (fixtures, counts, Markdown table, share link), which is mildly redundant but harmless. Remaining gap is minor: no note on failure modes or input validation behavior.
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 50% (weekday and startDate are documented in-schema; teams and doubleRoundRobin are not), and the description only partially compensates by explaining the double round-robin effect and the 3–24 team bound. It adds no meaning for the teams array itself beyond the schema's maxLength/minItems constraints.
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?
States a specific verb (Create) and resource (deterministic weekly fixtures) with hard scope: 3–24 teams, balanced home/away, odd-team byes. The round-robin domain is clearly distinct from the siblings (formation, lineup, playing-time), so an agent can select this without ambiguity.
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?
Usage is implied by the stated scope and constraints, but there is no explicit when-to-use/when-not-to-use guidance and no routing to or away from siblings. It never says, for example, whether this is the right tool when you already have a fixture list or how it relates to generate_fair_lineup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Choose a formation for 7v7 (U8–U10), 9v9 (U11–U12) or 11v11 (U13+), with alternatives and coaching notes. Explicit format takes precedence over age; defaults to balanced 7v7.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | ||
| format | No | 7v7, 9v9 or 11v11; also accepts numbers 7, 9, 11 and strings "7", "9", "11". | |
| ageGroup | No | For example U9 or U12. |
| Name | Required | Description |
|---|---|---|
| format | Yes | |
| guideUrl | Yes | |
| ageGuidance | Yes | |
| recommended | Yes | |
| alternatives | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: what the result contains (alternatives plus coaching notes), the format-over-age precedence rule, and the balanced-7v7 fallback.
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 tightly packed sentences: the value proposition first, then the precedence/default rules. No filler, and the highest-value constraint (format precedence) 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?
An output schema exists, so return values need not be explained, and the description already characterizes them briefly. For a no-required-param, read-only computation tool, everything needed to call it correctly is present; only the semantics of the style enum are unstated.
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 67% and the description compensates well: it maps formats to age ranges, documents the default for both format and style ('balanced 7v7'), and supplies the cross-parameter precedence rule that the schema cannot express. The 'style' enum's meaning (attacking/defensive emphasis) is left implicit, which is the only real gap.
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?
States a specific verb (choose/recommend) and resource (formation), and pins down the exact decision space with the 7v7/9v9/11v11 age mapping. The resource is clearly distinct from siblings like generate_fair_lineup or calculate_playing_time, though it never names a sibling explicitly.
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?
Gives the applicable conditions (age/format bands), an explicit precedence rule ('explicit format takes precedence over age'), and the default behavior when nothing is supplied. It stops short of stating when NOT to use it versus the lineup/playing-time siblings, but the operating context is clear.
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.
age_group2 fields changedInput schema / properties / body / descriptionAdded value: +"Slug (us-youth-soccer, ayso, the-fa, canada-soccer) or common name: US Youth Soccer, USYS, AYSO, The FA, FA, Canada Soccer. Case-insensitive."Input schema / properties / body / enumRemoved value: -[
- "us-youth-soccer",
- "ayso",
- "the-fa",
- "canada-soccer"
-]generate_fair_lineup4 fields changedInput schema / properties / format / anyOfAdded value: +[
+ {
+ "enum": [
+ "7v7",
+ "9v9",
+ "11v11"
+ ],
+ "type": "string"
+ },
+ {
+ "const": 7,
+ "type": "number"
+ },
+ {
+ "const": 9,
+ "type": "number"
+ },
+ {
+ "const": 11,
+ "type": "number"
+ },
+ {
+ "enum": [
+ "7",
+ "9",
+ "11"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / format / descriptionAdded value: +"7v7, 9v9 or 11v11; also accepts numbers 7, 9, 11 and strings \"7\", \"9\", \"11\"."Input schema / properties / format / enumRemoved value: -[
- "7v7",
- "9v9",
- "11v11"
-]Input schema / properties / format / typeRemoved value: -"string"generate_round_robin5 fields changedInput schema / properties / weekday / anyOfAdded value: +[
+ {
+ "maximum": 6,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "string"
+ }
+]Input schema / properties / weekday / descriptionPrevious value: -"0 Sunday through 6 Saturday. Requires startDate; first round is on or after that date."New value: +"0 Sunday through 6 Saturday, or an English weekday name or 3-letter abbreviation (case-insensitive), for example Saturday or sat. Requires startDate; first round is on or after that date."Input schema / properties / weekday / maximumRemoved value: -6Input schema / properties / weekday / minimumRemoved value: -0Input schema / properties / weekday / typeRemoved value: -"integer"recommend_formation4 fields changedInput schema / properties / format / anyOfAdded value: +[
+ {
+ "enum": [
+ "7v7",
+ "9v9",
+ "11v11"
+ ],
+ "type": "string"
+ },
+ {
+ "const": 7,
+ "type": "number"
+ },
+ {
+ "const": 9,
+ "type": "number"
+ },
+ {
+ "const": 11,
+ "type": "number"
+ },
+ {
+ "enum": [
+ "7",
+ "9",
+ "11"
+ ],
+ "type": "string"
+ }
+]Input schema / properties / format / descriptionAdded value: +"7v7, 9v9 or 11v11; also accepts numbers 7, 9, 11 and strings \"7\", \"9\", \"11\"."Input schema / properties / format / enumRemoved value: -[
- "7v7",
- "9v9",
- "11v11"
-]Input schema / properties / format / typeRemoved value: -"string"generate_round_robinage_groupgenerate_fair_lineup1 field changedInput schema / properties / rotateGoalkeeper / descriptionPrevious value: -"Rotate at period breaks; defaults to true when more than one goalkeeper is designated."New value: +"Designated keepers rotate at period breaks by default if more than one. Without designated keepers, defaults to keeping the current keeper until benched; true requests segment rotation, false fixes the first player in goal."calculate_playing_timegenerate_fair_lineuprecommend_formationRound-robin fixtures, standings and match-day plans for league organizers. Free.
Organise a weekly football game: fair teams, fixtures, squads, who is in, and the vote link.
Every kid's team, league and school schedule in one family calendar.
Round-robin ladders and match scores for small clubs. Players join by QR poster; no app, no account.
Add one secure layer between your agents and this server.
