Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

faceit_championship_search

Search FACEIT championships and leaderboards by game, status, country, or entity type to discover championship IDs and ranking data.

Instructions

Discover FACEIT championships and leaderboards. Returns leaderboard discovery rows, which are the anonymous way to discover championship ids: leaderboard identity, entity id/type, game and region, season, group/round/bracket placement, ranking type, scoring fields, dates, status and prize metadata. Defaults to ongoing championships. status is a closed enum (see faceit-leaderboard-statuses); entity_type and type are forwarded as filters and are not server-validated. The upstream caps a page at 100 rows.

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": "faceit_championship_search"
  }
}

Input Schema

Name	Required	Description
`game`	No	Optional game slug, one of the values returned by faceit-games.
`type`	No	Optional leaderboard type; defaults to championship and normally equals entity_type.
`limit`	No	Optional page size, 1-100; default 25.
`offset`	No	Optional non-negative row offset.
`status`	No	Optional status, one of ONGOING, UPCOMING or FINISHED; defaults to ONGOING.
`country`	No	Optional two-letter ISO country code such as DE.
`subtype`	No	Optional leaderboard subtype filter.
`has_drops`	No	Optional drops filter.
`entity_type`	No	Optional entity type; defaults to championship. Documented values: championship, hub, tournament, league, club, matchmaking.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

TDQS

A4.3/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 does well: it discloses the default filter (ONGOING), that status is a closed enum validated server-side while entity_type and type are merely forwarded and unvalidated, and that the upstream caps a page at 100 rows. It omits auth/rate-limit behavior and whether offset paging beyond the cap is truncated, but the operational caveats it does give are unusually valuable.

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 sentence and constraints follow in descending importance. The enumerated list of returned row fields is long but functional, letting an agent judge whether this tool answers its question; only that list could be trimmed slightly.

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 9-parameter tool with no output schema and no annotations, the description does the heavy lifting: it describes the shape of returned rows, states defaults, flags unvalidated filters, and explains the pagination ceiling. What remains thin is guidance on combining filters and on what an empty result means.

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 real meaning beyond the schema: the ONGOING default, the warning that entity_type and type pass through unvalidated, and the referral to faceit-leaderboard-statuses for valid status values. Combined with the 100-row page cap tied to limit/offset, this exceeds the baseline.

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?

The description opens with a specific verb and resource ('Discover FACEIT championships and leaderboards') and immediately clarifies the tool's role as an id-discovery endpoint ('the anonymous way to discover championship ids'), which distinguishes it from the singular faceit_championship detail tool. An agent knows exactly what this returns without opening the schema.

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?

It establishes the discovery-then-detail workflow by framing the output as the way to obtain championship ids, and states the default scope (ongoing championships). It does not explicitly name faceit_championship as the follow-up call or state when to prefer status=UPCOMING/FINISHED, so guidance is clear but not fully prescriptive.

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

Deploy Server