live_matchesFetch all currently live Dota 2 matches from STRATZ, returning matchId, radiantTeamId, direTeamId, and current game time. 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 read-only, open-world, idempotent, non-destructive behavior, lowering the bar. The description adds no further useful behavior (e.g., rate limits, external API latency) and instead asserts 'No arguments required,' which misrepresents the authentication requirement.
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 first sentence is tight and front-loaded. However, the second sentence 'No arguments required' is not only unnecessary but false, so the description doesn't cleanly earn its place.
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 live-data fetch with a schema-documented API key, the description could be complete if it aligned with the schema. By denying the required parameter and offering no alternative context, it leaves the agent with a contradicted invocation model.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents _apiKey with a clear description, so the baseline would be 3, but the description directly contradicts the schema by claiming no arguments are required. This undermines the agent's ability to invoke the tool correctly.
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?
States the specific action ('Fetch all currently live Dota 2 matches from STRATZ') and the exact return fields (matchId, team IDs, game time). This distinguishes it clearly from single-match or player-focused siblings like match and player_matches.
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?
There is no guidance about when to use this tool vs alternatives, and the only usage statement—'No arguments required'—is false because the input schema requires _apiKey. This is actively misleading rather than simply absent.
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.