Skip to main content
Glama
chrischall

myersparkathleticzone-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List the school's teams

mpaz_list_teams
Read-onlyIdempotent

List athletic teams for a selected school year and retrieve the team IDs needed for schedules, rosters, and scores. Team IDs change each year, so use the current year's list for accurate results.

Instructions

List this school's athletic teams for a school year, with the team id needed by the schedule, roster and scores tools. Team ids differ per school year — an id from one season fails against another. A past year is answered from the sport pages when the schedule has nothing, which reaches only sports currently in season; the result carries a coverage note saying so, and an empty list there does NOT mean the school fielded no teams. Read-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
yearNoSchool year, e.g. "2026-2027". Defaults to the current one. Past seasons often work but coverage is partial — see the `coverage` note in the result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/openWorld/idempotent hints, it discloses that team ids are year-specific and fail across seasons, that past-year data may fall back to sport pages and only cover in-season sports, and that an empty result carries a coverage note and should not be read as 'no teams.' This is rich, non-obvious behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences each carry unique information: core action, downstream dependency, id-year scoping warning, and past-year/coverage caveats. Read-only is stated at the end; nothing is redundant or padded.

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?

Despite lacking an output schema, the description tells the agent the key facts needed to call and interpret results: teams are school- and year-scoped, ids feed other tools, past years may be partial, and a coverage note accompanies fallback results. This is complete for the tool's low complexity.

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?

The schema already describes the `year` parameter well (format, default, coverage caveat), so the baseline is 3. The tool description adds a meaningful semantic: year scoping determines the validity of team ids downstream, reinforcing why choosing the right year matters.

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 specific verb (list), resource (this school's athletic teams for a school year), and a key purpose (providing team ids used by schedule, roster, and scores tools). The description makes clear it is the team-listing entry point and does not get confused with the single-team or schedule/score siblings.

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?

Explains that the tool exists to feed team ids to schedule/roster/scores tools, which is clear guidance for when to call it. It also warns about year-scoped id validity and past-year coverage limits, but it does not explicitly name alternative tools for related lookups such as resolve_team.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools