Skip to main content
Glama
hkaanengin

opendota-mcp-server

by hkaanengin

get_scenarios_item_timings

Analyze Dota 2 item timing win rates to identify optimal purchase times for heroes, improving build order decisions.

Instructions

Get win rates for heroes based on item purchase timing (when key items are completed).

Use this when users ask:

  • "When should I buy [item] on [hero]?"

  • "What's the optimal [item] timing?"

  • "How does [item] timing affect win rate?"

  • "Show me item timing statistics for [hero]"

  • "Which heroes benefit most from early [item]?"

  • "What's a good [item] timing?"

  • "Is [hero] better with early or late [item]?"

  • "When do pros buy [item]?"

Provides time-segmented data showing how item purchase timing correlates with win rates. Generally, earlier timings have higher win rates for core items, helping identify optimal farming targets and build orders.

Supports natural language item and hero names.

Args: item_name: Item to analyze. Accepts item names like: - Core items: "bfury" (Battle Fury), "radiance", "midas" (Hand of Midas) - Mobility: "blink" (Blink Dagger), "force" (Force Staff) - Defense: "bkb" (Black King Bar), "linkens" (Linken's Sphere) - Boots: "travels" (Boots of Travel), "phase" (Phase Boots) - Support: "wards", "mek" (Mekansm) - And many more item names/abbreviations hero_name: Hero to analyze. Accepts: - Integer: Hero ID (e.g., 86 for Rubick) - String: Hero name (e.g., "Rubick", "Anti-Mage")

Note: At least one parameter must be provided. You can provide:
- Only item_name: See which heroes buy this item and when
- Only hero_name: See all item timings for this hero
- Both: See specific item timing for specific hero

Returns: Dictionary organized by timing brackets (formatted as "MM:SS"). Structure depends on parameters provided:

If only item_name provided:
- item_name (str): The item being analyzed
- [time brackets]: Keys like "12:30", "15:00", etc., each containing list of:
    - hero_name (str): Hero name
    - games (int): Games with this timing
    - wins (int): Wins with this timing
    - win_rate (str): Win rate percentage (e.g., "65.3")
    
If only hero_name provided:
- hero_name (str): The hero being analyzed
- [time brackets]: Keys like "12:30", "15:00", etc., each containing list of:
    - item_name (str): Item name
    - games (int): Games with this timing
    - wins (int): Wins with this timing
    - win_rate (str): Win rate percentage
    
If both provided:
- hero_name (str): The hero
- item_name (str): The item
- [time brackets]: Keys like "12:30", "15:00", etc., each containing list of:
    - games (int): Games with this timing
    - wins (int): Wins with this timing
    - win_rate (str): Win rate percentage

Common queries: - Optimal item timing: get_scenarios_item_timings(item_name="bfury", hero_name="Anti-Mage") - Best heroes for item: get_scenarios_item_timings(item_name="blink") - Hero's item timings: get_scenarios_item_timings(hero_name="Anti-Mage")

Example: get_scenarios_item_timings(item_name="bfury", hero_name="Anti-Mage") -> { "hero_name": "Anti-Mage", "item_name": "bfury", "10:00": [{"games": 12, "wins": 10, "win_rate": "83.3"}], "12:00": [{"games": 45, "wins": 32, "win_rate": "71.1"}], "15:00": [{"games": 234, "wins": 145, "win_rate": "62.0"}], "18:00": [{"games": 189, "wins": 98, "win_rate": "51.9"}], "21:00": [{"games": 87, "wins": 38, "win_rate": "43.7"}], ... }

This clearly shows that Anti-Mage's win rate with Battle Fury decreases significantly as the timing gets later. A 12-minute Battle Fury has 71% win rate, while an 18-minute Battle Fury only has 52% win rate, suggesting you should aim for Battle Fury before 15 minutes for optimal results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hero_nameNo
item_nameNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It clearly discloses the requirement to provide at least one parameter, supports natural language names, explains the three return modes, and provides a detailed example showing the data structure and how to interpret win rate trends. This is strong transparency for a tool with no annotations, though it does not mention potential edge cases like omitted parameters causing errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is lengthy but well-organized into clear sections (purpose, use cases, args, returns, common queries, example). It is front-loaded with the primary purpose and usage examples. While some sections are verbose, every part earns its place given the tool's complexity and the need to document three modes of operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 optional parameters, 3 modes, no annotations, output schema present), the description is exceptionally complete. It fully documents the return structure for each parameter combination, provides a worked example, and interprets the data to help the agent understand the semantic meaning of win rates over time. It is more than sufficient for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema is minimal (anyOf integer/string/null with default null) and has 0% description coverage. The description's Args section fully compensates by explaining accepted item abbreviations, hero ID/name formats, and the three combination scenarios. The note about 'at least one parameter must be provided' and the 'Common queries' examples add semantic meaning far beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get win rates for heroes based on item purchase timing' with a specific verb and resource. It is distinguished from sibling tools like get_hero_item_popularity and get_scenarios_lane_roles by focusing on timing-based win rates. Numerous example queries reinforce the tool's unique purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a 'Use this when users ask' section with 8 explicit example queries and a 'Common queries' section with concrete parameter combinations. However, it does not explicitly mention when not to use this tool or name alternative tools for exclusions, which prevents a score of 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hkaanengin/opendota-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server