PlayerElo MCP server

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 entity or specific aspect (e.g., player history vs. player value vs. player style). Search tools are separated by entity (players, coaches, clubs). No two tools appear to perform the same function, and any conceptual overlaps (like player opportunities vs. transfer fit) are complementary rather than redundant.
Naming Consistency5/5
All tool names follow a consistent lowercase_underscore convention with verb prefixes: search_*, list_*, and get_*. The get_* tools use clear entity-specific suffixes (e.g., get_player_history, get_club_squad_gaps). This makes the naming predictable and easy to navigate.
Tool Count4/5
With 17 tools, this is slightly above the typical well-scoped range, but the server covers a broad domain (players, coaches, clubs, leagues, predictions, betting). Each tool serves a distinct purpose and the count feels justified rather than bloated.
Completeness4/5
The tool surface covers core read operations for all entities, including specialized analytics (player history, value, style, opportunities; club squad gaps; league rankings; predictions; value bets). Minor gaps exist, such as no coach history or player match-level stats, but these are not critical to the server's stated purpose.
Average 4.1/5 across 17 of 17 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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?
No annotations are provided, so the description carries the burden of behavioral disclosure. It adds useful context by specifying the ranking criterion (Team Elo) and temporal scope (current-season), but it does not state the return format, ordering direction, or any limits/assumptions; read-only behavior is only inferred from the 'get' prefix.
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, front-loaded sentence that immediately states the core result and adds a clarifying parenthetical. It contains no filler, redundant phrasing, or unnecessary 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?
With an output schema present and only one parameter, the description sufficiently covers the tool's purpose and output meaning. It lacks only minor details like explicit descending order or pagination, but the output schema likely handles return shape, making the description complete enough for straightforward use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, league_id, has 0% schema description coverage, and the description does not explicitly explain its role beyond implying it selects the league. Since 'A league's clubs' hints at the parameter's purpose, there is minimal added meaning over the schema's title and type, but the description does not compensate for the coverage gap.
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 league's clubs ranked by Team Elo, with the parenthetical 'current-season strength order' adding scope. This distinguishes it from siblings like list_leagues (which lists leagues rather than club rankings) and get_club (which targets a single club).
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?
There is no explicit guidance about when to use this tool versus alternatives, nor any mention of exclusions or prerequisites. The description only implies usage for current-season club ranking, but it does not name sibling alternatives or define when this tool is preferred.
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 disclosing behavioral traits. It does reveal that the tool returns a model-based estimate with underlying signals, and explicitly states it is not a third-party valuation. However, it does not disclose what the signals consist of, whether the output is a single number or a structured breakdown, or any potential limitations. This is adequate but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence states the core purpose and output units, and the second adds a clarifying distinction. It is front-loaded, contains no redundant wording, and every sentence contributes meaning.
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 (one parameter, clear purpose) and the presence of an output schema, the description is largely complete. It tells the user what the tool returns (estimate + signals), the currency, and its proprietary nature. The only notable gap is the lack of usage guidance, but that is covered separately in the usage dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, player_id, with 0% description coverage. The description does not elaborate on player_id, how to obtain it, or its format. While the parameter name is self-explanatory in context, the description does not compensate for the lack of schema documentation, leaving the agent to infer semantics from the tool name and parameter title alone.
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 that the tool provides PlayerElo's own model-based market-value estimate in euros, including the signals behind it. This is a specific, unambiguous purpose that distinguishes it from the sibling tools like get_player or get_player_history, which likely provide general profile or historical data. The phrase 'not a third-party valuation' further narrows its scope.
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 does not provide explicit guidance on when to use this tool versus its siblings. It only clarifies that the estimate is proprietary, which implies a use case for internal valuation, but does not state alternatives, exclusions, or when to prefer other player-related tools. There is no mention of how to find player_id or any prerequisite steps.
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 responsibility. It describes the tool as an 'analysis' which implies a read-only operation, but it does not disclose any behavioral specifics such as data sources, potential side effects (even if none), permissions, or error conditions. The description adds only purpose-level context, not the transparency expected from a tool with zero 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 a single, well-structured sentence with no wasted words. It front-loads the core purpose and adds a meaningful detail ('relative to its level') that clarifies the analysis scope. Every word earns its place.
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?
The tool is simple (one parameter, no nested objects, output schema present), so the description does not need to explain return values. It covers the purpose clearly, but it omits any guidance on the parameter and offers no contextual hints about prerequisites or typical usage. For a tool of this complexity, it is minimally adequate but has clear gaps in parameter clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention 'team_id' at all. With a single required parameter, the description should clarify what 'team_id' refers to (e.g., club ID) and how it relates to the analysis. It fails to add any meaning beyond the bare parameter name, leaving the agent to infer the mapping between 'club' and 'team'.
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 a specific function: analyzing a club's squad gaps by position relative to its level. It uses a resource ('club's squad-need analysis') and a clear output ('which positions are weakest... recruitment gaps'), distinguishing it from sibling tools like get_club or search_players.
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: when analyzing squad recruitment gaps for a club. It does not explicitly exclude alternatives or name when-not-to-use, but the context is sufficient for an agent to infer appropriate usage given the unique analysis focus.
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, the description carries the full burden. It does disclose the Business-tier key requirement, which is valuable, and sets expectations about realistic and plausible clubs. However, it does not mention whether the operation is read-only, quota usage, or response characteristics.
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 just two sentences, with the core function in the first and a requirement in the second. It is front-loaded and contains no filler.
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?
The description covers the core purpose and access requirement, which is adequate for a simple read-like tool. However, it omits parameter semantics and usage guidance, and with no annotations the agent must infer these. The presence of an output schema reduces the need to explain return values, but parameter clarity remains a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It never mentions top_n or clarifies that player_id is the player for whom to find opportunities. It only implicitly ties to a player via 'for a player', leaving both parameters under-explained.
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 defines the tool's function: producing a recruitment opportunity map with reachable clubs ranked by fit. It uses a specific verb (map) and resource (player opportunities), which distinguishes it from sibling tools like get_club_squad_gaps and get_player.
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 a scouting/transfer scenario via 'recruitment opportunity map' but does not explicitly state when to use this tool over alternatives or specify exclusions. There is no mention of conditions like 'use when exploring transfer options' or 'for club-side gaps, use get_club_squad_gaps instead.'
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, the description carries the full burden of behavioral disclosure. It reveals that the output is a time series with one point per date, but lacks details on date ranges, edge cases, or error behavior. For a simple read-only history tool, this is adequate 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 a single, focused sentence that front-loads the key output and use case with no wasted words. It is appropriately sized and clearly structured.
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 one-parameter tool with an output schema present, the description provides sufficient context for selection and invocation. It could mention the data format or prerequisites, but the overall context is complete enough.
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 has one parameter (player_id) with no description, and the description does not explicitly define it. However, the phrase 'A player's Elo...' implies that player_id identifies the player, offering minimal compensation for the 0% schema coverage.
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 returns a player's Elo and EAR over time, which distinguishes it from sibling tools that provide single-point data like value or style. It lacks an explicit verb such as 'get' or 'retrieve', but the intent is unambiguous from the context.
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 specifies the tool is 'useful for form/trend analysis and charts', giving clear context for when to use it. It does not mention alternatives or when not to use it, but the use case is well-defined.
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, the description carries the burden. It discloses the nature and structure of the output (per-90 output, process fingerprint) but does not mention any side effects, error behavior, or data limitations. It is a read-only operation by implication, but not explicitly stated.
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 concise phrase with no filler. Every word adds meaning, and it front-loads the core purpose before adding distinctive detail.
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 is a simple read with one parameter and an output schema, so the description does not need to explain return values. It provides sufficient high-level context for the profile's content, but could mention edge cases or prerequisites (e.g., player must exist).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It references the player implicitly ('A player's...'), giving context to the player_id parameter. However, it does not explain the parameter format or any constraints beyond the schema's integer type.
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 defines the tool as providing a player's playing-style profile, with specific content (per-90 output and multi-axis process fingerprint). It distinguishes from siblings like get_player by emphasizing 'how they play, not just how good they are'.
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 the appropriate use case: obtaining a player's style profile rather than general performance or value. The 'not just how good they are' phrase hints at when to choose this over get_player, though it does not explicitly name alternatives or exclusions.
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 disclosing behavioral traits. It mentions case-insensitivity, which is a useful behavioral detail, and lists the return fields. However, it does not explicitly state that the operation is read-only, or describe what happens when no matches are found or how the limit parameter affects results. Given the simplicity of a search tool, this is adequate but not rich.
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 very concise, consisting of two sentences. It front-loads the core action ('Find clubs by name') and then provides essential details about the return values and how to use them. No unnecessary words or repetition.
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 is simple, and the description covers the key purpose and return fields. An output schema exists, so detailed return value documentation is not the description's responsibility. However, it could have mentioned how the 'limit' parameter affects the result set, but given the schema default of 10 and the low complexity, the description is largely complete.
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 description explains the 'query' parameter indirectly by saying 'find clubs by name', which gives it meaning. However, the 'limit' parameter is not mentioned or explained in the description, and since schema description coverage is 0%, the description does not fully compensate for the lack of parameter documentation. The schema provides the default and type, but the description adds no additional context for limit.
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: finding clubs by name, with the specific detail of case-insensitivity. It also lists the returned fields (team_id, name, Elo, league, country), which distinguishes it from sibling search tools like search_players or search_coaches. The final instruction to use team_id with other club tools reinforces its role in the workflow.
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: when you need to find a club by name and obtain its team_id for further club-related operations. It also implicitly differentiates from get_club, which likely requires a known team_id. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a perfect score.
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 fully carries the transparency burden. It discloses the score range (0-100), the three blended components (tactical, financial, strategic), the per-signal breakdown, and the API key requirement. This gives a clear behavioral picture beyond the structured fields.
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 front-loads the primary output, enumerates the fit components, notes the per-signal breakdown, and states the access requirement. Every clause adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a composite scoring function with an output schema present, so the return format is covered by the schema. The description adds the score range, component definitions, and key-tier requirement. It does not explain error cases or edge conditions, but for selecting and invoking the tool, the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 mentions 'player → club move' but never explicitly explains the parameters 'player_id' or 'target_club_id', their source, or constraints. The prose only implies a relationship between IDs, leaving the agent to rely on parameter names and titles.
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 a specific verb ('get') and resource ('transfer-fit score'), and defines the scope as a player-to-club move with three named fit components. This distinguishes it from sibling tools like get_player_value or get_player_opportunities, which address different analyses.
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 when to use the tool: when a 0-100 transfer-fit score for a specific player-club pair is needed, and explicitly notes the prerequisite 'Ultra-tier key or higher'. It does not name alternative tools or exclusions, but the context is clear enough for an agent to select it over siblings.
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, the description carries the full behavioral disclosure burden. It adds pagination constraints (limit max 100, offset) and the active-only filter, but does not explain behavior for out-of-range offsets, ordering ties, or whether limit clamps. It is honest but minimal.
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 tightly written sentences deliver the core purpose and pagination details with zero filler. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with an output schema and only two parameters, the description covers essential context: ranking basis, active-player filter, and pagination semantics. Nothing critical is missing for the agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), so the description must compensate. It explains limit (maximum 100) and offset as pagination controls, which adds real meaning beyond the bare schema fields and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists the highest-rated players worldwide by current Elo, and specifies active players only. This distinguishes it from sibling tools like search_players (search by criteria) and get_player (individual lookup).
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 fetching global top player rankings, but it does not explicitly contrast with alternatives or state when not to use it. It mentions pagination, which is useful, but lacks explicit 'use this when...' guidance.
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 of behavioral disclosure. It mentions case-insensitivity, the return structure (coach_id, name, Elo, current club), and even notes that PlayerElo is the only public system rating coaches. However, it does not cover pagination, limit behavior, or potential error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose. Every sentence adds value, including the note about PlayerElo and the guidance to use coach_id with other coach tools. No redundant or vague phrasing.
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 search tool with an output schema, the description covers the essential return values and the next-step action. It is missing details about limit semantics and potential edge cases, but overall it provides enough context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly document either parameter. It implies that 'query' is the name to search, but 'limit' is entirely unmentioned. The description fails to compensate for the lack of parameter docs, though the parameter names are somewhat self-explanatory.
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 specifies the verb 'Find' and the resource 'coaches/managers' with a case-insensitive name search, distinguishing it from sibling tools like search_players. It also lists the key return fields, making the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: finding coaches by name and then using the returned coach_id with other coach tools. It does not explicitly state when not to use it or name alternatives, but the context is sufficient for an agent to select it appropriately.
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 that it returns the current record (not historical), lists the contained fields, and explicitly states the null-return behavior when no player matches the id. This is strong for a simple read-only lookup, though it doesn't discuss rate limits or auth, which are likely not applicable.
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 just two sentences: the first concisely states the purpose and fields, the second covers the null case. There is no filler or redundancy; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple one-parameter design, the presence of an output schema, and sibling context, the description is quite complete. It explains the scope ('current'), the fields, and the not-found behavior. It relies on the output schema for exact return formatting, which is appropriate. It never mentions alternatives, but that's more of a usage-guideline gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines player_id as an integer with no description. The description clarifies that this is the unique identifier for the player and that an unknown id yields null, adding meaning beyond the raw schema. For a single parameter, this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb phrase 'Full current record for one player by id' and enumerates the exact fields returned (name, age, position, club, league, Elo, EAR). This clearly distinguishes it from siblings like search_players (search by query), list_top_players (list), and get_player_history (historical data).
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: use this when you have a player_id and need their current full record. However, it does not explicitly state when to avoid it or mention alternatives like search_players for finding an ID first. There is no explicit exclusion or comparison with 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 provided, the description carries the full burden for behavioral disclosure. It transparently states the case-insensitive search behavior and the exact fields returned. It does not cover edge cases or the effect of the limit parameter, but for a simple search 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences that each add value: the core purpose, the return fields and how to use the ID, and a concrete example of the tool's typical use. No wasted words.
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 search tool with an output schema available, the description covers the essential behaviors and integration with other tools. It does not mention the `limit` parameter or behavior on no results, but the output schema likely covers return types. Overall, it is complete enough.
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 provides no descriptions (0% coverage), so the description must compensate. It explains that `query` is a player name, but does not explain `limit` at all. Since `limit` is optional with a default, the omission is less critical, but it still leaves a gap.
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: 'Find football players by name' with case-insensitivity. It distinguishes itself from sibling tools like search_coaches and search_clubs by explicitly focusing on players and mentioning the returned fields (player_id, name, Elo rating, etc.).
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: 'This is how you resolve a name like "Bellingham" to an id' and instructs to use the returned player_id with other player tools. However, it does not explicitly mention exclusions or alternatives like list_top_players, so it falls 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It adds the refresh rate ('signals refresh about every 10 minutes') and the meaning of 'current' signals, which is useful. However, it does not explicitly state that this is a read-only operation, nor does it mention any rate limits or pagination behavior. The presence of an output schema reduces the need to describe return values, but more behavioral context (e.g., what happens if since is stale) would improve 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 concise and front-loaded: the main purpose is stated in the opening clause, followed by optional filters and polling advice. All information is relevant and necessary, with no redundant phrases or filler. It fits in two sentences while covering all key aspects.
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 2-parameter tool with an output schema, the description covers all essential context: what the tool returns (value-bet signals), how to filter (strategy), how to poll for new picks (since), and how often data updates (10 minutes). The output schema handles return structure, so the description does not need to repeat that. This is complete for the tool's 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%, so the description must compensate. It fully explains both parameters: strategy with specific accepted values ('hs2_v6' = High Volume, 'hs1_v6' = Sweet Spot) and since with its purpose for incremental polling. This adds significant meaning beyond the raw schema types (integer/string), making it clear how and why each parameter should be used.
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: 'Current value-bet signals — where PlayerElo's fair odds diverge from the market price.' It identifies the specific resource (value-bet signals) and the scope (current, based on odds divergence). This distinguishes it from sibling tools that focus on players, coaches, clubs, and leagues.
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 guidance for both optional parameters: strategy ('hs2_v6' and 'hs1_v6') and since ('pass since=<the largest id from your previous call>'). It also explains the refresh cadence ('about every 10 minutes'), which informs when to poll. However, it does not explicitly mention when not to use this tool or suggest alternatives, though the sibling set is clearly different.
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 the transparency burden. It discloses the null return when no club has the given id, which is a key behavioral trait beyond the schema. It also specifies the record contents, providing useful context. Doesn't mention auth/rate limits, but these are less critical for a simple getter.
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 sentence that front-loads the core function, then lists fields and null behavior. No redundant wording, all information earns its place. Structurally efficient.
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 has an output schema, so return details are already structured. The description covers the essential: what it does, the parameter semantics, and the null edge case. Given the simple 1-parameter tool, no further context is needed for a complete understanding.
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?
Schema coverage is 0%, so the description must compensate. It does by explaining team_id is the club identifier and that a null return occurs for a non-existent id, giving meaning beyond the raw integer type. However, it doesn't mention any constraints like positive integer or that the id comes from search_clubs, which could be clearer.
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 a club's current record by team_id, listing specific fields (name, Elo, league, country, standout player). It distinguishes from siblings like search_clubs (by ID vs search) and get_club_squad_gaps (different data focus).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a team_id to look up a direct club record. It does not explicitly mention alternatives or when not to use, but the 'by team_id' context provides clear guidance. Missing explicit sibling differentiation keeps it from 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 provided, the description carries full transparency burden. It discloses the refresh interval (~10 minutes), the data source (confirmed lineups), and the conceptual approach (lineup-aware vs. team form). It does not detail rate limits, return shape, or edge cases, but for a simple read operation it gives sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each with a distinct purpose: sentence 1 defines the core output and refresh frequency, sentence 2 covers the optional filter and provides a key conceptual contrast. 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?
The description is complete for a single-parameter, read-only predictions tool: it covers what, when, source, refresh, filter, and conceptual distinction. An output schema exists to handle return values, so no description of the output is needed. The only minor gap is lack of explicit sibling alternatives, but that's already addressed in usage guidelines.
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 explicitly explains the sole 'league' parameter as an optional filter by name/code, which is not covered in the schema. This fully compensates for the 0% schema coverage for this parameter, though it omits example values or format hints.
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 provides win/draw/win probabilities for upcoming matches based on confirmed lineups, with a refresh cadence and optional league filter. This is a specific, actionable function that also distinguishes itself from form-based prediction tools.
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 for when the tool is relevant (upcoming matches, confirmed lineups, lineup-aware predictions) but does not explicitly name alternative tools or exclusion criteria. The 'not just team form' comment implies a distinction but doesn't offer direct sibling guidance.
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 burden of behavioral disclosure. It states the scope ('All competitions PlayerElo covers'), the fields returned (id, name, country), and its relationship to get_league_ranking. It does not mention pagination or auth, but for a simple zero-parameter list tool these are likely unnecessary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the tool's output and scope, the second gives a cross-reference to get_league_ranking. Every word earns its place; there is no redundancy or 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 output schema exists and the tool has zero parameters, the description sufficiently covers the purpose, output fields, and usage context. It also connects to a dependent tool, making it complete for this simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The mention of 'league_id' is for the sibling tool, not this one. Baseline 4 applies for no parameters.
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 identifies the tool's purpose: it lists all competitions covered by PlayerElo, with each league's id, name, and country. This is a specific verb+resource statement that distinguishes it from sibling tools like get_league_ranking, which consumes the league_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?
The description provides an explicit usage instruction: 'Use a league_id with get_league_ranking.' This tells the agent how to use the output and positions this tool as a prerequisite. It doesn't explicitly say when to use this tool vs alternatives, but no alternatives exist for listing leagues.
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 the responsibility for behavioral disclosure. It explicitly states it returns null for an unknown id and identifies the record fields, but does not mention other traits like read-only status or rate limits, which are largely implicit for a get operation.
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 with no wasted words. The main purpose is front-loaded, followed by the return fields and the edge-case behavior. The example is efficiently integrated.
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 simple with one parameter and an output schema, so the description needs no return-value detail. It fully covers what the tool does, what the parameter means, and a key edge case (null return), making it complete for an agent to invoke 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 input schema only lists coach_id with a type, but the description gives an example ('coach_4') and clarifies that the parameter is the lookup key. This adds crucial semantic meaning beyond the schema, which has 0% description 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 uses a specific verb ('get') and resource ('coach'), clearly stating it fetches a full record by id. It lists the returned fields and distinguishes from search-like siblings by explicitly requiring an id, making the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the coach_id is known and a full record is needed, with an example of id format. It does not explicitly name alternatives like search_coaches for finding an id, but the 'by id' phrasing provides clear context without exclusions.
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:

[![playerelo-mcp MCP server](https://glama.ai/mcp/servers/mwolters-cmyk/playerelo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mwolters-cmyk/playerelo-mcp)

Score Badge

Copy to your README.md:

[![playerelo-mcp MCP server](https://glama.ai/mcp/servers/mwolters-cmyk/playerelo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mwolters-cmyk/playerelo-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mwolters-cmyk/playerelo-mcp'

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