OpenDota MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting different resources (heroes, matches, players, teams, pro scene). However, some player-focused tools like get_player_heroes and get_player_rankings could potentially overlap in retrieving hero-related player data, though descriptions clarify their specific focuses.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with get_ prefix and snake_case throughout. The naming is highly predictable and readable, making it easy to understand each tool's function at a glance.
Tool Count4/5
17 tools is slightly high but reasonable for a comprehensive Dota 2 statistics server. The count supports detailed player analysis, match data, hero stats, and professional scene coverage without being overwhelming for the domain scope.
Completeness5/5
The toolset provides excellent coverage of the OpenDota API domain with comprehensive player analysis (stats, matches, heroes, peers, rankings), match data (public, pro, detailed), hero statistics, team info, and search functionality. No obvious gaps exist for typical agent workflows.
Average 3.2/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does without disclosing behavioral traits such as whether it's a read-only operation, potential rate limits, authentication needs, or error handling. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the main purpose, followed by brief sections for args and returns. It avoids unnecessary details, but the structure is basic and could be more polished (e.g., using bullet points or clearer formatting).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which should cover return values), the description doesn't need to explain returns in detail. However, with no annotations and minimal parameter guidance, it's incomplete for effective use, as it lacks context on usage scenarios and behavioral aspects.
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 adds minimal semantics by specifying that 'account_id' is the 'Steam32 account ID of the player', which clarifies the parameter's purpose beyond the schema's title 'Account Id'. However, with 0% schema description coverage and only one parameter, this provides some value but doesn't fully compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Get player hero rankings' which specifies the verb 'Get' and resource 'player hero rankings', but it's somewhat vague about what 'hero rankings' entails (e.g., rankings based on performance, win rate, etc.). It doesn't clearly distinguish from siblings like 'get_player_heroes' or 'get_hero_stats', which might overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't specify if this is for a specific player's hero performance rankings compared to other tools that might list heroes or general stats, leaving the agent to guess based on sibling names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('Get information') without detailing whether this is a read-only operation, if it requires authentication, rate limits, error conditions, or what the return format entails. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief and structured with clear sections for Args and Returns. However, the 'Returns' section is overly vague ('Team information'), and the overall content could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema, the description is minimally complete. However, it lacks details on behavioral aspects (like safety or constraints) and doesn't leverage the output schema to clarify return values, leaving gaps in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics: it names the parameter ('team_id') and implies it's required, but provides no details on format, constraints, or examples. With 0% schema description coverage, this doesn't fully compensate, but it at least identifies the parameter, meeting the baseline for minimal documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get information about a team' which provides a basic verb+resource combination, but it's vague about what specific information is retrieved. It doesn't distinguish this tool from potential sibling tools like 'get_player_by_id' or 'get_pro_teams' (if they existed), leaving ambiguity about scope and differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a valid team_id), exclusions, or how it relates to sibling tools like 'get_player_by_id' or 'get_pro_players', leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns 'List of all heroes with basic information', which implies read-only behavior, but lacks details on rate limits, authentication needs, pagination, or what 'basic information' entails. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one stating the purpose and one describing the return. It's front-loaded with the main action, but could be slightly more structured (e.g., clarifying 'basic information').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, output schema exists), the description is somewhat complete but lacks behavioral context. With no annotations and an output schema, it should ideally explain more about the return format or usage constraints, but it's minimally adequate.
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 0 parameters, and schema description coverage is 100%. The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get list of all Dota 2 heroes' with a specific verb ('Get') and resource ('Dota 2 heroes'). It distinguishes from siblings like get_hero_stats (statistics) and get_match_heroes (match-specific heroes), but doesn't explicitly differentiate them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention when to choose get_heroes over get_hero_stats (for detailed stats) or get_match_heroes (for heroes in a match), nor does it provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, data freshness, or error handling. For a tool that likely involves data retrieval, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose, followed by structured 'Args' and 'Returns' sections. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values in detail, and it appropriately summarizes them. However, with no annotations and low schema coverage, it should provide more context on usage and behavior to be fully complete for a data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'hero_id' is optional and for getting stats for a specific hero, which clarifies beyond the schema's title 'Hero Id'. However, it doesn't detail format constraints or examples, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get statistics for heroes.' It specifies the resource (heroes) and the action (get statistics), which is straightforward. However, it doesn't differentiate from sibling tools like 'get_heroes' or 'get_player_heroes', which might also retrieve hero-related data, so it lacks sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions an optional 'hero_id' parameter but doesn't explain when to include it or how it affects the output compared to other tools like 'get_heroes'. There's no context on prerequisites or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't address critical aspects like rate limits, authentication needs, data freshness, or what constitutes 'chat' (e.g., in-game, post-match). The return format is mentioned but lacks detail on structure or limitations.
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 efficiently structured with a clear purpose statement followed by labeled 'Args' and 'Returns' sections. It avoids unnecessary words, though the 'Args' and 'Returns' labels are slightly redundant given the structured schema fields. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (retrieving processed chat data), no annotations, and an output schema (implied by 'Has output schema: true'), the description is minimally adequate. It covers the purpose and parameter semantics but lacks behavioral context and usage guidelines. The output schema likely handles return values, reducing the burden on the description.
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 the single parameter: 'account_id: Steam32 account ID of the player.' The input schema has 0% description coverage (only title 'Account Id' and type 'integer'), so this clarification is essential. It specifies the ID format ('Steam32') and links it to the player, compensating well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get most common words used by player in chat.' It specifies the verb ('Get'), resource ('most common words'), and scope ('by player in chat'). However, it doesn't explicitly differentiate from sibling tools like 'get_player_recent_matches' or 'get_player_totals' beyond the wordcloud focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the player must have chat history), exclusions, or comparisons to sibling tools like 'search_player' or 'get_player_by_id' that might provide overlapping or complementary data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions retrieving 'recent public matches' but doesn't specify what 'recent' means (e.g., time range), whether there are rate limits, authentication requirements, or pagination behavior. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, using clear sections for 'Args' and 'Returns' without unnecessary details. Each sentence serves a purpose, making it easy to parse. A minor deduction for not front-loading all critical information (e.g., the default value is in the Args section rather than the main description).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no nested objects) and the presence of an output schema (which handles return values), the description is somewhat complete. However, it lacks behavioral details (e.g., what defines 'recent,' rate limits) and usage guidelines, making it adequate but with clear gaps for effective agent use.
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 the single parameter 'limit' by explaining it as 'Number of matches to retrieve (default: 5),' which clarifies its purpose beyond the schema's basic type and default. With 0% schema description coverage and only one parameter, this compensation is effective, though not exhaustive (e.g., no range constraints).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get recent public matches.' It specifies the verb ('Get') and resource ('recent public matches'), making it easy to understand what the tool does. However, it doesn't differentiate from sibling tools like 'get_pro_matches' or 'get_player_recent_matches,' which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_pro_matches' (for professional matches) or 'get_player_recent_matches' (for player-specific matches), leaving the agent without context for selection. This lack of comparative usage information results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('Search for players by name') and return type ('List of matching players'), but lacks critical details like search algorithm (exact match, partial, fuzzy), result limits, pagination, error handling, or performance characteristics. This is inadequate for a search tool with zero annotation coverage.
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 extremely concise and well-structured: a clear purpose statement followed by separate Args and Returns sections. Every sentence earns its place with no redundant information. The formatting with headings enhances readability without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search functionality with 1 parameter), no annotations, but with an output schema (which handles return values), the description is minimally complete. It covers the basic purpose and parameter but lacks behavioral context and usage guidelines. The output schema relieves the description from explaining return structure, but more operational details would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It documents the single parameter 'query' as 'Name to search for', which adds basic meaning beyond the schema's generic 'Query' title. However, it doesn't provide format details (e.g., case sensitivity, special characters) or examples, leaving significant gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Search for players by name', which is a specific verb+resource combination. It distinguishes itself from siblings like get_player_by_id (which retrieves by ID) and get_player_rankings (which provides rankings). However, it doesn't explicitly differentiate from get_pro_players, which might also search for players but with a professional filter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose search_player over get_player_by_id for known IDs, or how it differs from get_pro_players for professional players. There's no context about search scope, limitations, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but doesn't cover critical aspects like rate limits, authentication needs, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational 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 concise, with three sentences that efficiently cover purpose, arguments, and returns. Each sentence adds value: the first states the core function, the second explains the parameter, and the third outlines the response. There's no wasted text, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema, the description is moderately complete. It covers the basic purpose and parameter semantics adequately. However, with no annotations and multiple sibling tools, it lacks usage guidelines and behavioral details, which could hinder effective tool selection and invocation in a broader context.
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 beyond the input schema, which has 0% description coverage. It specifies that 'account_id' is 'The player's Steam32 account ID,' clarifying the parameter's purpose and format. This compensates well for the schema's lack of descriptions, though it doesn't detail constraints like valid ID ranges or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a player's information by their account ID.' It specifies the verb ('Get') and resource ('player's information'), and distinguishes it from siblings like get_player_heroes or get_player_recent_matches by focusing on basic player data. However, it doesn't explicitly differentiate from get_player_rankings or get_player_totals, which might overlap in scope, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid account ID, or compare it to siblings like search_player for unknown IDs or get_player_recent_matches for recent activity. Without such context, users might struggle to choose the right tool among the many player-related options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'Get's data, implying a read-only operation, but doesn't cover other aspects like rate limits, authentication needs, error handling, or data freshness. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded. It starts with a clear purpose statement, followed by brief sections for 'Args' and 'Returns', with no wasted words. Every sentence adds value, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with 1 parameter), the description is somewhat complete but has gaps. It explains the parameter and return value at a high level, and an output schema exists, so detailed return explanations aren't needed. However, with no annotations, it lacks behavioral context like error cases or performance hints, making it adequate but not fully comprehensive.
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 beyond the input schema. The schema has 0% description coverage, only specifying 'account_id' as an integer. The description explains that this is a 'Steam32 account ID of the player', clarifying the parameter's purpose and format, which compensates well for the low 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's purpose: 'Get player's overall stats totals.' It specifies the verb ('Get') and resource ('player's overall stats totals'), making it easy to understand what the tool does. However, it doesn't explicitly distinguish this from sibling tools like 'get_player_win_loss' or 'get_player_rankings', which might also provide player statistics, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as how it differs from 'get_player_heroes' or 'get_player_recent_matches'. This lack of usage instructions leaves the agent to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves statistics, implying a read-only operation, but doesn't cover important aspects like rate limits, authentication needs, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded, with the core purpose stated first, followed by brief sections for arguments and returns. Every sentence earns its place without redundancy, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks depth. It covers the basic purpose and parameter semantics but misses behavioral details and usage guidelines, leaving room for improvement in guiding the agent effectively.
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 the single parameter 'account_id' by specifying it as the 'Steam32 account ID of the player,' which clarifies its purpose beyond the schema's basic 'integer' type. With 0% schema description coverage, this compensates well, though it doesn't detail format constraints like valid ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get win/loss statistics for a player.' It specifies the verb ('Get') and resource ('win/loss statistics'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'get_player_totals' or 'get_player_rankings', which might also provide statistical data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for specific game modes or time periods. With siblings like 'get_player_totals' and 'get_player_rankings' available, this lack of differentiation leaves usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify any behavioral traits like rate limits, authentication needs, or data freshness. The description lacks details on what 'recent' means or any constraints beyond the limit parameter.
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 concise, with a clear purpose statement followed by brief sections for Args and Returns. Every sentence earns its place, and there is no unnecessary information, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema (which handles return values), the description is adequate but has gaps. It covers the basic purpose and parameter semantics but lacks usage guidelines and behavioral details, making it minimally viable but not fully comprehensive for an agent.
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 the single parameter: it explains that 'limit' is the 'Number of matches to retrieve' and provides a default value (5). Since schema description coverage is 0%, the description compensates by clarifying the parameter's purpose, which is valuable beyond the basic schema type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get recent professional matches.' This specifies the verb ('Get') and resource ('recent professional matches'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'get_public_matches' or 'get_match_data', which might also retrieve match-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_public_matches' or 'get_match_data', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions a default limit and return type, but lacks details on permissions, rate limits, pagination, or data freshness. For a read operation with no annotation coverage, this is insufficient 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 well-structured and front-loaded, with a clear purpose statement followed by concise sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and the presence of an output schema, the description is minimally adequate. However, without annotations and with siblings that overlap in domain, it lacks context on differentiation and behavioral traits, leaving gaps in completeness.
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 semantics beyond the input schema: it explains that 'limit' is 'Number of players to retrieve' with a default of 10. With 0% schema description coverage and only one parameter, this effectively compensates, though it doesn't cover edge cases like maximum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get list of professional players.' It specifies the verb ('Get') and resource ('professional players'), making the intent unambiguous. However, it doesn't differentiate from sibling tools like 'get_player_by_id' or 'get_pro_matches', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_player_by_id' for specific players and 'get_pro_matches' for matches, there's no indication of context, prerequisites, or exclusions, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data, implying a read-only operation, but does not disclose any behavioral traits such as rate limits, authentication needs, error handling, or whether it's idempotent. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, with a clear purpose statement followed by brief sections for arguments and returns. Every sentence earns its place by adding value, and it is front-loaded with the main functionality, making it efficient and easy to parse.
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 low complexity (one parameter) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose and parameter semantics adequately. However, it lacks behavioral context and usage guidelines, which slightly reduces completeness for an agent needing full operational 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?
The description adds meaningful context for the single parameter 'match_id' by specifying it as 'ID of the match to retrieve', which clarifies its purpose beyond the schema's basic type information. Since there is only one parameter and schema description coverage is 0%, the description effectively compensates by providing essential semantics, earning a high score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('detailed data for a specific match'), making it easy to understand what it does. However, it does not explicitly differentiate from sibling tools like 'get_pro_matches' or 'get_public_matches', which might also retrieve match data but with different scopes or filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or exclusions, such as whether it's for professional matches only or how it differs from sibling tools like 'get_pro_matches' or 'get_public_matches'. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get heroes'), implying a read-only operation, but doesn't cover aspects like error handling, rate limits, authentication needs, or data freshness. This leaves significant gaps for a tool that likely queries a match database.
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 with the core purpose, followed by clear sections for Args and Returns. Every sentence adds value without redundancy, making it efficient and easy to parse for an AI 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?
Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is largely complete. It covers the purpose and parameter semantics adequately. However, the lack of usage guidelines and behavioral details (e.g., error cases) prevents a perfect score, as these are important for reliable tool invocation.
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 the single parameter 'match_id' by specifying it as 'ID of the match to retrieve', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensation is effective, though it doesn't detail format constraints (e.g., valid ID ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('heroes played in a specific match'), making it easy to understand what it does. However, it doesn't explicitly distinguish this from sibling tools like 'get_match_data' or 'get_player_heroes', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'get_match_data' and 'get_player_heroes' available, there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't specify any behavioral traits like rate limits, authentication needs, or data freshness. The mention of 'default: 5' for the limit parameter adds some context, but overall, it lacks details on how the tool behaves beyond basic functionality.
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 appropriately sized and front-loaded, starting with the core purpose followed by structured sections for 'Args' and 'Returns.' Every sentence earns its place by providing essential information without redundancy, making it efficient and 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 the tool's moderate complexity (2 parameters, no annotations, but with an output schema), the description is fairly complete. It covers the purpose, parameters, and return value ('List of most played heroes with stats'), and the output schema likely handles return details. However, it lacks usage guidelines and deeper behavioral context, which holds it back from a perfect score.
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 semantics beyond the input schema, which has 0% description coverage. It explains that 'account_id' is a 'Steam32 account ID of the player' and 'limit' is the 'Number of heroes to retrieve (default: 5),' clarifying the purpose and default value. This compensates well for the low schema coverage, though it doesn't detail constraints like valid ranges for 'limit.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a player's most played heroes.' It specifies the verb ('Get') and resource ('player's most played heroes'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from siblings like 'get_player_totals' or 'get_player_recent_matches,' which might also involve player data, so it lacks sibling differentiation for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions, such as how it differs from 'get_hero_stats' or 'get_player_totals.' Without this, users must infer usage from the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves a list of 'frequently played with' players, hinting at aggregation logic, but lacks details on data freshness, rate limits, authentication needs, error handling, or pagination. The description is minimal and misses key operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by structured Args and Returns sections. Each sentence earns its place by defining functionality, parameters, and output without redundancy. It is appropriately sized for a simple lookup tool, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which covers return values), the description is moderately complete. It explains the basic operation and parameters but lacks behavioral context (e.g., how 'frequently played with' is determined). With no annotations, it should do more to guide safe usage.
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 description coverage is 0%, so the description must compensate. It adds meaningful semantics: account_id is explained as 'Steam32 account ID of the player', and limit specifies 'Number of peers to retrieve' with a default value. This clarifies parameter purposes beyond the schema's basic titles, though it could detail format constraints (e.g., integer range 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 with a specific verb ('Get') and resource ('players who have played with the specified player'), distinguishing it from siblings like get_player_by_id (which retrieves a single player's data) or get_player_recent_matches (which focuses on match history). It precisely identifies the target resource and relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid account_id), exclusions, or comparisons to similar tools like get_player_recent_matches (which might include peer data indirectly) or search_player (for finding players by name). Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return type ('List of recent matches with details') but doesn't disclose behavioral traits like rate limits, authentication needs, data freshness, error conditions, or pagination behavior for the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by well-organized Arg and Return sections. Every sentence earns its place, and information is front-loaded appropriately.
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 simple 2-parameter tool with an output schema (which handles return value documentation), the description is reasonably complete. It covers purpose and parameters adequately, though could benefit from more behavioral context given the lack of annotations.
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?
With 0% schema description coverage, the description compensates well by explaining both parameters: 'account_id' as the Steam32 account ID and 'limit' as the number of matches with a default value. This adds crucial 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 specific action ('Get recent matches played by a player'), identifies the resource ('matches'), and distinguishes from siblings by focusing on recent matches for a specific player rather than general match data, hero stats, or other player metrics.
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 when needing recent matches for a specific player, but doesn't explicitly state when to use this vs. alternatives like 'get_match_data' (for specific match details) or 'get_player_totals' (for aggregated stats). No exclusions or prerequisites are mentioned.
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:

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

Score Badge

Copy to your README.md:

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

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/asusevski/opendota-mcp-server'

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