Allows accessing OpenDota API data to retrieve real-time Dota 2 statistics, match data, player information, hero statistics, professional players and teams information.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@OpenDota MCP Server show me the recent matches for player ID 8674590"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server implementation for accessing OpenDota API data. This server enables LLMs and AI assistants to retrieve real-time Dota 2 statistics, match data, player information, and more through a standard interface.
Access player profiles, statistics, and match history
Retrieve detailed match information
Look up professional players and teams
Get hero statistics and rankings
Search for players by name
And more!
Related MCP server: MonkeyType MCP Server
To install OpenDota API Server for Claude Desktop automatically via Smithery:
npx -y @smithery/cli install @asusevski/opendota-mcp-server --client claude# Clone the repository
git clone https://github.com/asusevski/opendota-mcp-server.git
cd opendota-mcp-server
# Option 1: Automated setup (works with bash, zsh, and other shells)
./scripts/setup_env.sh
# Option 2: Manual installation with uv
uv add pyproject.toml
# For development dependencies
uv pip install -e ".[dev]"(Optional but recommended) Create an OpenDota API key at https://www.opendota.com/api-keys
Set your API key as an environment variable:
export OPENDOTA_API_KEY=your_api_key_herepython -m src.opendota_server.serverFollow this: https://modelcontextprotocol.io/quickstart/user
If you use WSL, assuming you have cloned the repo and set up the python environment, this is how I wrote the claude_desktop_config.json:
{
"mcpServers": {
"opendota": {
"command": "wsl.exe",
"args": [
"--",
"bash",
"-c",
"cd ~/opendota-mcp-server && source .venv/bin/activate && python src/opendota_server/server.py"
]
}
}
}python -m src.clientget_player_by_id - Retrieve player information by account ID
get_player_recent_matches - Get recent matches for a player
get_match_data - Get detailed data for a specific match
get_player_win_loss - Get win/loss statistics for a player
get_player_heroes - Get a player's most played heroes
get_hero_stats - Get statistics for heroes
search_player - Search for players by name
get_pro_players - Get list of professional players
get_pro_matches - Get recent professional matches
get_player_peers - Get players who have played with a specified player
get_heroes - Get list of all Dota 2 heroes
get_player_totals - Get player's overall stats totals
get_player_rankings - Get player hero rankings
get_player_wordcloud - Get most common words used by player in chat
get_team_info - Get information about a team
get_public_matches - Get recent public matches
get_match_heroes - Get heroes played in a specific match
MIT
Get list of all Dota 2 heroes.
Returns:
List of all heroes with basic information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get statistics for heroes.
Args:
hero_id: Optional hero ID to get stats for a specific hero
Returns:
Hero statistics including win rates by skill bracket
| Name | Required | Description | Default |
|---|---|---|---|
| hero_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get detailed data for a specific match.
Args:
match_id: ID of the match to retrieve
Returns:
Detailed match information including players, scores, and stats
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get heroes played in a specific match.
Args:
match_id: ID of the match to retrieve
Returns:
List of heroes played by each player in the match
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a player's information by their account ID.
Args:
account_id: The player's Steam32 account ID
Returns:
Player information including rank, matches, and statistics
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get a player's most played heroes.
Args:
account_id: Steam32 account ID of the player
limit: Number of heroes to retrieve (default: 5)
Returns:
List of most played heroes with stats
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get players who have played with the specified player.
Args:
account_id: Steam32 account ID of the player
limit: Number of peers to retrieve (default: 5)
Returns:
List of players frequently played with
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get player hero rankings.
Args:
account_id: Steam32 account ID of the player
Returns:
Player's hero rankings
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get recent matches played by a player.
Args:
account_id: Steam32 account ID of the player
limit: Number of matches to retrieve (default: 5)
Returns:
List of recent matches with details
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get player's overall stats totals.
Args:
account_id: Steam32 account ID of the player
Returns:
Summary of player's total stats
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get win/loss statistics for a player.
Args:
account_id: Steam32 account ID of the player
Returns:
Win/loss record
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get most common words used by player in chat.
Args:
account_id: Steam32 account ID of the player
Returns:
List of player's most frequently used words
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get recent professional matches.
Args:
limit: Number of matches to retrieve (default: 5)
Returns:
List of recent professional matches
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get list of professional players.
Args:
limit: Number of players to retrieve (default: 10)
Returns:
List of professional players
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get recent public matches.
Args:
limit: Number of matches to retrieve (default: 5)
Returns:
List of recent public matches
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Get information about a team.
Args:
team_id: Team ID
Returns:
Team information
| Name | Required | Description | Default |
|---|---|---|---|
| team_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Search for players by name.
Args:
query: Name to search for
Returns:
List of matching players
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for Studex tools, notifications, and profile integrations
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
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