Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

hltv_player

Retrieve a Counter-Strike player's public HLTV profile by numeric ID, including nickname, real name, country, age, team, and role-rating scores.

Instructions

Get a Counter-Strike player profile. Returns one player's public HLTV profile by numeric id: nickname, real name, country, age and date of birth when published, canonical URL, current team (id, name, logo) when the player is on a team, and the role-rating rows HLTV shows (Rating 3.0 plus Firepower, Entrying, Trading, Opening, Closing, Sniping and Utility scored out of 100). The trailing slug is cosmetic and optional; HLTV resolves the player by id.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
idYesHLTV numeric player id
slugNoCosmetic player slug; HLTV resolves the player by id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does substantial work: it enumerates the returned fields, flags conditional fields ('age and date of birth when published', 'current team ... when the player is on a team'), and explicitly defuses the slug parameter by calling it cosmetic. It does not describe failure behavior for an unknown id or any rate-limit/caching characteristics, which keeps it below a 5.

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 purpose is front-loaded in the first clause, and the remainder is dedicated to return contents rather than filler. The long enumeration of role-rating rows is dense but earns its place given the absence of an output schema; a slightly tighter phrasing would improve it.

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?

There is no output schema and no annotations, so the description must cover both behavior and return shape, and it does so thoroughly for a simple read-only lookup. The remaining gap is error handling for invalid or missing ids, which matters for a by-id fetch but is not addressed.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description's note that the slug is cosmetic and optional and that 'HLTV resolves the player by id' reinforces the schema meaning but largely restates the schema's own wording rather than adding new constraints or formats.

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

Purpose4/5

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

The description opens with a specific verb and resource ('Get a Counter-Strike player profile') and immediately narrows the scope to 'one player's public HLTV profile by numeric id'. That is unambiguous against the domain-level siblings (hltv_team, hltv_match), but it never names an alternative or states the lookup-vs-search distinction explicitly, so it stops short of full sibling differentiation.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer this is the single-player lookup keyed by id, and the closing sentence usefully clarifies that the id alone is sufficient. There is no explicit when-to-use, when-not-to-use, or pointer to hltv_search for discovering an id, which is the main practical gap for a by-id fetch tool.

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