jk-mcp-usls

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct data type or query: team lists vs. details, schedules vs. scoreboards vs. match events, and three separate analytics tools that do not overlap. An agent can easily select the right tool without confusion.
Naming Consistency5/5
Every tool follows the same get_ prefix with descriptive noun phrases (get_teams, get_standings, get_match_details). This consistent pattern makes the toolset predictable and easy to navigate.
Tool Count5/5
With 11 tools, the server is well-scoped for a sports data API: core retrieval (teams, standings, schedules, scores, rosters, news) plus a few advanced analytics tools. No tool feels redundant or out of place.
Completeness5/5
The domain of USL Super League data is thoroughly covered: teams, standings, matches, rosters, news, and analytical queries. The read-only nature is consistent with a data feed, and no critical data type appears missing.
Average 4.6/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 5, 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and idempotency. The description adds value by specifying return statuses (scheduled, in-progress, completed) and fields (opponent, date, score, status), which are not in annotations. No contradictions.
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 concise and well-structured: a single sentence stating the primary purpose, a second sentence summarizing return contents, and an Args block for the parameter. No fluff or redundant information, and the main purpose is front-loaded.
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?
With an output schema and comprehensive annotations, the description is sufficiently complete for a simple one-parameter read-only tool. It covers purpose, return fields, and parameter semantics. Minor gaps like defining 'current season' boundaries or potential errors are not critical given the available structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'team_id' string with no description (0% coverage). The description fully compensates by explaining it is an 'ESPN numeric team ID' and providing an example ('18418' for Atlanta United FC). This gives clear parameter semantics beyond the bare 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?
The description clearly states the tool's function: 'Get all matches for a single USL Super League team in the current season.' It specifies the resource (matches for a team) and distinguishes from sibling tools like get_scoreboard or get_match_details by focusing on the full season schedule. It also enumerates return components, reinforcing purpose clarity.
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 implies usage for retrieving a team's complete schedule but does not explicitly contrast with alternatives such as get_match_details for single matches or get_scoreboard for current games. There are no exclusions or 'use X instead' statements, so the guidance is implied rather than explicit.
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 annotations already declare the tool read-only, idempotent, and non-destructive. The description adds context about the response structure, listing the specific article fields returned, which is beyond the annotation coverage. No contradictory behavior is disclosed.
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 concise and front-loaded, starting with the main purpose and then adding details on the return format and parameter. Every sentence is informative and there is no 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?
Given the tool's simplicity, the description covers the purpose, the parameter, and the return structure. The output schema exists to detail return fields, so the description does not need to repeat them, and it doesn't. It is complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name, type, and default, with 0% description coverage. The description adds crucial meaning by explaining that 'limit' is the maximum number of articles to return and notes the default of 10, fully compensating for the schema's lack of description.
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 fetches recent USL Super League news articles, with a specific verb and resource. It distinguishes from sibling tools like get_teams and get_standings by focusing on news. The return fields are also listed, making the purpose unambiguous.
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 implies the tool is for news articles but does not explicitly mention alternatives or when not to use it. Sibling tools cover teams, standings, and scores, so usage can be inferred, but no direct 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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds meaningful behavior: tiers come from live league standings, top/bottom tier_size are defined, and it clarifies the 'middle' as everyone in between. No contradictions with annotations; it could add more detail on output, but the output schema covers that.
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 front-loaded with a crisp one-sentence purpose, followed by a short explanatory paragraph and a well-organized Args block. Every sentence adds value, and there is no redundant or filler content.
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?
With read-only annotations, an output schema present, and thorough parameter explanations, the description fully equips an agent to select and invoke the tool. It explains tier derivation, provides an example use case, and defines constraints, making it self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameter descriptions, but the description's Args section fully compensates by explaining team_id as an ESPN numeric team ID and tier_size with its default, minimum, and constraint that 2*tier_size must not exceed league size. This goes well beyond the schema's type/default fields.
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 states the tool gets a team's W-L-T splits against top-tier, middle, and bottom-tier teams, using a specific verb and resource. It distinguishes itself from sibling tools like get_standings or get_team_schedule by its analytic angle, but it doesn't explicitly name an alternative tool or contrast with them.
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 provides clear context for when to use the tool—e.g., asking 'how does this team do against the top of the table?' and avoiding manual result scanning. It also explains how tiers are derived. However, it doesn't explicitly state when-not-to-use or name a sibling tool as an alternative, so it stops short of a 5.
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 the tool as read-only and idempotent. The description adds valuable behavioral context by explaining the exact calculation (scaling by opponent/league average) and how to interpret values above/below raw PPG. It does not disclose edge cases or error handling, but the core behavior is well described.
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 concise, front-loaded with the purpose, and uses a compact formula and interpretation. The Args section is minimal and to the point, with no unnecessary verbosity.
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 read-only tool with an output schema, the description fully explains what is returned (raw and adjusted PPG) and how to interpret the adjusted value. It provides all necessary context for typical usage without requiring further elaboration.
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 single parameter team_id is described as an 'ESPN numeric team ID,' adding clarity beyond the schema's generic 'Team Id' label. This compensates for the schema's lack of parameter description, though it could note that the ID is a string representation of a number.
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 gets a team's raw and adjusted points-per-game, with a specific formula and interpretation. This distinguishes it from siblings like get_teams or get_standings by focusing on the adjusted metric.
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 context is clear: use this when you need a team's scoring output adjusted for opponent quality. The formula explanation implicitly guides usage, though it does not explicitly name alternative tools for raw stats or schedule strength. This is a minor gap but the intended use is well conveyed.
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, idempotentHint, and non-destructive behavior, so the description doesn't need to repeat those. It adds value by specifying exactly what data is returned (score, venue, attendance, chronological events), which goes beyond the annotations. It doesn't mention error conditions or rate limits, but the annotations cover the safety profile.
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 concise and well-structured: a clear opening sentence, a sentence listing return contents, a usage hint, and an Args block. Every sentence contributes important information, and the format is easy to scan.
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 tool's simplicity (one parameter), the presence of an output schema, and strong annotations covering safety and idempotence, the description is complete. It explains how to obtain the required input (match ID from scoreboard/schedule) and what the output covers, leaving no critical gaps.
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 provides only the parameter name and type (match_id: string) with no description. The description compensates by explaining that match_id is an 'ESPN numeric event ID' and provides an example format ('401853883'). This adds meaningful semantics beyond the schema, though it could be even more detailed about accepted formats.
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: 'Get detailed information for a single USL Super League match.' It lists specific return contents (score, venue, attendance, chronological key events) and distinguishes itself from sibling tools like get_scoreboard and get_team_schedule by focusing on a single match's details.
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 explicitly directs the user to use a match ID returned by get_scoreboard or get_team_schedule, which provides clear context for when to use this tool. It doesn't explicitly state exclusions, but the input-source guidance effectively communicates the intended workflow.
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 establish this as a safe, read-only, idempotent operation. The description adds behavioral context by noting the current nature of the data and the specific computed statistics (win/loss/tie, goals for/against, differential), which isn't captured by the annotations or input schema.
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 front-load the action and resource, then provide precise details about the return format and ordering. No filler.
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?
With no parameters, an output schema, and strong annotations, the description fully covers the tool's purpose and return semantics. It's self-contained.
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?
No parameters exist, so the description need not document them. The baseline for 0 params is 4, and the description adds no conflicting information.
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 retrieves the USL Super League standings, a specific resource with a clear verb. It differentiates from siblings like get_scoreboard or get_teams by specifying the ordered table with team records and goal stats.
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 use when current standings are needed, but does not explicitly discuss alternatives or exclusion criteria. The clear resource name and context provide reasonable guidance, so a 4 is appropriate.
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, idempotentHint, and destructiveHint false. The description adds that it returns specific player fields and emphasizes 'active' roster, providing value beyond the annotations. It doesn't mention auth or rate limits, but for a read-only tool with strong annotations, this is sufficient.
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 front-loaded with the purpose, followed by return fields, usage tip, and parameter detail. Every sentence earns its place; no wasted words.
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?
With one required parameter, clear output information, and a hint to obtain the team ID, the description fully covers what is needed to invoke the tool correctly. The output schema exists, so return values are well-defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for team_id (0% coverage), but the description defines it as 'ESPN numeric team ID' and gives an example for Atlanta United FC. This fully compensates for the missing schema description.
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 'Get the active roster for an USL Super League team' with a specific verb and resource, and lists returned player fields. This distinguishes it from sibling tools like get_teams and get_standings.
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 instructs users to use the team ID returned by get_teams, providing a clear prerequisite and linking to a sibling tool. It implies this is for roster queries, but lacks explicit when-not-to-use guidance, so a 4.
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 readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations: the league (USL Super League), the return contents (display name, abbreviation, location), and the ESPN ID source. No contradictions 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 compact: two short paragraphs with the purpose first, then return highlights, then parameter details. Every sentence earns its place; there is 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?
This is a simple read operation with strong annotations, an output schema, and a single parameter. The description covers the league, the specific-team scope, the parameter format/source, and expected return fields. Nothing critical is missing 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for team_id (0% coverage), so the description must compensate. It does so excellently by specifying the parameter is an 'ESPN numeric team ID', giving a concrete example ('18418' for Atlanta United FC), and pointing to get_teams as the source.
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 a specific verb+resource pattern: 'Get details for a specific USL Super League team.' It clearly differentiates from the sibling get_teams by emphasizing 'specific' and referencing the numeric 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 gives an explicit prerequisite: 'Use the numeric ID returned by get_teams.' This establishes when to use this tool and ties it directly to its listing sibling. It does not enumerate exclusions for other sibling tools, but the 'specific team' framing makes the intended use 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, openWorldHint, and idempotentHint, so the safety profile is clear. The description adds value by specifying that it returns a numbered list, the exact fields (ID, full name, abbreviation, home city), and that it only includes active teams—context 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, front-loaded with the core purpose, followed by return format and cross-reference. No fluff, 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 simplicity (0 params), rich annotations, and existence of an output schema, the description is complete. It covers what the tool does, what it returns, and the next step for detailed lookup.
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 schema coverage is 100% trivially. The baseline for 0 params is 4; the description doesn't need to elaborate on parameters and doesn't.
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 'Get all active USL Super League teams' with a specific verb (get), resource (teams), and scope (active, USL Super League). It also distinguishes itself from the sibling tool get_team by explaining that get_team is for detailed information on a specific 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 explicitly directs users to use get_team with the ID or abbreviation for detailed info, providing a clear alternative and indicating when to choose this list tool. It implies a workflow: first call get_teams to obtain IDs/abbreviations, then call get_team.
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 declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive. The description adds valuable behavioral nuance beyond these: the default no-argument behavior (current matchweek), the inclusive date range, and the dependency that end_date requires date. This contextualizes the tool's behavior in a way annotations alone cannot.
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 model: a single-sentence summary followed by a compact Args list. No fluff, no repetition. Front-loads the primary purpose and then granularly details each parameter and usage mode. 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 tool's simplicity, an output schema, and strong annotations, the description is fully complete. It covers all invocation modes (none, date only, date+end_date), parameter format, and constraints. No gaps remain for an agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It explicitly explains both parameters: date is an optional start date in YYYYMMDD format with an example, and end_date is optional but requires date. It also clarifies the semantic relationship between parameters, going well beyond the raw 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?
The description opens with a specific verb and resource: 'Get USL Super League match scores and status for a date or date range.' This clearly distinguishes it from siblings like get_standings (tables), get_match_details (specific match), and get_team_schedule (team fixtures). The scope and output are unambiguous.
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 behavioral context for when to use the tool: no arguments gives current matchweek, single date gives one day, date range gives inclusive range. It does not explicitly mention alternatives or exclusions, but the scenarios are thoroughly defined, making it clear when this tool should be selected.
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?
While annotations already indicate a safe read-only operation, the description adds substantive behavioral details: it returns the average current points-per-game and a per-opponent breakdown, and clarifies it only considers completed matches. 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 compact and well-organized: purpose coming first, followed by return behavior, usage context, and argument documentation. Every sentence provides value with no fluff 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 one-parameter read-only tool with an output schema, the description covers the computation method, when to use it, and the parameter format. The output schema handles return structure details, so the description needs no further expansion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description for team_id, but the description compensates fully by explaining it is an ESPN numeric team ID and providing an example. This makes the parameter semantics clear and actionable.
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 'gets a team's strength of schedule based on opponents already faced' with a specific verb and resource. It distinguishes from sibling tools like get_team_schedule by focusing on schedule difficulty rather than the schedule itself.
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 gives clear context, noting it is 'useful early in the season' for comparing who has played a tougher schedule. However, it does not explicitly mention alternatives or when not to use this tool, so it stops short of full guidance.
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:

[![jk-mcp-usls MCP server](https://glama.ai/mcp/servers/jedi-knights/jk-mcp-usls/badges/card.svg)](https://glama.ai/mcp/servers/jedi-knights/jk-mcp-usls)

Score Badge

Copy to your README.md:

[![jk-mcp-usls MCP server](https://glama.ai/mcp/servers/jedi-knights/jk-mcp-usls/badges/score.svg)](https://glama.ai/mcp/servers/jedi-knights/jk-mcp-usls)

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/jedi-knights/jk-mcp-usls'

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