Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

hltv_match

Fetch a Counter-Strike match by HLTV match ID to get both teams, live or final score, event details, map veto and per-map scores, lineups, and total and map stat scoreboards.

Instructions

Get a Counter-Strike match detail page. Returns one HLTV match by numeric id: both teams with ids, logos and series score; status (finished, live or upcoming); scheduled date in UTC; format (bo1/bo3/bo5), LAN flag and stage from the veto summary; the event id/name/URL; the full map list with per-map score, winner, picked_by, regulation and overtime halves, and the per-map stats page id; the map veto in order (picked, removed or left over); both lineups with player ids, nicknames, real names and roles; the match-total scoreboard stats; and map_stats scoreboards for the captured maps. The trailing slug is cosmetic and optional; HLTV resolves the match 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_match"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesHLTV numeric match id
slugNoCosmetic match slug; HLTV resolves the match 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, the description carries the full burden, and it discloses the payload in unusual depth — teams, status, date in UTC, format, veto, per-map halves and stats ids, lineups, scoreboards. It also clarifies that the slug is optional and HLTV resolves by id, which prevents a plausible misuse. It doesn't cover failure behavior for an unknown id, which keeps it from 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?

Purpose is front-loaded in the first short sentence, followed by a dense enumeration of return fields. The second sentence is long but every clause maps to real payload content that has no output schema to carry it, so the length is largely earned rather than padded.

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?

For a two-param detail fetch with no output schema, the description is nearly complete: it effectively serves as the return-value contract and disambiguates the optional slug. The only material gap is behavior on a missing or malformed id, which an agent would otherwise have to discover by trial.

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%, so both parameters are already documented, and the description largely restates that (id is numeric, slug cosmetic/optional). That restatement is helpful confirmation but adds no new syntax, format, or validation meaning beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource ('Get a Counter-Strike match detail page', 'Returns one HLTV match by numeric id'), which cleanly separates a single-match detail fetch from list-style siblings like hltv_matches. It never names an alternative explicitly, so it stops short of a 5, but the scope is unambiguous.

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 only implied: the 'by numeric id' framing tells the agent this requires an HLTV match id it already holds, and the note that slug is cosmetic signals the id is the real key. There is no explicit when-to-use vs hltv_matches/hltv_event guidance, no prerequisites, and no exclusions.

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