Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

faceit_user_skills

Retrieve FACEIT competitive skills for up to 10 players in one game, including Elo, skill level, ranked matches, latest Elo delta, win streak, pro flag, and expiration timestamp.

Instructions

FACEIT player skills for up to 10 users in one game. Returns competitive skill entries for a bounded batch of up to 10 players in one game: Elo value, skill level, ranked match count, latest Elo delta, current win streak and the professional-player flag, plus the upstream skill expiration timestamp. Duplicate ids are collapsed and unknown users are omitted, so the entries list can be shorter than the request and is a valid empty result when no player has skill data. The upstream requires exactly one game per request and returns entries in its own order.

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": {
      "user_ids": "<user_ids>",
      "game": "<game>"
    },
    "name": "faceit_user_skills"
  }
}

Input Schema

NameRequiredDescriptionDefault
gameYesGame slug, one of the values returned by faceit-games.
user_idsYesRequired FACEIT user UUIDs; repeat the parameter for up to 10 users.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.1/5.0
Behavior5/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 so well: it discloses return fields (Elo, skill level, ranked match count, latest delta, win streak, pro flag, expiration timestamp), dedup behavior, omission of unknown users, the valid empty result, and that ordering follows the upstream rather than the request.

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 operation and followed by result shape and edge cases; every clause carries information. Slight redundancy in restating 'bounded batch of up to 10 players in one game' and a somewhat dense final sentence keep it below top marks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter, read-only lookup with no output schema and no annotations, the description supplies everything an agent needs: field-level result contents, cardinality limits, dedup/omission semantics, empty-result validity, and ordering guarantees.

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, and the description adds real meaning: user_ids is a bounded batch of at most 10 with duplicates collapsed and unknowns dropped, and game must be exactly one slug per request. That goes beyond the schema text, which only says 'repeat the parameter for up to 10 users'.

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, resource and scope: 'FACEIT player skills for up to 10 users in one game', and the second sentence enumerates the returned fields. No sibling in the catalog also returns player skill data, so the operation is easy to place, but it never explicitly distinguishes itself from any named alternative.

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 agent can infer this is the call for fetching skill/Elo data for a set of players, and 'the upstream requires exactly one game per request' hints that multi-game lookups need separate calls. There is no explicit when-to-use, when-not-to-use, or prerequisite guidance.

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