Allows analyzing public Dota 2 matches via OpenDota, returning a coaching-report-ready JSON summary covering laning, farming, deaths, itemization, objectives, teamfights, benchmark percentiles, skill build, damage sources, and rune control for a given match and participant.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@dota2-coach-mcp-server analyze match 7894561230, deep-dive on hero Pudge"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The MCP server behind the dota2-coach
Claude Code plugin. Exposes one tool, analyze_dota2_match, that fetches a
public Dota 2 match from OpenDota and returns a coaching-report-ready JSON
summary (laning, farming, deaths, itemization, objectives, teamfights,
benchmark percentiles, skill build, damage sources, rune control).
This repo is deployed at https://dota2-coach.promager.com/mcp, which the
plugin's .claude-plugin/plugin.json points to as a remote HTTP MCP server.
Installing the plugin does not run any of this code locally — it just
connects to wherever this is deployed.
Inputs: match_id (required), player (account_id, personaname substring,
or hero name substring, for a deep-dive on one participant), refresh
(bypass cache), no_wait (don't wait for OpenDota to parse an unparsed
match).
npm install
PORT=8787 npm run start:httpThen put it behind a reverse proxy that terminates TLS and forwards to that
port, e.g. an Nginx or Caddy config for dota2-coach.promager.com proxying
to http://127.0.0.1:8787. Keep the process alive across reboots/crashes
with systemd or pm2, for example:
pm2 start server.js --name dota2-coach-mcp -- --http
pm2 saveSet DOTA2_COACH_CACHE_DIR to a persistent path (survives restarts/deploys)
if you don't want to re-fetch/re-parse matches on every redeploy; it
defaults to ./cache next to this file otherwise.
No auth is implemented; anyone who has the URL can call the tool. That's a
reasonable default since it only proxies OpenDota's own public, free API and
holds no secrets, but consider adding an API key check (via headers in the
plugin's mcpServers config, once needed) if this ever needs to be locked
down.
Related MCP server: opendota-mcp-server
npm install
npm start # stdio, for local testing or a Claude Desktop mcpServers entryserver.js, two transports picked by CLI flag: default stdio, --http
for Streamable HTTP (what's actually deployed).
lib/ — the OpenDota fetch/cache/summarize logic. lib/analyze.js is the
entry point; see its interpretation notes cross-referenced in the plugin
repo's SKILL.md for what each output field means.
Fetch a public Dota 2 match from OpenDota and return a coaching-report-ready JSON summary: result, draft, per-player stats and benchmark percentiles vs. their rank bracket, objectives/teamfight timelines, rank medal, and (with player) a deep-dive on one participant (lane efficiency, deaths log, skill build, damage sources, rune control, item/ability usage counts, item timing, gold/xp/net-worth timelines). Use the returned JSON to write the actual coaching analysis yourself — this tool only extracts and translates data, it does not generate advice.
| Name | Required | Description | Default |
|---|---|---|---|
| player | No | Focus the deep-dive section on one participant: account_id (exact), personaname (substring, case-insensitive), or hero localized name (substring, case-insensitive). Always pass this when the user asks about their own performance rather than a general match recap. If ambiguous or no match, the tool errors and lists the actual participants — retry with a more specific value (account_id is always unambiguous). | |
| no_wait | No | Don't request/wait for a full parse if the match is unparsed; analyze whatever basic data is available. | |
| refresh | No | Bypass the local cache and re-fetch from OpenDota (e.g. the match was reparsed). | |
| match_id | Yes | Numeric Dota 2 match id, e.g. from a Dotabuff/OpenDota/Stratz URL like .../matches/7891234567 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does well: it discloses the external source (OpenDota), that only public matches are supported, the non-advice behavioral boundary, and the deep-dive mode gated by `player`. It stops short of latency, rate-limit, or cache/parse-failure behavior (those live only in parameter text), so it is not exhaustive.
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?
Front-loaded with the core action and result, followed by the boundary statement. The long parenthetical inventories are dense but informative rather than filler. Slightly unwieldy as a single sprawling sentence, but every clause conveys field-level payload information an agent needs.
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?
No output schema exists, so the description must convey return structure — and it does, listing result, draft, per-player stats with rank benchmarks, timelines, and the optional deep-dive. Combined with the advice boundary, an agent has enough to decide to call it and to interpret the payload.
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%, so the baseline is 3, but the description adds real semantics: it explains that `player` switches on a whole extra deep-dive section and enumerates its contents (lane efficiency, deaths log, skill build, timings). That goes beyond the schema's parameter description by tying the parameter to output shape.
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 a specific verb and resource ('Fetch a public Dota 2 match from OpenDota') and enumerates the returned payload (result, draft, per-player benchmarks, timelines, optional deep-dive). An agent immediately knows both what it does and what it produces; no siblings exist to differentiate from.
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?
Clearly frames the tool's role: extract/translate data, then 'write the actual coaching analysis yourself — this tool only extracts and translates data, it does not generate advice.' That is a meaningful boundary on when the tool's output suffices. It offers no explicit when-not-to-use conditions or alternatives, but with no siblings the gap is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0analyze_dota2_matchScored across 1 tool
Only one tool exists, so there is no risk of misselection or overlap. Its purpose—extracting Dota 2 match data for coaching—is clearly stated.
The single tool uses a clear verb_noun snake_case pattern (analyze_dota2_match). With only one tool, there are no inconsistent naming conventions to compare against.
A single tool is thin for a server framed around coaching, even though this tool is comprehensive. Typical related operations like match discovery or player history are absent, making the surface feel under-scoped.
The tool covers deep single-match extraction including draft, per-player stats, timelines, and optional player deep-dive. It lacks match discovery/list and broader player profile tools, but the core analysis workflow is otherwise usable.
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Claude Code / MCP skills for the dev pipeline: discover, spec, design, build, ship, operate.
Live SEO workflow tools for Claude Code, Codex, and AI agents.
