heroesFetch the complete list of all Dota 2 heroes from STRATZ, returning each hero's numeric id, name, displayName, and shortName. No arguments required.
| Name | Required | Description | Default |
|---|---|---|---|
| _apiKey | Yes | Your own STRATZ API token (BYO — Pipeworx does not supply one). Free at https://stratz.com/api after Steam sign-in. |
Changes observed during successful MCP inspections.
Input schema / properties / _apiKeyAdded value: +{
+ "description": "Your own STRATZ API token (BYO — Pipeworx does not supply one). Free at https://stratz.com/api after Steam sign-in.",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "_apiKey"
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, open-world, idempotent, and non-destructive, so the description doesn't need to restate safety behavior. It adds return-field details, which is helpful. However, the false claim 'No arguments required' is misleading and slightly undercuts the otherwise adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core purpose, and the return-field list is efficient. It loses a point because the concise 'No arguments required' sentence is inaccurate and would have been better omitted or corrected.
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?
For a simple no-output-schema tool, the description covers the basic purpose and return fields. But it denies the existence of the required _apiKey parameter, which is a critical omission/misstatement for invocation. The schema partially compensates, but the description should be internally consistent with 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?
Schema coverage is 100% and the schema's _apiKey description is clear about the BYO token requirement. The description, however, explicitly says 'No arguments required', which contradicts the required _apiKey parameter. This is actively harmful: an agent following the description would omit a required field.
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 names a specific verb ('Fetch'), a specific resource ('the complete list of all Dota 2 heroes'), and the data source ('from STRATZ'). It also lists the returned fields, making the purpose unambiguous. It doesn't explicitly contrast itself with sibling tools like 'hero' or 'hero_stats', but 'complete list of all' inherently differentiates it.
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 this should be used when an agent needs the full hero roster, but it never explicitly says when to prefer this over siblings like 'hero' or 'hero_stats'. There are no exclusion criteria or alternative tool suggestions. The 'No arguments required' statement is closer to parameter guidance than to usage context.
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.