Skip to main content
Glama
Crawlora MCP

Crawlora MCP

Official

faceit_fpl

Fetch FACEIT Pro League circuits and filter by game to access circuit IDs, regions, season windows, ranking source, and paginated results.

Instructions

FACEIT Pro League circuits. Returns FPL (FACEIT Pro League) circuits, optionally filtered to one game: circuit id, game and region, display name, default flag, season windows with start and end timestamps, and the configured ranking source. An unknown game is a valid empty list. Paging uses limit and offset and the response reports has_more.

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_fpl"
  }
}

Input Schema

NameRequiredDescriptionDefault
gameNoOptional game slug, one of the values returned by faceit-games.
limitNoOptional page size, 1-100; default 20.
offsetNoOptional non-negative row offset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.8/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 a solid job: it discloses that an unknown game yields a valid empty list rather than an error, that paging is limit/offset based, and that the response carries a has_more flag. It does not explicitly state read-only/safe semantics or rate-limit/auth behavior, which keeps it below 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?

Three sentences, front-loaded with the resource and the optional filter, then the returned field list, then edge-case/paging semantics. Dense and free of filler, though the long inline field enumeration is slightly dense and could be bulleted for faster scanning.

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?

No output schema exists, so the description takes on the return-value burden and discharges it by listing the fields returned. Combined with the empty-result and pagination notes, an agent has nearly everything needed to call this correctly; only safety/auth semantics are absent, which is minor for a read-only list endpoint.

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; the description adds genuine meaning on top — that 'game' is an optional filter whose unrecognized value returns an empty list, and that limit/offset drive paging with has_more in the response. The enumeration of return fields also clarifies what the filter affects.

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 uses a specific verb and resource ('Returns FPL (FACEIT Pro League) circuits') and enumerates exactly what comes back: circuit id, game/region, display name, default flag, season windows, ranking source. An agent can tell this is a circuit-listing endpoint rather than a match/player/leaderboard tool. It stops short of naming a sibling to contrast against, so it lands at 4 rather than 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?

It implies usage ('optionally filtered to one game') and explains the paging contract, which is real operational guidance. However, it never states when to prefer this tool over other FACEIT listing tools, nor any prerequisite for the game slug beyond a parenthetical pointer to 'faceit-games'. Usage is inferable but not spelled out.

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