myersparkathleticzone-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource or operation, with clear delineation between all-teams upcoming schedule and single-team full season. The resolve_team helper prevents id guessing ambiguity, and content types (teams, scores, roster, news, videos, photos) are cleanly separated.
Naming Consistency5/5
All tools share a consistent `mpaz_` prefix and follow a verb_noun pattern (list_*, get_*, resolve_*, healthcheck). Naming clearly indicates whether an operation lists a collection or fetches a specific entity, with no style mixing.
Tool Count5/5
Ten tools provide comprehensive but focused coverage of an athletics site's read-only resources. Each tool addresses a distinct need, from team discovery to schedules, scores, roster, news, media, and health verification.
Completeness5/5
The surface covers core team information (roster, schedule, scores), content (news, videos, photos), and discovery (list/resolve teams), with a healthcheck for operational reliability. No significant gaps for the stated purpose; edge cases like missing player data and partial scores are explicitly handled.
Average 4.4/5 across 10 of 10 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond the annotations by disclosing that images are on a public CDN and require no authentication. This is helpful for understanding the tool's behavior. The 'Read-only' statement is redundant with the readOnlyHint annotation but does not contradict it.
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 concise and front-loaded with the core subject. However, the final sentence 'Read-only' repeats information already provided by the readOnlyHint annotation, adding slight redundancy. Overall it is appropriately sized.
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 simple read-only list tool with no parameters and no output schema, the description covers the essential context: what is being returned and that images are directly fetchable. It does not detail return structure or pagination, but given the simplicity, this is acceptable.
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 tool has zero parameters, so the baseline is 4. The description doesn't need to explain parameters, and the schema coverage is trivially 100%. No additional parameter semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('photo galleries published on the site') and distinguishes it from sibling tools like mpaz_list_news and mpaz_list_videos. The verb 'list' is not explicitly stated in the description but is present in the tool name/title, making the purpose clear but slightly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that images are on a public CDN and can be fetched without auth, which is useful for how to handle results, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the description need not repeat safety. It adds useful context: results are ordered oldest first, and past seasons often work with the caveat to check the year's team id and coverage note via mpaz_list_teams. This goes beyond annotation values.
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?
The description is two tight sentences, front-loaded with the core function, then the prerequisite, then the read-only note. Every word earns its place with no redundancy.
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 low-complexity read tool with rich annotations and full parameter descriptions, the description adequately covers purpose, ordering, and prerequisites. It doesn't detail the response fields, but no output schema is present and the tool name implies a schedule; minor gap only.
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 fully documents all three parameters. The description adds little beyond what the schema already says, though it emphasizes that both sportSlug and teamId are required, which is already in the schema. Baseline 3 is appropriate.
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 clearly states the tool returns a single team's complete season in chronological order, using a specific verb (get) and resource (team schedule) with scope (single team). It distinguishes itself from sibling tools like mpaz_get_schedule by emphasizing 'single team' and requiring both sport slug and team id.
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?
It explicitly instructs to resolve sport slug and team id with mpaz_list_teams or mpaz_resolve_team first, giving clear prerequisite usage. It doesn't explicitly name an alternative for multi-team schedules, but the 'single team' framing implies differentiation from mpaz_get_schedule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals a critical behavioral nuance: most teams publish coaches but not players, so an empty list is normal, not an error. It also warns that team ids differ per school year and advises checking 'coverage' notes. These details prevent misinterpretation of results.
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?
The description is three sentences, front-loaded with the main purpose, then adds the key edge case and a read-only note. Every sentence earns its place; no redundancy or fluff.
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?
The description, combined with a rich input schema and annotations, fully covers the tool's behavior for a roster-fetch operation. It addresses the most likely confusing scenario (empty players list) and provides the necessary prerequisite steps. With no output schema, the return value is not required to be detailed.
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 descriptions cover 100% of parameters, so the baseline is 3. The description does not add parameter-specific detail beyond what the schema already provides, but it reinforces the requirement of sportSlug and teamId.
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 clearly states the tool's purpose: returning coaching staff and players for a single team. The title and description align on the specific resource, and the scope ('for one team') distinguishes it from list-style siblings like mpaz_list_teams.
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 states required inputs ('Requires the sport slug and team id') and guides the agent to use mpaz_list_teams first to resolve the correct team id for a given year. It also clarifies that an empty players list is expected, setting proper expectations. It lacks an explicit 'when not to use' statement but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds meaningful context beyond these: it returns a window of ~10 upcoming events, ordered oldest first, and is not a complete season. This is valuable behavioral information not present in annotations.
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?
Two sentences: the first states the core function, the second adds the critical window caveat and alternative. No filler, information is front-loaded, and every sentence earns its place.
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?
The description is adequate for this simple list tool: it explains the window limitation, ordering, and directs to the alternative for full season. It does not describe the return event structure or pagination, but given there is no output schema and the tool is straightforward, this is a minor gap. The year parameter is fully documented in the schema.
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?
The input schema covers 100% of the single parameter (year) with a rich description including examples, default behavior, and past season handling. The tool description does not add parameter details, but the schema already provides full semantics, so baseline 3 is appropriate.
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 clearly states the tool returns 'Upcoming events across every team, oldest first', which specifies the verb (get), the resource (all-school schedule/events), and the scope (every team). It distinguishes from the sibling tool mpaz_get_team_schedule by explicitly noting this covers all teams, not a single team.
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?
The description provides explicit guidance: it is for upcoming events across all teams, and it directly names the alternative tool mpaz_get_team_schedule for a team's full season. It also warns that this returns only a window, not the whole season, which helps the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds value by specifying the exact verification (parseable RSC payload) and what it reports (configured site and school id). The 'Read-only' line is redundant with the annotation but not contradictory.
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?
The description is three short sentences with the main action front-loaded in the first sentence. There is no fluff or redundant detail beyond the necessary clarification of the RSC payload and the reported fields.
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 zero-parameter, read-only health check, the description covers the core function and the output (site and school id). It could explicitly mention failure behavior or return format, but given the tool's simplicity and good annotations, it is adequately complete.
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 input schema has zero parameters, so the baseline is 4. The description explains what the tool does and what it reports, which compensates for the lack of parameters and adds functional context.
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 uses the specific verb 'Verify' and clearly identifies the resource ('athletics site') and the acceptance condition ('still serving a parseable RSC payload'). This distinguishes it from sibling tools that fetch specific data types like schedules or rosters.
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 purpose of checking reachability is clear and implies when to use it, but the description does not explicitly contrast it with alternative tools or state when not to use it. For a simple health check, the context is still unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the 'Read-only' phrase adds no new safety info. However, the description adds useful behavioral context: the source (homepage) and ordering (newest first), which are not implied by annotations or schema. No contradiction with annotations.
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?
The description is two short sentences that convey source, ordering, and read-only nature. It is front-loaded and every word earns its place. No redundancy or 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?
Given the tool's simplicity (no parameters, no output schema), the description provides sufficient context: it names the resource, source, ordering, and safety profile. It does not detail the structure of individual news items, but for a list operation this is acceptable. Sibling tools are similarly concise.
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?
There are no parameters, so the schema is fully covered (100%). Baseline for zero params is 4. The description does not add parameter-level details because none exist; it appropriately focuses on behavior instead.
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 clearly states the tool lists recent news posts from the athletics site homepage, with a specific verb ('list') and resource ('news posts'). It distinguishes itself from sibling tools like list_videos and list_photo_galleries by content type and source.
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 implies usage context: it is for retrieving recent news from the homepage, newest first. It does not explicitly name alternatives, but the context is clear enough given sibling tools exist for different content types. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the ambiguity behavior: 'Returns every candidate when the query is ambiguous.' This adds value beyond the readOnlyHint and idempotentHint annotations by explaining the non-deterministic output shape. The 'Read-only' statement aligns with the annotation rather than contradicting it.
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?
Three sentences, each earning its place: purpose with examples, usage guidance with explicit sibling tools, and a brief note on ambiguous results. The purpose is front-loaded and there is zero fluff or redundancy.
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?
Given the tool's simplicity, two parameters, and rich annotations, the description covers purpose, usage, and the key behavioral nuance of ambiguity. It does not describe the exact return structure for candidates, but for a resolution tool this is not a significant gap, and the description is fully adequate for an agent to select and invoke it.
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 coverage is 100%, with both provided parameters already described in the input schema. The description enriches the query parameter with extra examples ('varsity football', 'girls JV volleyball'), but does not add substantially new semantics beyond what the schema already covers, so the baseline of 3 is appropriate.
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 opens with a specific verb-resource pairing: 'Find a team id from a loose name', with concrete examples that immediately clarify what the tool does. It also distinguishes itself from sibling tools like mpaz_list_teams by focusing on name-ambiguous resolution rather than listing all teams.
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?
Explicitly states when to use: 'Use this before mpaz_get_team_schedule / mpaz_get_roster / mpaz_get_scores rather than guessing an id.' This names the alternative tools and the proper workflow, giving clear context and avoiding guesswork.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint), the description explains critical null-score behavior: half-entered games yield null scores and 'a missing score is unknown, never zero.' This adds valuable behavioral context about data storage upstream and null handling.
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?
The description is three sentences with no fluff. It front-loads the purpose, then adds necessary behavioral nuance, and ends with a directive to an alternative. Every sentence earns its place.
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 the simple read-only nature, 3 parameters, and thorough schema annotations, the description covers all essential aspects: return fields, null semantics, and alternative usage. No output schema exists, but the description includes key output field names, making it complete for an agent to select and invoke correctly.
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 each parameter is already well-documented. The tool description itself does not add extra parameter semantics, staying at the baseline for high schema coverage.
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 clearly states the tool returns completed games with results for a single team, using specific output field names. It distinguishes itself from the sibling tool mpaz_get_team_schedule, which covers upcoming fixtures.
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?
Explicit guidance is provided: 'Prefer mpaz_get_team_schedule for upcoming fixtures' clearly tells when not to use this tool. The description also references mpaz_list_teams for resolving team IDs for past seasons, giving practical usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations that state read-only/idempotent, the description adds key behavioral quirks: videoLengthSeconds is always 0 and title is the team name, explicitly saying this is expected not missing data. It also clarifies the link type (NFHS Network vs hosted clips), which is valuable context.
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?
The description is only two sentences, front-loaded with the core purpose. Every sentence adds value—the first states what it lists, the second details expected data quirks. No filler or redundancy.
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?
For a simple list tool with no parameters and no output schema, the description covers the purpose, the nature of the results, and the safety (read-only). It even mentions output fields like videoLengthSeconds and title, which provides enough context for an agent to interpret results correctly.
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 tool has zero parameters, so there is nothing for the description to explain beyond the schema. The baseline for no-parameter tools is 4, and the description doesn't attempt to invent parameter guidance, which is appropriate.
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 clearly states 'Games with a broadcast link' and specifies it lists NFHS Network links, distinguishing it from sibling tools like mpaz_list_teams or mpaz_get_scores. The title 'List game broadcast links' aligns precisely with the verb+resource structure.
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 provides clear context for when to use the tool—when looking for broadcast links—and notes the type of content (NFHS Network links). However, it doesn't explicitly enumerate alternatives or exclusion cases, though sibling names make the contrast implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint and openWorldHint, but the description adds substantial behavioral nuance beyond those: the coverage note, the fallback to sport pages for past years, and the meaning of an empty list. This is genuinely useful context.
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?
Every sentence earns its place: the main purpose is front-loaded, followed by critical caveats about year-specific IDs and partial coverage. It is compact yet information-dense without being verbose.
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?
For a simple one-parameter tool with no output schema, the description covers purpose, usage, edge cases, output semantics, and relationship to sibling tools. It is fully sufficient for an agent to select and invoke it correctly.
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 itself already fully describes the `year` parameter (default, past behavior). The description adds further clarification about the coverage note and empty-list semantics, so it adds some value beyond the schema but is not the primary source of parameter meaning.
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 opens with a specific verb+resource ('List this school's athletic teams for a school year') and explicitly states the output's purpose ('team id needed by the schedule, roster and scores tools'), distinguishing it from sibling tools like mpaz_get_schedule or mpaz_resolve_team.
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 clearly states when to use the tool (to obtain team IDs for other tools) and provides important caveats: team IDs differ per year, past-year coverage is partial, and an empty list should not be interpreted as absence of teams. This gives the agent explicit context for when and how to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![myersparkathleticzone-mcp MCP server](https://glama.ai/mcp/servers/chrischall/myersparkathleticzone-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/myersparkathleticzone-mcp)

Score Badge

Copy to your README.md:

[![myersparkathleticzone-mcp MCP server](https://glama.ai/mcp/servers/chrischall/myersparkathleticzone-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/myersparkathleticzone-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/myersparkathleticzone-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server