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. |
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.
Several tools have overlapping or intentionally duplicated purposes: ask_pipeworx/ask_pipeworx_beta currently behave identically, and the Polymarket cluster (bet_research, polymarket_arbitrage, polymarket_edges, polymarket_fill_risk, polymarket_kalshi_spread) presents multiple scanners with fuzzy boundaries. The long descriptions help, but the set as a whole is hard to navigate without close reading.
Naming is a mix of bare single nouns (hero, match, meta, remember, forget), snake_case verb-first names (ask_pipeworx, compare_entities, generate_llms_txt), and noun-first compounds (pipeworx_feedback, bet_research, scan_competitor_ai_presence). There is no consistent verb_noun or noun-verb convention across the set.
At 43 tools, the server bundles at least five unrelated domains (Dota 2 stats, Pipeworx data querying, Polymarket analytics, memory, subscriptions, AI visibility). That is far too many for a focused MCP server, and the mix makes the surface feel like a grab bag rather than a purpose-built toolkit.
Each subdomain individually has solid coverage: Dota 2 has heroes/matches/players/tournaments/meta plus a GraphQL fallback, the data layer has discovery + routing + grounding + validation, and memory/subscriptions have full lifecycle operations. The only real gap is cohesion across domains; within each slice there are no obvious dead ends.