Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

opendota_pro_matches

Fetch recent professional Dota 2 match summaries with team, league, score, winner, and series data; paginate older results via match ID cursor. Use returned match IDs for parsed player stats.

Instructions

OpenDota recent professional matches. Returns professional Dota 2 match summaries with match ID, teams, league, start time, duration, scores, winner and series metadata. OpenDota returns up to 100 rows per page. Set less_than_match_id to a positive match ID to fetch older results; use next_less_than_match_id from the response for the next page. An empty cursor page is the end of history. This is recent results, not an upcoming-match schedule. Use opendota_match with one returned match ID for parsed player statistics.

Input Schema

NameRequiredDescriptionDefault
less_than_match_idNoReturn professional matches with IDs lower than this positive match ID; copy next_less_than_match_id from the previous response

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A4.6/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 full burden and mostly does: it discloses the page size cap (up to 100 rows), the cursor direction semantics, and the termination condition (empty cursor page = end of history). It implies a read-only retrieval but never states side effects, rate limits, or auth needs, which leaves a small gap for a no-annotation tool.

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 and payload, then pagination mechanics, then the disambiguation and the hand-off to opendota_match. Six short sentences, each carrying a distinct fact — no restatement of the name or filler.

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

Completeness4/5

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

With no annotations and no output schema, the description does the heavy lifting: it enumerates the returned fields and the pagination contract, which is what an agent needs to call it and page through results. What it omits is minor but real — whether the first unpaginated call starts from the newest match, and whether any league/team filtering exists at all.

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, and the description adds real meaning beyond it: the value must be a positive match ID, lower IDs yield older matches, and the recommended source of the value is next_less_than_match_id from the prior response. That operational guidance is exactly the kind of context a bare schema property description cannot convey.

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 professional Dota 2 match summaries') plus the exact fields returned, and explicitly contrasts with two siblings: it is 'recent results, not an upcoming-match schedule', and points to opendota_match for parsed player stats. An agent can distinguish it from opendota_league_matches, opendota_team_matches and opendota_match without opening any schema.

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

Usage Guidelines5/5

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

Explicit routing: use opendota_match with a returned match ID for parsed per-player statistics, and it declares what this tool is NOT (an upcoming-match schedule). It also gives the concrete pagination procedure — set less_than_match_id to go older, copy next_less_than_match_id, empty cursor page means end of history — so the agent knows both when to use it and how to keep using it.

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