Skip to main content
Glama

Pitch Time — Fair Youth Soccer Lineups

Find a youth soccer age group

age_group
Read-onlyIdempotent

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.

Input Schema

NameRequiredDescriptionDefault
dobYesDate of birth as YYYY-MM-DD.
bodyYesSlug (us-youth-soccer, ayso, the-fa, canada-soccer) or common name: US Youth Soccer, USYS, AYSO, The FA, FA, Canada Soccer. Case-insensitive.
seasonStartYearNoSeason start year, or year of play for Canada. Defaults to the current season for the body.

Output Schema

NameRequiredDescriptionDefault
ageYes
bodyYes
noteYes
labelYes
cutoffYes
seasonYes
pageUrlYes
bodyNameYes
rulesUrlYes
sourceUrlYes
formatNoteYes
formatAgeBandYes
retrievedDateYes
typicalFormatYes
seasonStartYearYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / body / description
      Added 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."
    • removedInput schema / properties / body / enum
      Removed value: -[
      -  "us-youth-soccer",
      -  "ayso",
      -  "the-fa",
      -  "canada-soccer"
      -]
  2. Added

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources