Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

opendota_hero_descriptions

Retrieve Dota 2 Aghanim's Scepter and Shard descriptions for all heroes or one hero_id, showing upgrade availability, affected skills, new skills, and optional lore text.

Instructions

OpenDota Dota 2 Aghanim's Scepter and Shard descriptions. Returns, for every Dota 2 hero or for one hero_id, what Aghanim's Scepter and Aghanim's Shard do: whether each upgrade exists, its description, the skill it changes and whether it adds a new skill. include_lore=true adds each hero's lore text (about 155 KB for all heroes), so it is off by default. An unknown hero id returns not found. Take hero_id from opendota-heroes.

Input Schema

NameRequiredDescriptionDefault
hero_idNoPositive hero id from opendota-heroes; omit it for all heroes
include_loreNotrue adds each hero's lore text; defaults to false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A4.5/5.0
Behavior4/5

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

No annotations exist, so the description carries the load, and it does well: it discloses the error case ('unknown hero id returns not found') and the payload cost of include_lore (~155 KB for all heroes) which justifies the default-off choice. It stops short of stating read-only/rate-limit behavior, but for a read endpoint the key operational caveats are covered.

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

Conciseness5/5

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

Front-loaded with purpose, then return contents, then the include_lore cost/default, then error behavior, then the hero_id source. Every sentence adds a distinct fact with no filler.

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?

No output schema, yet the description specifies what each returned record contains and the one error behavior, plus the size tradeoff of lore. Nothing an agent needs to call it correctly is missing.

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

Parameters4/5

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 meaning beyond the schema: the ~155 KB size implication of include_lore and where hero_id should come from (opendota-heroes). This is genuine incremental guidance.

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?

States a specific verb and resource ('Returns... Aghanim's Scepter and Shard descriptions') and enumerates the exact fields returned (whether upgrade exists, description, skill changed, new skill). An agent can distinguish it from opendota_hero_abilities or opendota_abilities because it is scoped to Aghanim's upgrades.

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?

Clarifies the two modes: omit hero_id for all heroes or supply one, and points to opendota-heroes as the source of hero_id. It doesn't explicitly name an alternative tool or exclusions, but the usage context is clear.

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

Deploy Server

Other Tools