euroleague-open-data

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes (search_players vs search_teams, get_player_stats vs get_player_fantasy_log). The fantasy draft tools (get_draft_board, compare_draft_candidates, plan_snake_draft) could be confused at a glance, but their descriptions provide clear triggers for when each should be used.
Naming Consistency4/5
Names follow a consistent verb_noun pattern with lowercase and underscores. There is a mix of verbs (search_, get_, run_, compare_, plan_) but each verb is semantically appropriate for its action, so the variation is minor and not chaotic.
Tool Count5/5
13 tools is well within the ideal 3-15 range and covers both general data retrieval (stats, boxscores, shot charts) and specialized fantasy draft features. Each tool adds distinct value without redundancy.
Completeness4/5
The domain of Euroleague basketball data and fantasy drafting is well covered: search, player/team stats, boxscores, shot charts, coach rotations, and fantasy draft tools. Minor gaps like a game schedule or standings list exist, but the run_sql tool can address these ad hoc.
Average 4.6/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 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
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It discloses that Four Factors are returned for both the team and opponents, and explains how to interpret them (e.g., low tov_pct is good). However, it does not explicitly state that the operation is read-only, nor mention any permissions, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the main purpose is in the first sentence, followed by concise additional detail about the Four Factors interpretation and parameter examples. No redundant or irrelevant content.
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 output schema exists, the description need not detail return structure. It covers parameter semantics, the source of team_code, and interpretability of results. It lacks explicit mention of the read-only safety profile and any prerequisites beyond using search_teams, but these are minor given the nature of a stats retrieval tool.
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%, and the description fully compensates by explaining team_code as 'canonical code from search_teams' with examples, and season as optional with an example. This adds significant meaning 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 returns 'Team season statistics including offensive/defensive rating and the Four Factors', using a specific verb and resource. It distinguishes itself from sibling tools like get_player_stats by focusing on team-level statistics.
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 team-level analysis and provides interpretation guidance for the Four Factors, but it does not explicitly state when to use this tool versus alternatives like get_player_stats or search_teams. There are no explicit exclusions or alternative recommendations.
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?
There are no annotations, so the description carries the full burden. It explains the role of the 'teams' parameter (setting replacement level) and notes that person_codes should be 'two or more,' providing some behavioral detail. However, it does not disclose what the comparison output contains (despite an output schema existing), how it handles missing or invalid codes, or any other side effects. The information given is helpful but not comprehensive.
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 tight and front-loaded: a one-sentence purpose, a one-sentence usage guideline, and a concise args list. Every sentence adds value with no redundancy. The structure is easy to scan.
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 that an output schema exists, the description need not explain return values. It covers the primary purpose, usage context, required parameter, and key optional parameters. The missing explanation of 'scoring' is a minor gap, but overall the description gives an agent enough context to select and invoke the tool 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 0%, so the description must compensate. It explains person_codes, season, and teams: person_codes are 'canonical ids' (two or more), season has an example code, and teams is 'managers in the league, used to set replacement level.' It omits the 'scoring' parameter entirely, leaving it undocumented. Thus, partial semantic 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's action: 'Compare named players side by side for a draft pick decision.' It specifies the resource (players) and the context (draft pick decision), distinguishing it from siblings like get_player_fantasy_log or plan_snake_draft. The example 'Vezenkov or Milutinov?' further clarifies the intended use.
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 says 'Use when the user is choosing between specific players' and provides an example query. It also gives a clear prerequisite: 'Resolve names to person_codes with search_players first.' This directly informs the agent when and how to invoke the tool, including the need to pre-process names.
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?
With no annotations provided, the description carries the full burden. It discloses the game-by-game granularity, the per-player scope, and the behavior of the last_n parameter. It lacks details like error handling or data source caveats, but for a read-only data retrieval tool, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise front-loaded summary, illustrative example, and clear Args section. The example paragraph, while slightly verbose, effectively reinforces the tool's value, so the length is justified.
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 presence of an output schema, the description appropriately focuses on purpose, usage context, and parameter semantics. It covers the essential decision-making context (season averages hide role changes) and parameter details. It falls slightly short of a 5 by not mentioning potential edge cases like invalid player codes or season formats.
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%, but the description fully compensates by explaining every parameter: person_code is the canonical ID from search_players, season uses a format example, and last_n describes both the recent-N behavior and the special case of 0. This adds significant meaning 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 returns game-by-game fantasy points for a single player, explicitly distinguished from season averages and sibling tools like get_player_stats. The phrase 'for judging form and reliability' further clarifies the use case, making the purpose specific and actionable.
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 strong contextual guidance by contrasting with season averages, implying when this tool is needed over aggregate stats. However, it does not explicitly name an alternative tool or state when not to use it, which would justify 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?
No annotations are present, so the description carries the burden. It discloses the ranking methodology, the fact that scoring is recomputed from boxscores, and how teams affect replacement level. However, it does not explicitly state that this is a read-only operation, and there is a slight inconsistency regarding the scoring parameter (schema default 'classic' vs. description's 'modern system'), though this may reflect different aspects.
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 well-structured with sections for usage, fields, and arguments. It front-loads the core purpose and keeps explanations relevant. Slightly verbose, but each sentence provides useful context for an agent.
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 tool has 7 parameters and an output schema. The description explains the ranking logic and key fields, making it complete enough for most draft-related tasks. It could be improved by explicitly mentioning the scoring parameter's effect and clarifying read-only behavior, but overall it covers the complex domain well.
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 description adds meaningful context for all schema parameters except 'scoring'. It explains the impact of 'teams' on replacement level, what 'roster_size' means, and the fields returned. The omission of the 'scoring' parameter is a gap, especially since the description claims a specific scoring system while the schema allows a different default.
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: 'Rank players for a BasketNews Fantasy DRAFT by value over replacement.' It clearly distinguishes the tool from siblings like search_players or compare_draft_candidates by focusing on draft ordering, not generic stats.
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?
Provides explicit guidance: 'Use this for...', 'Do NOT rank by points per game for a draft', and explains why via the unique-roster rationale. It also advises asking the user if the teams count is unknown, making the usage boundaries clear.
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?
No annotations are present, so the description must convey behavioral expectations. It does so by revealing the dual-name matching strategy and the optional season parameter, which helps the agent understand how search results are produced. It does not cover error cases or case sensitivity, but the core search behavior is transparent.
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-organized: a summary sentence, a brief contextual note, and a clean Args list. Every sentence provides necessary value, with no redundancy or irrelevant details.
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, one required, output schema provided), the description covers the essential behavior and parameters adequately. Minor gaps include not clarifying how the season parameter narrows results or the behavior when no match is found, but these are not critical for a search tool.
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 0% description coverage, so the description's Args section is critical. It explains 'name' as 'any part of the club name' with concrete examples and describes 'season' as an optional season code with a format example. This fully compensates for the missing 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 opens with a specific verb-resource pair: 'Find a club's canonical team_code from a partial name.' This clearly defines the tool's objective and distinguishes it from siblings like search_players, which searches for players. The note about seasonal renames adds domain-specific specificity.
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 by explaining that clubs are renamed between seasons and that the tool matches both seasonal and permanent names. This implies when the tool should be used but does not explicitly mention alternatives or when-not-to-use scenarios, stopping 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?
No annotations are provided, so the description carries the full burden. It discloses the output contents (final score, team totals, player lines) and parameter format, which gives a clear picture of the tool's behavior as a read-only retrieval. It does not mention rate limits or authentication, but the nature of a boxscore query makes these less critical.
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 with a clear front-loaded purpose statement followed by a structured argument list. Every sentence adds value: the first sentence defines the tool's output, and the arguments section clarifies both parameters. No unnecessary verbiage.
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 two-parameter tool and the presence of an output schema, the description covers all necessary context: what the tool returns, what each parameter means, and the intended scope ('one game'). The description is complete enough for an agent to select and invoke the tool 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?
Schema description coverage is 0%, so the description must compensate for both parameters. It does so effectively: 'season' is explained with an example format ('E2025'), and 'game_code' is described as 'the game's numeric code within that season.' This adds meaning beyond the schema's bare type definitions.
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 'Full boxscore for one game' and lists specific contents: 'final score, both team totals, and every player line.' This distinguishes it from sibling tools like get_player_stats or get_team_stats, which focus on individual or team aggregates rather than a single game's complete boxscore.
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 by specifying this is for 'one game,' implying it should be used when a full boxscore for a specific game is needed. It does not explicitly name alternatives or exclusions, but the specificity of the purpose makes usage obvious in context of the sibling tools.
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?
With no annotations, the description carries full burden. It discloses key behavior: returns one row per season, season omission yields career view, and rate stats are identical across per_mode values. This gives the agent important operational expectations. It could add error handling or auth notes, but for a stats read tool these are less critical.
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 one-sentence summary, followed by concise usage notes and a clean Args list. Every sentence adds value; no fluff or repetition. It is compact yet information-dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which covers return format), the description provides essential usage context: data granularity, parameter combinations, and rate-stat behavior. This is sufficient for an agent to correctly select and invoke the tool for a player-stats query.
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 coverage is 0%, but the description fully compensates by explaining every parameter with concrete examples: person_code ('006590'), season format ('E2025'), and per_mode enumerated values with a behavioral note about rate stats. This is more informative than the schema itself.
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: 'Season stats for one player'. It clearly distinguishes this from siblings by emphasizing 'one player' vs team stats, and lists specific stats (traditional totals, true shooting, eFG, usage). This unambiguously states what the tool does.
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 states the prerequisite 'Requires a person_code from search_players' and gives usage guidance for the optional season (omit for career view) and per_mode values. It doesn't explicitly list when not to use it versus alternative tools, but the 'one player' scope implies differentiation from team-level tools, offering clear 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?
With no annotations, the description carries full burden and does an excellent job: it explains rotation_style is a relative tercile, coaches with <10 games get insufficient_data, minute_concentration is a Herfindahl index, and data is keyed to the coach. This fully discloses return semantics and edge cases.
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?
Well-structured with a clear lead sentence, justification paragraph, and an Args list. It is somewhat verbose but every sentence earns its place by conveying important context or semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description goes beyond by explaining the meaning of key output fields and edge cases. It covers use case, interpretation, and parameter details, making it fully complete for a tool of this complexity.
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 coverage is 0%, and the description compensates fully with an Args section explaining season format, team_code as an optional club code from search_teams, and coach_name as an optional partial name. This adds meaning far 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?
Clearly states the tool reports how a coach distributes minutes, and frames it as a way to judge a player's minutes ceiling. This distinguishes it from sibling stats tools by focusing on coach-level rotation patterns.
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?
Explicitly tells the user to use it to judge a player's minutes ceiling and explains why rotation depth matters. It does not explicitly name alternative tools for team-based stats, but the coach-vs-team distinction is clearly implied.
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?
With no annotations, the description carries the full burden and delivers: it explains snake-order mechanics, the reverse_snake option, and critically warns that likely_available is a distribution, not a prediction. This goes beyond the schema to set accurate expectations about output reliability.
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 longer than average but every sentence contributes—purpose, usage, snake-order explanation, caveat, and parameter list. It is well-structured with an intro paragraph and an Args list, though the 'Work out' phrasing is slightly redundant with 'plan.'
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 covers what the tool does, when to use it, how the snake logic works, what each parameter means, and the key caveat about likely_available. Since an output schema exists, there is no need to describe return values, making the description essentially complete for invocation.
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 Args section defines all six parameters with practical meanings (e.g., 'roster size',
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 concrete outcome ('which overall picks you own and who should be there') that clearly defines a draft-planning resource. It distinguishes this tool from siblings like get_draft_board or compare_draft_candidates by focusing on the user's own pick schedule and turn-by-turn targets.
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 a clear invocation condition: 'Use this when the user knows their draft slot and wants a plan.' It does not explicitly name alternatives or say when not to use it, but the context is strong enough to signal the intended scenario.
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?
With no annotations, the description fully discloses behavioral caveats: data availability starting in 2007, provisional zone labels, and the 500-row cap on raw coordinates. It also warns that zone coding is upstream's own and points to a data-quality resource. This goes well beyond basic descriptions and provides essential context for the agent.
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 short but information-dense. The first sentence states the core purpose, the second provides a key data caveat, and the Args subsection cleanly maps to parameters. Every sentence earns its place with 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?
Given the tool has 4 parameters and an output schema, the description covers all necessary context: purpose, data limitations, parameter semantics, and response behavior. The output schema handles return-value details, so the description completes the picture without redundancy.
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%, but the description compensates with a dedicated Args section that explains every parameter. It gives a concrete example for season ('E2025'), tells the agent to source person_code from search_players and team_code from search_teams, and explains include_raw's effect and its 500-row cap. This fully resolves any ambiguity in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Shot-zone breakdown, optionally with raw x/y coordinates,' which clearly identifies the tool's output as shot-zone data with an optional raw coordinate mode. It distinguishes itself from sibling tools like get_player_stats and get_team_stats by focusing specifically on shot zones. The purpose is specific and 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 usage context: it notes that shot data exists only from 2007 onward and that earlier seasons have boxscores but no coordinates, guiding when not to use the tool. It also explains how to obtain person_code and team_code from search_players and search_teams, which aids integration. However, it does not explicitly name alternative tools or provide a direct when-to-use versus alternatives comparison, 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?
With no annotations, the description discloses key behavioral traits: case-insensitive and substring-based matching, season restriction, and limit default. It also notes the output is a canonical person_code. It doesn't mention empty-result behavior, but output schema covers return structure, making this acceptable.
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 tightly written with three clear sections: purpose, usage guidance, and parameter definitions. Every sentence adds value, including concrete examples ('doncic', 'Luka') that clarify matching behavior without unnecessary length.
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 tool is a simple lookup with three parameters and an output schema. The description covers purpose, usage, parameter meanings, and key matching behavior. Since output schema exists, explaining return structure is unnecessary, so the description is complete for this context.
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 coverage is 0%, but the description provides detailed semantics for all three parameters: name is 'any part of the player's name', season has an example format, and limit states its default. This fully compensates for the sparse 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 finds a player's canonical person_code from a partial or misspelled name. It distinguishes itself from other player tools by emphasizing that every other tool requires a person_code, not a name, making the unique 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Call this FIRST whenever the user names a player' and explains that all other player tools take a person_code, not a name. This provides clear when-to-use guidance and implicitly contrasts with alternative tools like get_player_stats.
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?
Without annotations, the description carries full responsibility for disclosure. It openly states that the warehouse holds zero rows for players from the NBA or domestic leagues, and explicitly warns 'Do not invent a projection.' It also details exactly what the tool returns (vacated minutes and fantasy points per position, remaining players' minute stability), which is transparent about the tool's behavior and limitations.
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 somewhat longer than two sentences, but every sentence is purposeful. It flows logically from an overview, to usage cases, to limitations, to return structure, to parameter definitions. No fluff or repetition exists, and the structure makes it easy to parse.
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 complexity, the description is complete. It explains the core purpose, anticipated use cases, limitations, output details, and parameters. An output schema exists to further clarify the return structure, so the description need not repeat that. The combination of description, schema, and sibling-context makes this a fully-specified tool.
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 descriptions for team_code or season, and schema coverage is 0%. The description compensates fully by providing 'team_code: club code from search_teams' and 'season: season code, e.g. "E2025"'. This adds cross-referencing to a sibling tool and an example format, making both parameters 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 opens with a precise statement of what the tool provides: 'What minutes and production a club has vacated, by position, plus who remains.' This clearly identifies the resource (role outlook for a club) and distinguishes it from sibling tools like get_team_stats or get_player_stats by focusing on vacated roles and remaining player stability. The purpose is unmistakable.
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 the tool: 'This is the tool for "how will player X do at his new club" and for drafting anyone without history in this competition.' It also provides a clear when-not scenario: if a player comes from the NBA or a domestic league, no projection is possible. It further instructs the agent to state the vacated role and let the user supply the player's level, which is strong usage guidance.
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?
With no annotations provided, the description carries the full burden and discharges it well. It discloses that the connection is read-only, only a single SELECT/WITH is permitted, results are capped, and queries are cancelled after 15 seconds. These are critical behavioral traits for a SQL tool.
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: purpose, usage, prerequisite, constraints, and parameters are presented in a clear, efficient order. Every sentence earns its place with 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?
Despite being a complex SQL tool with an output schema, the description covers all necessary context: when to use, safety constraints, the schema prerequisite, and parameter semantics. The output schema exists, so return values need not be described here.
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%, but the Args section compensates fully. It clarifies that sql must be a single SELECT (or WITH ... SELECT) statement, and that limit is capped at 500 rows. This adds essential meaning beyond the bare schema types.
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: 'Run a read-only SQL SELECT against the warehouse.' It clearly positions this as a generic fallback for questions the other tools cannot answer, distinguishing it from the specialized sibling tools like search_players and get_team_stats.
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 explicitly states when to use this tool: 'Use this for any question the other tools cannot answer.' This implies specialized siblings should be preferred, and also instructs the agent to read the euroleague://schema resource first. Constraints like single SELECT/WITH, read-only, cap, and 15-second timeout further guide usage.
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:

[![euroleague-open-data MCP server](https://glama.ai/mcp/servers/McNews11/euroleague-open-data/badges/card.svg)](https://glama.ai/mcp/servers/McNews11/euroleague-open-data)

Score Badge

Copy to your README.md:

[![euroleague-open-data MCP server](https://glama.ai/mcp/servers/McNews11/euroleague-open-data/badges/score.svg)](https://glama.ai/mcp/servers/McNews11/euroleague-open-data)

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/McNews11/euroleague-open-data'

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