Skip to main content
Glama
Sign In

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

opendota_pro_players

Read-only

Searches OpenDota's public pro-player roster by optional team_id from opendota_teams and case-insensitive q across player/team names, tags and country codes; if both filters are supplied, both must match. limit defaults to 50 (maximum 100); offset defaults to 0 and next_offset continues the filtered list. The 5 MB upstream roster is cached in process for six hours. Account IDs, Steam IDs, profile URLs and avatars are omitted.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "opendota_pro_players"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoOptional case-insensitive substring search across player/team names, team tags and country codes; maximum 200 characters.
limitNoOptional local page size, default 50, maximum 100.
offsetNoOptional zero-based local offset, default 0.
team_idNoOptional positive team ID from opendota_teams; filter players associated with this team.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, yet the description adds substantive context: the 5 MB upstream roster is process-cached for six hours, pagination advances via next_offset, and account IDs, Steam IDs, profile URLs and avatars are deliberately omitted from results. These are non-obvious behavioral traits an agent would otherwise have to discover by calling the tool.

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 core purpose, filter semantics, pagination, caching and omission notes are all packed efficiently, with scope stated first. It's dense and slightly overpacked in one run-on sentence, but no sentence is wasted.

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?

An output schema exists, so return-shape explanation isn't required, and the description still covers the things the schema can't: cache lifetime, filter combination, pagination continuation, and field omissions. Nothing material is missing for correct invocation.

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 schema baseline is 3. The description adds value beyond it by stating the AND-combination rule for team_id and q, and by stating that next_offset continues the filtered list rather than the unfiltered roster. That extra meaning justifies a 4.

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 ('Searches OpenDota's public pro-player roster') and names the exact filtering surface (team_id from opendota_teams, q across player/team names, tags, country codes). This is clearly distinguishable from siblings like opendota_team_players or opendota_teams, which the description implicitly references as the source of team_id.

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 specifies the key semantics for combining filters ('if both filters are supplied, both must match') and notes that team_id must come from opendota_teams, which is practical routing guidance. It stops short of explicitly saying when to prefer this over opendota_team_players, so it earns a 4 rather than a 5.

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

All Crawlora MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources