Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

faceit_player

Retrieve a FACEIT player profile by nickname or user ID to get avatar, country, verification status, memberships, and per-game Elo, region, and skill level.

Instructions

FACEIT player profile by nickname or user id. Returns one FACEIT profile: nickname, avatar and cover image, country, verified/registration status, memberships and per-game competitive state (Elo, region, skill level and level label). Exactly one of nickname and user_id is required. The ranking routes accept the user id returned here. A nickname that does not exist is an unknown entity and answers 404; profile friends, streaming ids and linked platform accounts are deliberately not mirrored.

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

Input Schema

NameRequiredDescriptionDefault
user_idNoOptional FACEIT user UUID; exactly one of nickname and user_id is required.
nicknameNoOptional FACEIT nickname; exactly one of nickname and user_id is required.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

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 burden and does well: it discloses the 404 behavior for non-existent nicknames, states the response is a single profile, and explicitly names data that is deliberately not mirrored (friends, streaming ids, linked platform accounts), which prevents false expectations. It stops short of noting auth requirements or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tightly packed sentences, front-loaded with the resource and return shape before the constraint and the exclusion note. No filler and no redundant restatement of the tool name.

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?

There is no output schema, so the description compensates by listing the returned fields (nickname, avatar, cover image, country, verification, memberships, per-game Elo/region/skill level). Combined with the 404 note and the exclusion statement, an agent has everything needed to call and interpret it.

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% and both properties already document the mutually-exclusive requirement, so the description's restatement adds little. The one piece of added value is the note that the returned user id can be fed into the ranking routes, which is a usage hint rather than deeper parameter semantics.

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?

States a specific verb and resource ('FACEIT player profile by nickname or user id') and immediately enumerates the returned fields, so the agent knows exactly what entity comes back. It also distinguishes itself from the ranking tools by noting they consume the user id returned here.

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?

Gives a concrete selection rule ('Exactly one of nickname and user_id is required') and a chaining hint toward the ranking routes that accept the returned user id. It does not explicitly say when a different sibling (e.g. faceit_player_rank) should be preferred over this one, so it stops short of a full when/when-not statement.

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