Crawlora MCP

Official

Overview Schema Source Related Servers Discussions Admin

faceit_competition_matches

Fetch a paginated list of FACEIT competition matches by competition ID and type, with optional player filtering for reviewing match activity.

Instructions

FACEIT competition match list. Returns one page of a competition's match list for a competition id and type. The upstream requires both id and type and rejects a missing type; an unknown id is an empty list. The sampled anonymous response was empty and its non-empty item shape is unverified, so each match is passed through as raw upstream JSON rather than a guessed DTO.

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>",
      "type": "<type>"
    },
    "name": "faceit_competition_matches"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Competition id from faceit-championship-search.
`page`	No	Optional non-negative page number; default 0.
`size`	No	Optional page size, 1-100; default 20.
`type`	Yes	Competition type such as championship; the upstream rejects a missing type.
`player_id`	No	Optional player UUID filter.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.17.20Nov 12, 2026

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 discloses that the upstream rejects a missing type, that an unknown id returns an empty list rather than an error, and that each match is returned as unverified raw upstream JSON. That last point is unusually candid about return-shape uncertainty. It stops short of covering authentication requirements, rate limits, or total-page semantics, so it is not 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?

Four sentences, front-loaded with purpose, then constraints, then the return-format caveat. Every sentence carries information, though the discussion of the sampled anonymous response is slightly verbose for a definition body.

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 the description compensates by explaining that matches come back as raw upstream JSON with an unverified item shape, which is exactly the caveat an agent needs. Pagination is delegated to the schema, which is reasonable given full coverage. Only the absence of auth or rate-limit context keeps it from a 5.

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 the schema already documents id, type, page, size, and player_id, making 3 the baseline. The description reinforces the mandatory pairing of id and type and the consequence of an unknown id, but adds no format, range, or cross-parameter semantics beyond what the schema states.

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 names a specific verb and resource: it returns one page of a competition's match list filtered by competition id and type. An agent can tell this is a paged list read for FACEIT competitions. It does not explicitly differentiate itself from similarly named sibling tools such as vlr_event_matches or opendota_league_matches, which keeps it below a 5.

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: the description establishes that both id and type are mandatory and that an unknown id yields an empty list, which effectively tells the agent the preconditions for a successful call. However, it never says when to prefer this tool over an alternative source of match lists, and the only sibling reference (faceit-championship-search) appears in the schema, not the description.

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

Deploy Server