hero_statsDota 2 hero meta: per-hero pick/win/ban counts in pro play, primary attribute, attack type, and roles. Optionally filter by role (e.g. "Carry", "Support"). OpenDota keyless data.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Optional role filter, e.g. "Carry", "Support", "Initiator". | |
| limit | No | Max heroes to return (default 30). |
Changes observed during successful MCP inspections.
Input schema / examplesAdded value: +[
+ {
+ "limit": 10,
+ "role": "Carry"
+ },
+ {
+ "limit": 30
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare all safety hints (readOnly, openWorld, idempotent, non-destructive), so the description's additional context about OpenDota keyless data and scope to pro play adds value beyond the structured annotations. It does not detail behavior such as response ordering, pagination, or rate limits, but given annotation coverage, the added context is helpful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with a clear topic ('Dota 2 hero meta'), and each sentence serves a purpose: declaring the data content and noting the optional filter and data source. There is no redundant or extraneous wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, no output schema, and robust annotations, the description adequately conveys the data scope (pro play), the kind of data returned (pick/win/ban counts, attributes, roles), and the keyless access. It does not mention time range or default limit, but for a simple read-only data tool, the description is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters (role and limit) with descriptions and examples, so schema coverage is 100%. The description echoes the role examples ('Carry', 'Support') and adds 'Initiator' but does not provide additional semantic detail beyond what the schema already offers. Baseline 3 is appropriate as the description does not materially enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides per-hero pick/win/ban counts, primary attribute, attack type, and roles for Dota 2 pro play. While it lacks an explicit verb like 'get' or 'list', the resource and scope are immediately clear. It distinguishes from sibling tools like pro_matches (match data) and get_player (player data) by focusing on hero meta stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving Dota 2 hero meta statistics and explains the optional role filter with examples, giving some practical guidance. However, it does not explicitly state when to prefer this tool over alternatives (e.g., pro_matches for match-level data) or provide exclusion criteria, leaving usage boundary implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.