opendota-mcp
Server Quality Checklist
Latest release: v0.2.1
- Disambiguation4/5
Tools are clearly organized by primary entity (player, hero, team, league, match) and most have a singular purpose; similarly named tools like get_player_matches and get_player_recent_matches are distinguishable by their descriptions. A few player-stat tools (totals, counts, histogram, heroes) overlap in subject but differ in output shape, so some care is still needed.
Naming Consistency5/5Nearly all tools follow a consistent get_<resource>_<detail> snake_case pattern, such as get_player_matches, get_team_heroes, and get_hero_matchups. Action verbs like request, refresh, search, and list are used only where appropriate, with no style mixing or vague naming.
Tool Count2/542 tools is a very large surface for an MCP server and exceeds the comfortable range, making agent selection harder even though the tools are well-named. Many related stat tools could be consolidated into fewer parameterized tools without losing functionality.
Completeness4/5The set covers core read-only Dota 2 workflows well: player history and stats, hero matchups and benchmarks, teams, leagues, pro matches, match parsing, constants, and name resolution. A few niche OpenDota endpoints such as player ability/item usage are missing, but there are no obvious workflow dead-ends.
Average 3.6/5 across 42 of 42 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 56 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.jsonto 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?
With no annotations, the description must carry the burden of disclosing behavior. It reveals the return format (field/sum pairs) but omits important behavioral details such as how filters affect the aggregation, whether results include all game modes by default, pagination behavior, or any response limitations. This is insufficient for a tool with 19 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is also minimal to the point of under-specification. It front-loads the core concept but lacks supporting context (e.g., output shape details, filtering caveats) that would make it structurally complete for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (19 parameters, no output schema, no annotations), the description is far from complete. It mentions the return format vaguely but does not clarify how the many filter parameters interact, what the default behavior is, or what an agent should expect in the response. This is a significant gap 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter already has a meaningful description in the schema. The tool description adds no parameter-specific semantics beyond implying that filters will refine the aggregate totals. Baseline 3 is appropriate because the schema carries the full explanatory weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific resource (lifetime aggregate totals for a player) and a clear verb (get, implied), and enumerates concrete fields (kills, deaths, assists, etc.). It distinguishes the tool from sibling tools like get_player_counts or get_player_histogram by stating the result is field/sum pairs, though it doesn't explicitly name an alternative or exclusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description only states what the tool returns, with no mention of typical scenarios, prerequisites, or conditions that would make it preferable to similar player-stat tools like get_player_heroes or get_player_win_loss.
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 present, so the description carries the full burden of behavioral disclosure. It does not mention sorting, pagination, freshness of 'recent', or whether authentication is required. The only behavioral hint is 'recently', which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core information (players, hero, recency) and lists the returned fields. It is efficient, but omits a clear action verb and any contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, an agent would not know the exact return format, sorting, or limits. The description gives field names but lacks critical details about 'recent' semantics and how to interpret win rates. It is minimally viable for a simple tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes hero_id with guidance to resolve names via search_dota_entities. The description itself adds no parameter information, but since schema coverage is 100% and the parameter is well-documented, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: players who have played a hero recently, along with account id, name, games, wins, and win rates. This distinguishes it from sibling tools oriented around matches or player-specific stats, though it lacks an explicit verb like 'get' or 'list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_hero_recent_matches or get_player_heroes. It only describes the output content, leaving the agent to infer the appropriate context from the name.
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?
Since no annotations are provided, the description must carry the full behavioral burden. It only tells what data is returned, without mentioning that the call is read-only, any authentication requirements, rate limits, or other side effects. The phrase 'top-100 percentile scores' gives information but not operational transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the primary purpose. There is no filler, though 'with hero names' is somewhat redundant because leaderboard rankings typically imply context. Overall, it is well-structured for at-a-glance comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the result structure. It does indicate the presence of hero names and percentile scores, but it does not hint at ordering, result length, or pagination. This leaves some ambiguity, though the simple significance of the tool is understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions for account_id and language are complete and detailed (including how to derive the ID and accepted language codes). The tool description adds no parameter-specific insight beyond the schema coverage, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('hero leaderboard rankings') and the returned data ('top-100 percentile scores per hero'). It uses a player context that aligns with the required account_id, but it does not explicitly distinguish itself from siblings like get_hero_rankings or get_player_heroes, leaving that inference to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over its many alternatives. There are no stated conditions, exclusions, or mentions of global-versus-per-player scenarios, leaving the agent to rely on the tool name and schema.
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?
There are no annotations, so the description bears the full burden of explaining behavior. It only enumerates output fields and does not disclose ordering, default limits, read-only safety, or how peers are defined. This lack of behavioral detail could mislead an agent about result sorting or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short, front-loaded phrase that wastes no words and conveys the core output. Though not a full sentence, it is efficient and easy to parse, with all key information presented first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately lists return fields and scope, but it omits ordering, default result count, and the meaning of 'played with most' (e.g., sorted by games together). For a simple list endpoint this is workable, but richer context would improve call correctness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema documentation covers 100% of the parameters (account_id and limit), so the description adds little beyond schema. The schema already explains account_id as a Steam32 id and limit as max results, satisfying the baseline for parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies the resource ('players this player has played with most') and lists the output fields (names, games together, wins, win rate), making the tool's purpose understandable. It does not explicitly contrast with sibling tools, but the wording is specific enough to distinguish from player stats endpoints like get_player_heroes or get_player_totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention use cases, exclusions, or relationships to sibling tools such as get_player_pros or get_player_hero_rankings, leaving the agent to infer applicability.
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 present, so the description bears full responsibility for behavioral disclosure. It mentions team affiliations as part of the output but doesn't state whether results are ordered, paginated, or limited by the limit parameter. No side effects or special behavior are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff. Every word contributes to the core meaning. It's short but not under-specified to the point of being unusable, though additional detail would be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description doesn't explain return format, result structure, or how the limit parameter affects results. For a simple list endpoint, baseline information exists but lacks context about data shape and usage scenarios, making it incomplete for an agent to fully anticipate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already well-documented in the schema. The description adds no extra semantic meaning beyond what the schema provides, but the schema itself is sufficient. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource ('professional players') and the relationship ('played with or against'), which clearly differentiates from many siblings like get_player_matches or get_player_ues. However, it lacks an explicit verb like 'list' or 'retrieve', so it's somewhat implicit but still clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_player_peers or get_pro_players. The description doesn't mention any usage context, prerequisites, 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, the description carries the full burden. It reveals what data is returned (games, wins, win rates) but hides behavioral details such as sorting, pagination, rate limits, or whether the response includes only current roster players. The mutation/read intent is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence efficiently conveys the core purpose. It is front-loaded and free of redundancy, though it is a sentence fragment and could benefit from a verb like 'Gets' for grammatical completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It does not mention return format, ordering, or any limitations (e.g., date range, team roster scope). The rich schema helps with parameters but the overall call behavior remains underexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters (team_id and language) with 100% coverage. The description's mention of 'pro team' reinforces team_id semantics but adds no new meaning about language, defaults, or value formats that the schema doesn't already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (plays) and resource (pro team's heroes) and conveys that it returns hero statistics for a team, distinguishing it from player- or hero-centric tools. It is clear but does not explicitly name siblings or contrast with them, so it misses full 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_team_matches or get_hero_stats. The description implies a use case (team hero analysis) but provides no explicit conditions, exclusions, or alternative routing.
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, leaving the description to carry the full burden of behavioral disclosure. The description only states the output is 'recent matches, enriched with hero names...' but does not mention pagination, rate limits, authentication, result limits beyond the schema, or how errors are handled. For a read-only list tool, this is minimal but not dangerously misleading; it simply omits additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that immediately states the tool's purpose and key enriching features. Every word serves to clarify the tool's scope. It is appropriately sized and avoids redundancy, earning the maximum score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lightly describes the output as 'matches enriched with hero names and game mode labels', but it omits essential details like the exact structure of each match, supported date ranges, default limits, or any response examples. Given the tool's moderate complexity and lack of output schema, this description is insufficient to fully enable an agent to call and interpret the result without guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description coverage is 100%, so all parameters are already documented with their meaning. The description adds minimal extra value: it ties language to hero name localization (which the schema also mentions) and clarifies the output's enriched nature, but does not enrich the parameters themselves beyond what is already in the schema. The baseline score of 3 is appropriate because the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a pro team's recent matches, with a specific focus on enriched data (hero names and game mode labels). This distinguishes it from sibling tools like get_team (which returns team info) or get_player_recent_matches (which is player-centric). It could be more explicit about differentiating from get_pro_matches, but the 'team' qualifier is present and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a team's match history, but it provides no explicit direction on when to choose it over alternatives like get_league_matches or get_pro_matches. There is no mention of scenarios where this tool is preferable or exclusions. The guidance is only implicit in the title and one-line description, so it fails to fully inform 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, the description carries the full burden. It lists output fields but omits behavioral traits such as pagination, filtering behavior, whether historical players are included, or any authentication requirements. For a data-returning tool, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that conveys the essence without unnecessary words. It is front-loaded with the main purpose and key fields, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool, the description and schema give a workable picture. However, the absence of an output schema and lack of detail about the response structure (e.g., exact field names, ordering) leaves some uncertainty, though not enough to prevent basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the sole parameter (team_id) thoroughly, specifying its source and constraints. The tool description adds no additional parameter meaning, but the schema already provides full coverage, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (team players) and key output fields (games played, wins, current-member flag), making it clearly distinct from sibling tools like get_team_matches or get_team_heroes. It lacks a strong verb but is still unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, and no exclusions are mentioned. The description implies a lookup use case but does not articulate scenarios or differentiate from related player/team tools.
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 return contains leaderboard scores and ranks, which hints at the output shape, but the description does not disclose any behavior such as ordering direction, result limits, pagination, or dependencies on search_dota_entities for name resolution. The disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that puts the main purpose first and adds a clarifying parenthetical about the returned scores and ranks. No word is wasted; it is fully efficiently structured, with only a slightly below-perfect score because the parenthetical includes an unnecessary comma.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (1 param, no nested structures) and that the schema fully documents the only param, the description is reasonably complete: it covers the resource (hero), the scope (global top players), and the output (leaderboard scores and ranks). Minor lack is any mention of ordering or limit, but for a simple leaderboard query these are predictable to most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter, hero_id, already carries a rich description including usage example and a link to search_dota_entities for name resolution. The main description adds no parameter information, so the baseline score of 3 is appropriate because the schema fully manages the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-object: global top players on a hero, with the parenthetical clarifying the resource is a leaderboard of scores and ranks. This makes the purpose understandable, though it does not explicitly contrast with the closely-named sibling get_player_hero_rankings, leaving the agent to infer the difference from the 'global' prefix and the sibling name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as get_player_hero_rankings or get_hero_players. The 'global' framing implies this is for the world-wide leaderboard of the hero, but this is left to inference; there is no explicit when, when-not, or named alternative.
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 must carry the burden. It labels the result 'enriched' but does not explain what enrichment means (e.g., hero/player names resolved, item names), how many matches are returned, pagination, or any rate-limit/authorization concerns. For a list-fetch tool backed by an external Dota API service, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence plus a prerequisite pointer; it is easy to scan and front-loads the resource before the guidance. Minor gap: it could mention the optional 'language' parameter's effect on enriched fields, but it is not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and a fully described schema, the description is almost complete for invocation. However, the word 'enriched' creates expectations about the return payload that the description never clarifies, and with no output schema and no annotations, an agent cannot predict what data fields come back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters well. The description adds no new semantics beyond 'league_id' being required, which the schema already states. Baseline 3 is appropriate because the structured schema carries the weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description says it returns 'Matches played in a league/tournament, enriched', which names a clear resource and implies a list/fetch operation. However, it does not distinguish itself among the many match-related tools (e.g., get_player_matches, get_team_matches, get_pro_matches), so an agent still has to infer scope differences among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to use get_leagues first to find league ids, which is explicit prerequisite guidance. It does not state when NOT to use this tool or which sibling to prefer for player/team/pro match lists, but the league-scope clue covers the most important usage decision.
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 disclosing behavior. It mentions the output fields but does not describe any behavioral traits such as authentication needs, rate limits, pagination, or what happens with invalid parameters. The description is too sparse to convey 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and key outputs. It contains no filler or repetition, making it efficient, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 20 parameters and no output schema, the description gives only a high-level view of the output fields. It lacks critical context such as default behavior, pagination semantics, or how the standard filters affect results. An agent would need to rely heavily on the schema, but the description does not provide enough situational context for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 20 parameters have detailed descriptions in the schema, so the baseline is 3. The description adds no additional parameter semantics beyond noting 'the standard filters', which is vague and does not compensate or enhance the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the heroes a player has played, with specific fields listed (hero names, games, wins, win rate, with/against splits). This is a specific resource and action, distinct from sibling tools like get_player_hero_rankings, which focus on rankings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_player_hero_rankings or get_player_matches. The phrase '(with the standard filters)' implies common filters but offers no explicit selection criteria 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. It explains the histogram concept and common fields but does not disclose behavior such as how bins are computed, what the response contains, whether the 'win' parameter filters results, or any default scoping. The phrase 'wins per x-value' hints at the output but leaves the exact semantics ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with a clear purpose statement followed by a succinct list of common field values. It front-loads the concept and uses no unnecessary words; every part contributes directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 20 parameters, no output schema, and no annotations, the description is far from complete. It lacks any explanation of response structure, pagination, default values, or how filters like 'win', 'significant', or 'date' affect the histogram. An agent invoking this tool would still need to infer much behavior from undocumented conventions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all 20 parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds a more comprehensive list of valid values for the required 'field' parameter (kills, deaths, assists, etc.) than the schema's examples, thereby providing practical extra meaning for choosing an appropriate field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (one stat for a player) and the nature of the output (a distribution/histogram), e.g., 'wins per x-value'. However, it lacks an explicit action verb like 'Retrieve' or 'Get', and while it distinguishes from totals/counts by implying distribution, it does not explicitly contrast itself with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_player_totals or get_player_counts. The description does not state conditions, exclusions, or mention any sibling tool, leaving the agent to infer the appropriate context from the tool name and schema.
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, the description carries full burden of behavioral disclosure. It states that the tool returns all tracked leagues/tournaments with ids and tiers, implying a read-only operation, but it does not mention any potential limitations, data freshness, authentication requirements, or whether the list is sorted or paginated. The description is minimal and leaves much to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the content and format of the result. It is concise and front-loaded with the key information (all tracked leagues/tournaments, ids, tiers). It could arguably include a bit more structure, but for a simple tool with no parameters, this is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, low complexity), the description covers the essential information: what is returned and what fields are included. It is sufficient for an agent to understand the basic purpose and expected output type, though it omits details like ordering or whether the list is exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There is no schema to add detail, and the description correctly does not introduce any parameter-related confusion. Since there are no parameters to document, the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear resource (tracked leagues/tournaments) and informs the user it returns ids and tiers. The verb is implied (get/list), but the content is specific enough to understand the tool's purpose. It does not explicitly differentiate from sibling tools like get_league_matches, but the resource scope is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of when not to use it or any conditions that would make it preferable to other league-related tools. The description simply states what the tool returns without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It discloses the core output semantics (percentile values by bracket) and the option to omit a bracket, but it does not mention anything about the response shape, default behavior beyond 'omit for all', or any caveats. For a read-only query tool this is adequate but not thorough, warranting a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that wastes no words. It front-loads the core concept ('Benchmarks for a hero') then specifies the main fields and the optional bracket filter. Every clause serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should provide enough to succeed. It explains what data all accessible agencies but does not describe the structure of the response, how percentiles are presented, whether a heroic record is required beyond an ID, or the data source. Since the required parameter is handled by the schema and the tool returns, a minimal description is acceptable, but there are gaps regarding response format and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both parameters are already fully described in the schema. The description adds minimal semantic value beyond the schema, such as mapping bracket numbers to rank names ('1 Herald ... 8 Immortal') and stating that omitting bracket means 'all brackets', but these details also appear in the schema. With full schema coverage, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific about what the tool returns: percentiles of what various players achieve (last hits, kills, GPM, etc.) for a given hero, broken down by rank bracket. This clearly differentiates it from sibling tools like get_hero_stats or get_hero_matchups, which return different aggregate data. It lacks only the explicit 'retrieves/gets' verb, but the meaning is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what data is shown but provides no explicit guidance on when to choose this tool versus get_hero_stats, get_hero_rankings, or get_hero_players. There are no conditions, prerequisites, or exclusion scenarios mentioned, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the kind of data returned (average rank, spectate count, scoreboard, hero names) but does not mention whether live matches have inherent delays, whether authentication is needed, or any rate-limit or caching behavior. Basic transparency exists but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that packs the essential information: what is returned and the key fields. No filler words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the main payload adequately. However, it lacks any usage context or mention of possible limitations (e.g., number of results, update frequency), leaving an agent with only the bare functional description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (language) with a detailed description, so schema coverage is 100%. The tool description does not add anything about parameters, but with full schema coverage a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a clear verb-resource pair ('Top live games currently in progress') and enumerates key return fields (average rank, spectate count, scoreboard, hero names). It is specific enough to be distinguished from generic match tools, though it does not explicitly differentiate from sibling tools like get_pro_matches or get_match.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only states what it returns, not the intended use case, prerequisites, or when a user should instead call a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the data granularity (per match) and the focus on rank medal changes, which is behavioral info, but it does not mention whether the operation is read-only, whether there are rate limits, or how the data is ordered. The granularity adds value, but side-effect disclosure is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that packs the key purpose and data grain. It is front-loaded with the resource and the specific data type, with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, no-output-schema tool, the description conveys the core function but stops short of defining the expected response format beyond 'snapshots'. It is minimal, and with no annotations to off-load safety information, an agent might need to infer the output structure and limits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter account_id is already well-documented within the schema itself. The description adds nothing extra about parameter usage or constraints; the baseline is adequate because the schema carries the semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it returns a player's rank medal history over time, specifically as rank_tier snapshots per match. It identifies the subject (player) and the resource (rating history) but does not explicitly differentiate from other player-related tools except implicitly by topic. It is specific enough to avoid tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention any conditions for selecting it over other player history tools like get_player_histogram or get_player_hero_rankings. There is no mention of the type of request or prerequisite context beyond the account_id parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It adds useful context about the return format (per-player rows with account id, rank, KDA, items-lite) and notes the data is 'enriched', though it does not specify what enrichment entails. It omits details about pagination, rate limits, or that only public matches are accessible, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that conveys the resource, scope, and return row composition without wasted words. The term 'enriched' is slightly vague but the overall structure is efficient and front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low parameter count, complete schema, and absence of an output schema, the description provides a reasonable starting point. However, it lacks mention of default behavior (e.g., limit default), pagination, or any filtering nuances. Since the tool has many siblings and no annotations, a bit more context on expected use or data shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already thoroughly documents all three parameters, including hero_id resolution via search_dota_entities and language options. The description adds no extra parameter-level meaning beyond what the schema already provides. Therefore, the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches recent public matches for a hero, with a specific resource (hero) and a specific scope (recent public matches). It also hints at the row-level structure (account id, rank, KDA, items-lite). It does not explicitly distinguish itself from sibling tools like get_hero_players, but the verb and resource are unambiguous enough for an agent to understand the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by 'recent public matches on a hero'—an agent can infer this is for viewing recent hero match data. However, there is no explicit guidance on when to choose this over alternatives, nor any exclusions or prerequisites. The sibling list includes many hero-related tools, so more specific routing would have been helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It conveys that item names are resolved in the output and that data is split into start/early/mid/late phases, which is useful. However, it does not describe the exact output data shape, whether counts or percentages are returned, or any additional API behavior like pagination or rate limits. This is a read-only operation by name, but no explicit safety detail is added beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core purpose and enumerating the phase keys for clarity. It could arguably be more verbose ('Returns item popularity...'), but it is compact and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one required parameter and moderate output complexity; no output schema exists. The description gives meaningful context about the return structure (phases and resolved item names), enough to understand what the tool provides. It does not detail the exact popularity metric or example payload, but for this straightforward lookup tool, the basics are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with hero_id and language both fully described in the schema. The description adds no information about parameter meanings or how to use them. Since the schema carries the burden, a baseline of 3 is appropriate, as the description contributes no further parameter-level value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing item popularity for a specific hero, organized by game phase, with the key added detail that item names are resolved. It is distinct from sibling hero-related tools because none others mention item popularity by phase, though the phrasing is nominal rather than a verb-led action statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you would call this when you need item popularity data for a hero. However, it provides no explicit guidance on when to prefer it over other hero-related tools, no exclusion criteria, and no mention of alternative tools for similar data such as benchmarks or recent matches. The absence of explicit 'when-to-use' guidance leaves the decision to inference.
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 data is returned but does not mention whether the operation is read-only, any authentication requirements, rate limits, or error behavior. For a simple GET-like tool this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs in the core purpose and a concrete list of returned fields with no filler. It is concise and front-loads the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one well-documented parameter, no output schema), the description is reasonably complete for a basic profile lookup. However, it lacks guidance on usage context and does not disclose any operational constraints, which for a tool with no annotations leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers the single parameter (account_id) thoroughly, including how to obtain the value. The tool description itself adds no extra parameter explanation, but since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource ('a player's profile and current competitive standing'), and enumerates the exact fields returned (display name, avatar, country, rank medal, leaderboard position, MMR estimate). This distinguishes it from sibling tools like get_player_pros or get_player_totals, which focus on different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for basic profile queries but does not explicitly state when to use this tool over alternatives like get_player_pros or get_player_matches. There is no mention of exclusions or conditions, leaving the agent to infer context from the tool name and field list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It states this is a simple listing operation with no side effects or authentication requirements, which is useful. However, it does not mention pagination, response size, rate limiting, or whether the list is complete/current, leaving some behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that presents the core information immediately. Every word contributes value, naming the resource and the key fields returned. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, read-only listing tool this description is nearly complete: it tells the agent what the tool returns and includes enough detail to judge relevance. The only missing element is a note that distinguishes it from the very similar sibling get_player_pros, which would improve completeness for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage of those (trivially) is 100%. Baseline for no parameters is 4, and the description adds no parameter-specific details because none exist to describe. This score reflects that the schema fully handles the parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a verb and resource: 'List of professional players' and names the included attributes (teams, countries, Steam ids). It does not explicitly distinguish from sibling get_player_pros, which likely refers to a different endpoint or perspective, so it falls one step short of a top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when this tool should be used over alternatives, nor are any exclusions or contextual hints given. The presence of the similarly named sibling get_player_pros makes this gap significant, as the agent cannot determine which one to select based on the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description is accurate about it being a read operation (focused statistics), but it doesn't mention potential limitations like the absence of certain brackets, whether averages are aggregated per bracket, or whether hero names are localized even if language is set. It's a safe read tool, but extra detail on the shape of the output would have deepened 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: a single informative sentence and a clear directive, placing the key stats and scope up front. There's no filler or redundancy; every phrase adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must carry the return-information burden. It successfully indicates the primary data (pick/ban counts, win rates) and the dimensions (pro play, brackets, turbo) and that hero names are resolved. This is sufficient for an agent to know what to expect. It could add a little more about the list format (e.g., one entry per hero), but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, language, has a 100% descriptive schema that covers its purpose, accepted formats, defaults, and the option to list all supported languages. The tool description doesn’t mention the parameter at all, but the schema already handles the semantic burden, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides 'full hero statistics' including pick/ban counts and win rates, scoped across pro play, public skill brackets, and turbo, with hero names resolved. That is a specific verb+resource. However, it doesn't contrast with sibling tools like get_hero_rankings or get_hero_matchups, so it doesn't fully distinguish them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description ends with 'Use for meta/tier questions,' which gives a clear typical context. But it does not explicitly mention when not to use it or name any alternative tools for more specialized queries. This is a single use case, no exclusions, so it's adequate but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly implies a read-only operation and enumerates some return fields, but it does not disclose potential absence of data, error behavior, or any authentication requirements. The listed fields add some context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence with a parenthetical list that is front-loaded with the action. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description sufficiently covers the purpose and expected return contents. It omits edge cases like not-found behavior or exact JSON structure, but these are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the team_id parameter is already well explained with a source hint ('from get_teams, pro match rows, or get_pro_players'). The tool description adds no additional meaning regarding the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (one professional team's profile) with a concrete field list (rating, wins/losses, logo, tags). The singular 'one' clearly distinguishes it from sibling get_teams, leaving no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus alternatives like get_teams, get_team_matches, or get_team_players. The phrase 'one professional team' implies a need for a specific team_id, but no direct comparison or exclusion conditions are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the responsibility for behavioral disclosure. It adds meaningful ordering context ('ranked by rating') and describes output fields, but it does not mention pagination limits, rate limits, or any other operational behavior beyond the schema-provided page 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the primary action and resource, followed by key result attributes. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description covers the essential selection criteria: what is listed, how it is ordered, and what details are returned. It omits only minor specifics like total result counts or additional fields, but these are not necessary for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'page' parameter, so the description does not need to restate its meaning. The description provides no additional insight into how the page parameter interacts with the results, which is acceptable given the exhaustive schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List'), a clear resource ('professional teams'), and an ordering criterion ('ranked by rating'), plus key output fields. This cleanly differentiates the plural listing tool from its singular sibling 'get_team', so an agent can select it without confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives such as get_team or get_team_matches. The intended use case is implied but not stated, and there is no mention of when this tool should be avoided.
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 only states that it checks status but does not disclose any behavioral traits such as return format, possible status values, whether it is read-only, or whether it can be polled. This is a minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no extraneous words. It clearly states the purpose and the source of the required parameter. Extremely concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter status-checking tool with no output schema, the description is adequate but lacks details about the response structure or how to interpret the status. It does not mention possible states or whether the agent should poll. Slightly incomplete for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear job_id description. The description adds a connection to request_match_parse, clarifying where the job_id comes from. This is slight extra value, but the schema already fully documents the parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking the status of a match parse job, and explicitly references the originating request_match_parse tool. This distinguishes it from the many sibling tools, which focus on retrieving data or submitting actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: after calling request_match_parse, the returned job_id is used here. It does not explicitly state when not to use it or list alternatives, but the connection to request_match_parse provides sufficient context for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It explains the coordinate system ('keys are x,y on a 64x64 grid') and how to interpret raw position maps, which adds non-obvious behavior. However, it does not disclose the output structure beyond counts and maps, nor any caveats about performance, scaling, or network behavior. That is acceptable but not rich for an un-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core purpose and wastes no words on filler. It packs in the coordinate legend and conversion rule efficiently. It could have separated the coordinate explanation into a second sentence for readability, but overall it is lean and structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that returns a wardmap for a player with many filter parameters, the description explains the key output components (total counts + raw position maps) and the coordinate math, which is non-obvious and essential for correct interpretation. With no output schema, the description adequately covers the return structure though it does not mention, for example, whether results include game mode or hero breakdowns, but the filters in the schema imply these are applied. The description is sufficiently complete for typical agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the input schema documents every parameter with clear descriptions (win, date, sort, limit, etc.). The description adds nothing about parameters themselves—it only describes the output format and coordinate conversion. Since the schema already covers the semantics, a baseline of 3 is appropriate with no additional value from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: 'Ward placement heatmap for a player' with a specific resource (player) and resource (ward placements). It distinguishes itself from sibling tools like get_player_wordcloud (word chat) or get_player_heroes by naming the ward heatmap topic. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates the tool is used when an agent needs ward placement data for a player, but it does not explicitly state when to use this tool compared to alternatives like get_player_totals (which might include warding stats) or get_player_histogram. No exclusions or when-not-to-use guidance is given; context must be inferred.
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 only states what the tool returns without mentioning any side effects, authentication needs, rate limits, or return format. Given the absence of annotations, more behavioral context would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence containing the core purpose and the key referencing constraint. Every word earns its place, and the information is front-loaded and immediately useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the primary purpose and filter association, but with no output schema, it omits details about the response structure, pagination behavior, or any limitations. For a tool with 19 parameters, a bit more context on expected output would improve completeness, yet the core functionality is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already provides 100% description coverage, the tool description adds value by explicitly stating that filters are identical to get_player_matches, which is a strong hint for agents already familiar with that tool. This contextual linkage makes parameter usage clearer than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting a player's win/loss counts and win rate. It also references the sibling tool get_player_matches to clarify filter behavior, making it easy to distinguish from other sibling tools like get_player_totals or get_player_counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it uses the same filters as get_player_matches, which gives a useful reference point but does not explicitly define when to choose this tool over alternatives. It lacks direct exclusions or conditions, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the output structure (two lists) and sorting behavior, adding value beyond the name. However, it does not disclose potential caveats like case sensitivity, text normalization, or how filters interact with results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence explains the return content and structure, the second gives the use case. Every word earns its place and it is well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich 19-parameter schema and absence of an output schema, the description adequately explains the high-level return shape but lacks details on list item format (e.g., word-frequency pairs) and default behaviors. It is sufficient for basic understanding but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description does not add extra meaning beyond what the schema already provides, but it does not need to since all parameters are well-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns words said in a player's matches, sorted by count, with separate my_words and all_words lists. This precisely identifies the resource and differentiates it from all sibling tools, none of which are wordcloud-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('chat-toxicity or tilt flavor') but does not explicitly state when to use alternatives or exclusion criteria. It implies the intended context but lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the binning behavior and bucket format, which is useful. However, it does not mention potential caveats like small sample sizes, missing duration buckets, or whether the win rate is aggregate across all brackets. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the key grouping detail and immediately conveys the analytical purpose. No filler words or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only lookup, the description covers the essential output concept (win rate per duration bucket). It does not specify exact return fields or ordering, but the scope is simple enough that an agent can correctly invoke the tool and interpret the result. Minor gaps exist but are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents hero_id with a clear explanation (resolve names via search_dota_entities and an example). The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('binned'), a resource ('hero's win rate'), and the exact grouping (match duration buckets in 5-minute increments). It clearly distinguishes this tool from siblings like get_hero_stats or get_hero_matchups by focusing on duration-based performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases (analyzing hero power curve over game length) but does not explicitly state when to prefer this tool over alternatives or when not to use it. It offers no exclusions or named sibling comparisons, leaving usage largely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the content returned (names, attributes, attack type, roles, base stats) and indicates it lists all heroes, but it does not mention pagination, response format, or any rate limits. For a simple list endpoint, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the primary action and resource, then lists the returned fields. It is concise, every word contributes, and it ends with a clear usage hint. No fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no required parameters and no output schema, the description adequately summarizes the return content. It could specify the exact structure (e.g., array of objects) but 'list all' implies a list. The inclusion of base stats and localized names gives enough context for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a detailed description of the 'language' parameter, covering accepted codes, tags, and the default behavior. The tool description adds marginal context by mentioning 'localized + English' names, which indirectly relates to the language parameter, but it does not go beyond the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and specifies the exact resource ('all Dota 2 heroes') along with the content fields (names, primary attribute, attack type, roles, base stats). This clearly distinguishes it from sibling tools like get_hero_stats or get_hero_matchups, which focus on statistics and matchups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it is a 'good starting point for hero questions,' which implies a broad use case. However, it does not explicitly mention when to avoid this tool or name alternatives for more specific hero data (e.g., get_hero_stats for statistics). The guidance 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does reveal key behavioral traits: the approximate number of matches (~20), that filters are disregarded, and the enrichment fields. However, it does not mention whether the operation is read-only, any authentication or rate-limit considerations, or error/edge cases for invalid account IDs. The provided behavioral details are useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that packs the essential information: target scope, unfiltered nature, and output enrichment. It avoids redundancy and is efficiently structured, with the most important qualifier ('regardless of filters') included upfront.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately lists the main output categories (hero names, win/loss, KDA, game mode, skill bracket) so an agent understands what to expect. It also covers the tool's core behavior and scope. Minor gaps include lack of return structure details (e.g., field names) and any mention of limitations like account existence, but for a simple 2-parameter tool these are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for both parameters (account_id and language). The tool description adds no extra meaning about parameters beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource ('a player's ~20 most recent matches'), and distinct characteristics ('regardless of filters', enriched with hero names, win/loss, KDA, game mode, skill bracket). This makes it easily distinguishable from sibling tools like get_player_matches, which likely returns filtered or more extensive match data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'regardless of filters' implies this tool is for a quick unfiltered snapshot of recent matches, which offers some guidance. However, it does not explicitly say when to prefer this over get_player_matches or other sibling tools, nor does it mention any exclusions or prerequisites. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does explain the search key, that results are account ids, and how to handle a Steam profile URL. However, it is silent on match semantics, result limits, pagination, and error behavior, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The most important facts — what is searched and what is returned — are front-loaded, and the extra URL guidance earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter search tool, the description is adequately complete: the schema covers the input, and the description explains the output and a common id-extraction case. Mentioning result limits or ambiguity handling would improve completeness, but nothing essential is missing for basic correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single q parameter with a clear description and minLength constraint, so the baseline is 3. The description adds peripheral context about personaname and account-id derivation but does not substantially improve on the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Search Dota 2 players'), a specific lookup key ('display name / personaname'), and the useful output ('account ids usable with the player tools'). This clearly distinguishes it from stats-oriented player siblings, though it does not explicitly contrast it with search_dota_entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes a clear use case: find players by display name and obtain account ids for use with player tools. It also gives practical guidance for deriving an account id from a Steam profile URL. It does not name explicit alternatives or exclusions, but the context is sufficient for a simple lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially carries the behavioral burden by saying the returned rows are enriched with hero names, win/loss, and game-mode labels, and that the history is rated. It does not disclose default significance/Turbo behavior, sorting/pagination defaults, or response details beyond those three enrichments.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that front-load the action and resource, summarize commonly used filter categories, mention enriched rows, and point to summary alternatives. There is no filler or redundant repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It gives the core context needed for a filtered row-level match-history call and explicitly handles the summary-use case. With 21 parameters and no output schema, one might expect a complete output/return hints or a note on paging/limits; those are left to the schema or are otherwise absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Because the input schema coverage is 100% and each parameter already has a descriptive sentence, the baseline is 3. The high-level list of filters in the description adds no parameter syntax or semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and object: "Get a player's rated match history," and lists the available filter dimensions and output enrichments. It also distinguishes itself from its summary siblings by naming get_player_win_loss and get_player_heroes as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The final sentence gives an explicit when-not-to-use rule: summary requests should use get_player_win_loss or get_player_heroes. It does not, however, contrast this tool with the similarly named get_player_recent_matches sibling, leaving some selection nuance to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses the ordering (newest first), the pagination mechanism (less_than_match_id), and that results are enriched with readable fields. This goes beyond a bare read operation, though it does not cover error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. Key facts (scope, ordering, pagination, enrichment) are front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain the return shape. It lists the main fields but 'Enriched with readable fields' is vague—it does not specify the exact response structure (e.g., array vs. object) or any additional fields. For a list endpoint with pagination, this is a tolerable but not complete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well-documented. The description's mention of less_than_match_id for pagination adds minimal value beyond the schema's own description. It does not provide extra semantic context beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (recent professional matches), specifies the included fields (league, teams, score, duration), and states the ordering (newest first). It is easily distinguishable from sibling tools like get_match or get_league_matches by the combination of 'most recent' and 'professional'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for fetching recent professional matches but does not explicitly state when to use it over alternatives. It does provide pagination guidance specifically for less_than_match_id, which is a usage detail, but it lacks explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It does reveal that the operation is a non-read action on cached data, notes the ~500 match range, and mentions the API call cost. However, it is silent on whether the refresh is synchronous or asynchronous, what happens to existing cached data, and what the response indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first is front-loaded with the action and target data; the second adds a usage rule and a cost note. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, when to invoke it, and follow-up guidance, but lacks any note on response shape or potential delays. For a tool with no output schema and no annotations, an agent would benefit from knowing whether to expect a simple acknowledgement and whether it needs to wait before re-querying. This missing information keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage: account_id is thoroughly described with its Steam32 format and source. The description doesn't need to explain parameters, and adding a generic reference to 'a player' is sufficient; there are no extra semantics to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies an action ('refresh') and a specific resource ('a player's match history... medal and profile name'), making it easy to distinguish from the many read-only get_player_* sibling tools. It states the scope precisely and unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition: use when a player's data looks stale, followed by a concrete post-condition ('then re-query'). It doesn't name alternative tools (such as request_match_parse) or state when not to use it, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It adds genuinely useful behavioral context by specifying the data source (public matches) and resolving the win_rate ambiguity with 'low win_rate vs a hero means that hero counters this one.' However, it does not disclose response ordering, error behavior, or rate limits, which matters more given 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first delivers the purpose and output content, the second adds the interpretive caveat that makes the tool safely usable. Both sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-lookup tool with fully documented schema parameters, the description names the returned fields (games played, win rate), the data source, and how to interpret the key value. The main gap is that with no output schema, the response structure and ordering (relevant to the limit parameter) are left unspecified, but an agent still has enough to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The schema already documents hero_id resolution via search_dota_entities, limit range and default, and language codes with defaults, so the tool description need not duplicate this. The description adds no parameter detail beyond the schema, which is acceptable at full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (hero performance against every other hero) and the content returned (games played and win rate from public matches). The 'counters lookup' framing and interpretation of low win_rate clearly distinguish this from sibling hero endpoints like get_hero_stats, get_hero_benchmarks, or get_hero_item_popularity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description frames the tool as 'the classic counters lookup,' giving an agent a clear condition for when to select it among the many hero-related siblings. It does not explicitly name alternatives or state when not to use it, but the use-case framing is strong enough to guide correct routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. The description states that ids are resolved to readable names, which is a helpful behavioral note, but it doesn't mention potential performance issues with no date/limit filters, default sort order, or exactly how the 'having' field behaves (it says 'used by hero-stat tools' but not this tool).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the core purpose ('Match counts broken down by...'), and ends with the id-resolution behavior. Every word earns its place; no repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only aggregation tool with 100% schema coverage and no output schema, the description is reasonably complete. It could mention that 'having' may not apply or clarify defaults, but the schema already covers parameter semantics, and the description conveys the grouping behavior that defines this tool's distinct value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 19 parameters. The description adds little beyond the schema—it lists breakdown dimensions but doesn't explain how they map to query parameters or clarify the 'having' parameter's role in this tool. Baseline 3 is appropriate given the complete schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool returns 'match counts' broken down by multiple dimensions (leaver status, game mode, lobby type, lane role, region, patch) and resolves ids to readable names. It uses a specific verb ('get') and resource ('player counts'), and the breakdown dimensions distinguish it from sibling tools like get_player_matches or get_player_win_loss.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only aggregation use case: counting matches with filters and grouping dimensions. It does not explicitly name alternative tools or when-not-to-use conditions, but the breakdown-by-categories wording makes its use case reasonably clear relative to siblings such as get_player_totals or get_player_matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explains the output format, included data fields, and the difference between parsed and unparsed matches. It does not mention error handling or rate limits, but provides useful context beyond a simple 'get match' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized and front-loads the core purpose and output style, followed by details about optional draft data and parsed matches. It is informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main return content and highlights the optional include sections through the schema. There is no output schema, but the description explains what the base response contains. Missing details like error cases or pagination are minor for a single-match fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, documenting all parameters and their defaults. The tool description adds no extra parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a Dota 2 match by id and presents it as a compact, human-readable view with resolved names and labels. This specific verb-resource combination distinguishes it from sibling tools like get_player_matches or get_pro_matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving match details and notes that it works with parsed matches for richer data, but does not explicitly contrast with alternative tools or state when not to use it. However, the focus on match id makes the intended context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It states the tool checks health/statistics and implies a connectivity check, but it does not describe what the response contains or whether it may fail or be slow. This is a moderate gap for a simple parameterless tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action is front-loaded, and the use-case guidance earns its place by telling the agent when to call this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health-check tool, the description is nearly complete: it states the purpose, the resource, and the practical use case. The only minor omission is a more concrete statement of the return payload, but no output schema exists and the simple nature of the tool reduces the impact of that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter ambiguity to clarify. The baseline for zero-parameter tools is 4, and the description correctly does not invent unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and a clear resource ('OpenDota API service health/statistics'), immediately distinguishing it from the many data-query sibling tools. The name and description align perfectly, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful to verify connectivity before deeper queries' gives clear situational guidance for when to call this tool. It does not mention alternatives, but none are needed because no sibling tool duplicates the health-check purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that matching is case-insensitive and substring-based, and that it supports English and localized names. This goes beyond a generic search description and gives the agent concrete expectations about how the search behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy. The first sentence states the core capability and output, and the second gives actionable usage guidance. Every word earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search-lookup tool with four parameters and no output schema, the description fully covers the necessary context: what it searches, what it returns, usage ordering, matching behavior, and language support. It also points to list_supported_languages for language options, making the tool self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for all four parameters. The description adds conceptual context (e.g., 'English or any supported localized name') but does not significantly expand on the schema's parameter meanings. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find heroes/items/abilities by name' and retrieve numeric IDs. It explicitly lists the resource types (heroes, items, abilities) and the action (find/get IDs), distinguishing it from sibling tools like get_heroes or get_constants that serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this FIRST to resolve names... into the ids other tools need.' This tells the agent when to invoke this tool relative to others, and it implies the alternative (other tools that consume these IDs). It stops short of naming explicit alternatives or when-not-to-use conditions, so it doesn't earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior on its own. It declares that the resource is 'raw' and that constants are English-only, which is meaningful and goes beyond a generic getter. It stops short of stating the response format or error behavior, but for a resource-lookup tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences contain all essential information. The first sentence immediately states the action and gives a representative list; the second adds a valuable note about localization. No redundant wording exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema or annotations, the description tells the agent which resource names to use and warns about the English-only behavior. It doesn't explicitly describe the returned data's structure, but the term 'resource' and enumerable constants imply a straightforward JSON-like payload. Minor ambiguity remains about invalid resource handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single 'resource' parameter with examples. The description adds extra examples and the English-only caveat, reinforcing parameter meaning and disambiguating acceptable values. Given 100% schema coverage, the additional values help but are not critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a clear verb+resource pattern: 'Get a raw OpenDota game-constants resource,' then lists a wide range of concrete resource names (heroes, items, abilities, item_ids, etc.). This makes the tool's scope obvious and distinguishes it from the many sibling lookup tools that fetch specific stats or matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description supplies clear context: use this tool for raw game-constant data. It further tells the agent not to use it when localized names are needed, recommending 'tools with a language parameter' instead. However, it names no specific sibling tool as the alternative, so the routing is partly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output shape (Steam codes and labels) and purpose, implying a read-only operation. It doesn't mention pagination or sorting, but for a static list these are not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The first sentence states what is listed; the second explains how to use the result. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is fully sufficient. It tells the agent what it returns, with an example, and how to apply that output. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so description adds no parameter-specific meaning. However, it clarifies that the returned codes are intended for the 'language parameter' of other tools, which is useful context. Baseline 4 for no-param tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource: languages for localization with Steam codes and labels. It includes an example code ('schinese') and explains the output structure, making it distinct from sibling data-fetching tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states how to use the tool's output ('Pass one of these to the language parameter of other tools'), providing clear usage context. It doesn't explicitly state when not to use it, but for a simple enumeration tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the waiting behavior (default 45s, blocks), cost implication (counts as 10 API calls), and the outcome (unparsed vs parsed). It also clarifies the 'unfinished' status handling, giving the agent critical behavioral expectations beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states the core action and wait, second explains the value and next step, third covers cost and failure handling. Every sentence is informative and there's no filler. Slightly dense but still well-structured and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers what the agent needs: how to invoke, what to expect (waiting), cost, and follow-up actions. It also mentions the default wait and timeout tip. For a tool with only two parameters and no nested objects, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both match_id and wait_seconds have descriptions that explain their meaning. The description adds context about the default and timeout constraint but doesn't add new semantic depth beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Submit a match for full replay parsing') and resource ('a match'), and differentiates from siblings by noting 'Unparsed matches lack teamfights/graphs/ward logs' and directing to get_match for the deep view. It clearly distinguishes this from get_parse_job_status and other match-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly explains when to use this tool (when a match is unparsed and needs parsing), what to do after completion (call get_match with include.teamfights), and the fallback behavior if unfinished (retry later or poll with get_parse_job_status). This is comprehensive usage guidance with alternatives named.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/yuxiang115/opendota-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server