NHL MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different NHL data categories (games, players, teams, standings, etc.), but there is some overlap between get_player_stats and get_team_stats (which includes player stats) that could cause minor confusion. The compare_seasons and compare_teams tools are clearly differentiated from the get_* tools.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with clear, descriptive names. The pattern is uniform across all 11 tools, using either 'get_' or 'compare_' prefixes followed by specific nouns, making them predictable and easy to understand.
Tool Count5/5
With 11 tools, this server is well-scoped for an NHL data domain, covering key aspects like games, players, teams, standings, and schedules. Each tool serves a distinct purpose without feeling bloated or insufficient, fitting the typical range of 3-15 tools for a focused server.
Completeness4/5
The tool set provides comprehensive coverage for accessing NHL statistics and information, including live games, historical data, comparisons, and playoff details. Minor gaps exist, such as lack of tools for draft information, league news, or player injury reports, but core workflows are well-supported without dead ends.
Average 3.2/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
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool compares statistics but does not describe what statistics are returned, how data is formatted, whether it's aggregated or detailed, or any limitations like rate limits or data freshness. For a tool with no annotations, this is a significant gap in transparency.
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 a single, efficient sentence that directly states the tool's purpose without any wasted words. It is front-loaded with the core functionality, making it easy to parse and understand quickly. This exemplifies good conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of comparing statistics across seasons, the lack of annotations, and no output schema, the description is incomplete. It does not explain what kind of statistics are compared, the format of the output, or any behavioral traits like data sources or limitations. For a tool with no structured support, the description should provide more context to be fully helpful.
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 has 100% description coverage, clearly documenting both parameters. The description adds no additional semantic information beyond what the schema provides, such as explaining the meaning of 'teamAbbrev' or 'seasons' in context. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but the description does not compensate with extra insights.
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's purpose: 'Compare team or player statistics across multiple NHL seasons.' It specifies the verb ('compare'), resource ('team or player statistics'), and scope ('across multiple NHL seasons'), making it easy to understand. However, it does not explicitly differentiate from sibling tools like 'compare_teams' or 'get_team_stats', which might offer overlapping functionality, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools such as 'compare_teams' or 'get_team_stats', nor does it specify prerequisites, exclusions, or contexts for usage. This lack of comparative guidance leaves the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states what data is returned but doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'Get'), potential rate limits, authentication needs, error handling, or data freshness. For a tool with no annotations, this leaves significant gaps in understanding how it behaves.
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 a single, efficient sentence that front-loads the core purpose and lists specific data types. Every word earns its place with no redundancy or fluff, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that returns complex data (play-by-play, scoring plays, etc.). It mentions what data is included but doesn't explain return format, structure, or potential limitations. For a detailed query tool, more context on output behavior is needed to be fully helpful.
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% for the single parameter (gameId), so the schema already documents it fully. The description adds no additional meaning beyond what the schema provides (e.g., no examples of valid gameIds or format details). Baseline 3 is appropriate when schema does the heavy lifting, though no extra value is added.
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 verb 'Get' and resource 'detailed information about a specific game', specifying the types of data included (play-by-play, scoring plays, period summaries). It distinguishes from siblings like get_schedule (list of games) or get_player_stats (player-focused), though not explicitly named. The purpose is specific but could be more precise about sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage for detailed game data, but doesn't mention prerequisites (e.g., needing a valid gameId), exclusions (e.g., not for live games vs. get_live_games), or direct comparisons to siblings like get_schedule for game lists. The context is clear but lacks operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the types of statistics returned but fails to describe critical behaviors like rate limits, authentication needs, error handling, or whether the data is real-time or historical. This leaves significant gaps for an agent to understand operational constraints.
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 a single, efficient sentence that front-loads the core purpose and lists key metrics without unnecessary details. It avoids redundancy and waste, though it could be slightly more structured by separating usage context from the metric list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with behavioral complexity. It omits details on return format (e.g., structured data, pagination), error cases, and how statistics are calculated or sourced, which are essential for an agent to use the tool effectively in varied contexts.
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 has 100% description coverage, clearly documenting both parameters ('limit' and 'season') with defaults and formats. The description adds no additional parameter semantics beyond what the schema provides, such as explaining how 'limit' affects ranking or what 'season' encompasses. Baseline 3 is appropriate as the schema handles the heavy lifting.
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's purpose with a specific verb ('Get') and resource ('NHL goalies'), listing key metrics like save percentage, GAA, wins, and shutouts. It distinguishes itself from sibling tools like 'get_player_stats' by focusing on goalie-specific data, though it doesn't explicitly 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_player_stats' for non-goalie players or 'get_team_stats' for team-level data. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is most appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what data is returned but doesn't mention whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or response format. For a data retrieval tool with zero annotation coverage, this leaves significant behavioral gaps.
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 a single, efficient sentence that gets straight to the point. It's appropriately sized for a straightforward data retrieval tool and front-loads the core purpose without unnecessary elaboration. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with 3 well-documented parameters but no output schema, the description is minimally adequate. It tells what data is returned but doesn't describe the response structure, pagination, or data freshness. With no annotations and no output schema, more context about the return format would be helpful for the agent to understand what to expect.
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 all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema - it mentions general statistics but doesn't explain how parameters affect the query. Baseline 3 is appropriate when schema does the heavy lifting.
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's purpose: 'Get statistics for top NHL players including goals, assists, points, plus/minus, and other performance metrics.' It specifies the verb ('Get'), resource ('top NHL players'), and scope of data returned. However, it doesn't explicitly differentiate from sibling tools like 'get_goalie_stats' or 'get_team_stats' beyond implying player focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_goalie_stats' for goalie-specific data or 'get_team_stats' for team-level statistics. There's no context about prerequisites, limitations, or typical use cases beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states what data is returned but doesn't disclose whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or how 'current' is determined (e.g., live updates vs. cached data).
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 a single, efficient sentence that front-loads the core purpose and lists key data components. Every word earns its place with zero redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficiently complete. It lacks details on return format (e.g., structure of bracket data), error handling, authentication needs, or how 'current' interacts with the optional season parameter, leaving significant gaps for agent understanding.
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 the single parameter 'season' with its type and default behavior. The description adds no additional parameter semantics beyond implying the bracket is season-specific, which is already covered by the schema.
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 action ('Get') and resource ('current playoff bracket') with specific components ('series information, matchups, and results'). It distinguishes from siblings like get_schedule or get_standings by focusing on playoff brackets, but doesn't explicitly differentiate from tools like compare_seasons that might involve playoff data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, timing considerations, or comparisons to sibling tools like get_schedule or get_standings that might overlap with playoff information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but does not specify whether it requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with zero annotation coverage, this lack of behavioral context is a significant gap, though it at least correctly implies a read operation.
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 a single, efficient sentence that front-loads the core purpose. It avoids redundancy and wastes no words, making it easy to parse. However, it could be slightly improved by structuring key details more explicitly, but it remains highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving detailed team statistics), no annotations, and no output schema, the description is minimally adequate. It covers the purpose and data scope but lacks details on behavioral traits, usage guidelines, and output format. It meets the basic requirement but leaves gaps that could hinder an agent's effective use, especially without annotations to fill in missing context.
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 schema description coverage is 100%, with clear descriptions for both parameters (teamAbbrev and season). The description adds no additional parameter semantics beyond what the schema provides, such as format details or examples not already covered. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.
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's purpose: 'Get detailed statistics for a specific NHL team including roster, season performance, and player stats.' It specifies the verb ('Get'), resource ('NHL team'), and scope of data returned ('roster, season performance, and player stats'). However, it does not explicitly differentiate from sibling tools like get_team_streak or get_standings, which might also provide team-related statistics, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like get_team_streak or get_standings, nor does it specify contexts or exclusions for usage. The agent must infer usage based on the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves streak information 'based on recent game results,' which hints at read-only behavior, but doesn't clarify data freshness, rate limits, error handling, or authentication needs. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
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 a single, well-structured sentence that efficiently conveys the tool's purpose without unnecessary words. It is front-loaded with the main action and resource, making it easy to parse quickly. Every part of the sentence earns its place by specifying the scope ('NHL team') and basis ('recent game results').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is adequate but incomplete. It explains what the tool does but lacks details on behavioral aspects like data sources or limitations. Without annotations or an output schema, the description should provide more context to fully guide the agent, but it meets the minimum viable threshold.
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 has 100% description coverage, with the parameter 'teamAbbrev' clearly documented. The description doesn't add any additional meaning beyond what the schema provides, such as examples of abbreviations or constraints. Since the schema does the heavy lifting, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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's purpose with a specific verb ('Get') and resource ('current winning or losing streak for an NHL team'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_team_stats' or 'get_standings' that might also provide streak-related information, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance by mentioning 'based on recent game results,' which implies context but doesn't specify when to use this tool versus alternatives like 'get_team_stats' or 'get_standings.' No explicit when-to-use or when-not-to-use instructions are included, leaving the agent to infer usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'recent matchups and historical records' but doesn't disclose data freshness, rate limits, authentication needs, or what specific statistics are included, leaving gaps for a tool that likely queries external data.
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 a single, efficient sentence that front-loads the core purpose ('compare head-to-head statistics') and includes key scope details ('between two NHL teams including recent matchups and historical records') without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool with three parameters and likely complex return data. It lacks details on output format, error handling, or data sources, which are critical for an agent to use this tool effectively in context with siblings.
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 all parameters (team1, team2, season). The description adds no additional meaning beyond implying these parameters are used for comparison, maintaining the baseline score as the schema handles the heavy lifting.
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 specific action ('compare head-to-head statistics') and resource ('between two NHL teams'), distinguishing it from sibling tools like get_team_stats or get_standings by focusing on direct team comparisons rather than individual team metrics or broader league data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. While it implies comparison of two teams, it doesn't specify scenarios where this is preferred over other tools like get_team_stats for individual team analysis or compare_seasons for temporal comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool can retrieve schedules but doesn't cover key traits like whether it's read-only (implied by 'Get'), rate limits, error handling, or output format. This leaves significant gaps for a tool with no structured safety hints.
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 appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second adds parameter context. There's no wasted text, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and parameter hints but lacks details on behavior, output, or integration with siblings, leaving room for improvement in completeness.
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 input schema fully documents both parameters (date and teamAbbrev) with descriptions. The description adds minimal value by hinting at optionality ('Can get schedule for a specific date or team') but doesn't provide additional semantics beyond what the schema already states, meeting the baseline.
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's purpose: 'Get NHL schedule for upcoming games.' It specifies the resource (NHL schedule) and scope (upcoming games). However, it doesn't explicitly differentiate from siblings like 'get_live_games' or 'get_game_details,' which might also retrieve schedule-related data, so it misses the top score.
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 implied usage by mentioning 'Can get schedule for a specific date or team,' suggesting when to use optional parameters. But it lacks explicit guidance on when to choose this tool over alternatives like 'get_live_games' for current games or 'get_game_details' for specific matchups, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes what data is returned (standings with specific metrics) and filtering options, but doesn't disclose behavioral traits like whether this is a read-only operation (implied by 'Get'), rate limits, authentication requirements, or how 'current' is determined (real-time vs. cached). The description doesn't contradict any annotations since none exist.
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 efficiently structured in two sentences: the first states the core purpose and data returned, the second adds filtering capabilities. Every word earns its place with no redundancy or unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 optional parameters, no output schema, no annotations), the description is adequate but has gaps. It covers what data is returned and filtering options, but doesn't explain the return format (e.g., structured list of teams), how standings are ordered, or what happens when multiple filters are combined. For a data retrieval tool with no output schema, more detail about the response structure would be helpful.
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 fully documents all three parameters (date, division, conference) with their types, formats, and options. The description adds minimal value beyond the schema by mentioning filtering capabilities but doesn't provide additional semantic context like parameter interactions or default behaviors beyond what's in the schema descriptions.
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 verb ('Get') and resource ('current NHL standings') with specific data fields included (wins, losses, points, goals for/against, goal differential). It distinguishes from siblings like get_game_details or get_player_stats by focusing specifically on standings rather than game details, player stats, or other team metrics.
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 this tool ('Get current NHL standings') and mentions filtering capabilities by division or conference. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (e.g., when to use get_team_stats instead for different metrics).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes what information is returned (scores, period, game state, venue) but doesn't mention rate limits, authentication needs, error conditions, or whether data is real-time vs cached. It adequately covers the core behavior but lacks operational details.
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 efficiently structured in two sentences with zero waste. The first sentence establishes purpose and scope, the second details the returned information. Every phrase adds value without redundancy or unnecessary elaboration.
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 tool with one well-documented parameter and no output schema, the description is reasonably complete. It covers purpose, scope, and return information. However, without annotations or output schema, it could benefit from mentioning response format or data freshness, though not strictly required for basic functionality.
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 fully documents the single optional date parameter. The description adds marginal value by mentioning 'today or a specific date' context, but doesn't provide additional syntax or format details beyond what the schema specifies. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Get'), resource ('live NHL game scores and status'), and scope ('for today or a specific date'). It distinguishes from siblings like get_schedule (future games) and get_game_details (specific game details) by focusing on live games with current status.
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 this tool ('for today or a specific date'), but doesn't explicitly state when not to use it or name alternatives. It implies usage for live game information rather than historical stats or schedules, though no explicit exclusions are given.
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:

[![nhl-mcp-ts MCP server](https://glama.ai/mcp/servers/argotdev/nhl-mcp-ts/badges/card.svg)](https://glama.ai/mcp/servers/argotdev/nhl-mcp-ts)

Score Badge

Copy to your README.md:

[![nhl-mcp-ts MCP server](https://glama.ai/mcp/servers/argotdev/nhl-mcp-ts/badges/score.svg)](https://glama.ai/mcp/servers/argotdev/nhl-mcp-ts)

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/argotdev/nhl-mcp-ts'

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