This server provides MCP tools to query FACEIT CS2 player and match data for performance analysis. You can look up players by exact nickname to get their ID and profile, retrieve lifetime statistics (K/D, ADR, win rate, headshot %), browse match history with pagination and custom result limits (up to 100), fetch detailed per-round and per-player stats for a specific match (kills, ADR, KAST, headshots, etc.), and get general match details (teams, players, competition, result). Additionally, it enables analyzing a player's weaknesses by comparing their recent match performance against lifetime averages, and benchmarking a player's single-match stats against a professional player's lifetime averages.
Allows querying FACEIT CS2 stats, including player profiles, lifetime stats, match history, and detailed per-match statistics.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@faceit-mcp What are my lifetime CS2 stats on FACEIT?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Lets Claude query your FACEIT CS2 stats directly (player profile, lifetime stats, match history, per-match detailed stats) so you can ask for real analysis instead of pasting screenshots.
Install dependencies and build:
npm install
npm run buildGet your FACEIT API key (if you don't already have one):
Log in, create an "App" in App Studio
Generate a server-side API key
Add this server to your Claude Desktop config
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS,
or the equivalent on your OS):
{
"mcpServers": {
"faceit": {
"command": "node",
"args": ["/absolute/path/to/faceit-mcp/build/index.js"],
"env": {
"FACEIT_API_KEY": "your-api-key-here"
}
}
}
}Restart Claude Desktop. You should see "faceit" as a connected MCP server.
Related MCP server: faceit-mcp
Claude Desktop runs this server locally over stdio. Claude web can't spawn a
local process, so it needs the server hosted somewhere and reachable over
HTTPS via the MCP Streamable HTTP transport, exposed here at api/mcp.ts.
Deploy this repo to Vercel (or any Node host that runs api/mcp.ts as an
HTTP endpoint).
In the deployment's environment variables, set:
FACEIT_API_KEY — your FACEIT API key
MCP_ACCESS_TOKEN — a secret you generate yourself (e.g. openssl rand -hex 24). Anyone who can reach the URL and knows this token can query
your FACEIT key through the connector, so keep it private.
In claude.ai: Settings → Connectors → Add custom connector, and use
https://<your-deployment>.vercel.app/api/mcp as the URL. If prompted for
auth, use the MCP_ACCESS_TOKEN value as a bearer token
(Authorization: Bearer <token>).
faceit_find_player — look up a player by nickname, get their player_id
faceit_get_player_stats — lifetime CS2 stats (K/D, ADR, win rate, HS%, etc.)
faceit_get_match_history — recent match list for a player
faceit_get_match_stats — full per-round, per-player stats for one match
faceit_get_match_details — teams, competition, result for one match
faceit_analyze_weaknesses — compares a player's last N matches against their own official FACEIT lifetime average for the same stats (K/D, ADR, headshot %, entry success, clutch conversion, utility/flash usage) and flags any that trail their established baseline by 10%+
faceit_analyze_match_vs_pro — analyzes one match and ranks which stat areas trailed a pro/reference player's FACEIT lifetime average (defaults to donk666) by the largest relative margin
This uses FACEIT's free public Data API (open.faceit.com/data/v4). No cost, subject to their standard rate limits.
Your API key lives in your local Claude Desktop config, not in this repo — don't commit it anywhere.
Look up a FACEIT player by their exact nickname to get their player_id and basic profile info. Use this first before other tools that require a player_id.
| Name | Required | Description | Default |
|---|---|---|---|
| nickname | Yes | Exact FACEIT nickname |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the need for an exact nickname and the output (player_id and basic profile info), but does not cover not-found behavior, error handling, or whether the operation is read-only. These gaps are notable for a tool expected to serve as a prerequisite for others.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and output, then usage guidance. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description provides the essential information: what it does, when to use it, and what it returns. It is slightly incomplete regarding the exact shape of 'basic profile info' and error responses, but sufficient for an agent to invoke it correctly as a preliminary step.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the nickname parameter described as 'Exact FACEIT nickname'. The description repeats 'exact nickname' in prose but adds no additional semantic value beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool looks up a FACEIT player by exact nickname to retrieve player_id and basic profile info. It also distinguishes from sibling tools by positioning this as the first step before other player_id-dependent tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this first before other tools that require a player_id' gives clear context on when to invoke this tool. However, it doesn't explicitly state when not to use it (e.g., if player_id is already known), lacking a full exclusion clause.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get general details for a specific FACEIT match: teams, players, competition info, status, results.
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes | FACEIT match_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only retrieval operation via 'Get' and lists what is returned, but it does not discuss potential errors, required permissions, or rate limits. For a simple read tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and resource, then efficiently enumerates the returned content categories. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists the key information categories (teams, players, competition info, status, results), giving the agent a solid sense of what to expect. For a straightforward one-parameter tool, this is sufficiently complete, though it could benefit from noting any distinctive behaviors like optional filters or match state variations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (match_id) with a clear description, so the schema does the heavy lifting. The description adds no extra parameter-level detail, which is acceptable given 100% schema coverage. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('general details for a specific FACEIT match'), clearly distinguishing it from siblings like faceit_get_match_stats by focusing on 'details' rather than 'stats'. It also enumerates key content (teams, players, competition info, status, results), making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool—when you need general match details—but provides no explicit guidance on when not to use it or comparisons to alternatives like faceit_get_match_stats. The positioning as 'general details' offers some differentiation, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's recent CS2 match history (list of match ids, results, timestamps) on FACEIT.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of matches to return | |
| offset | No | Pagination offset | |
| game_id | No | Game id, default 'cs2' | cs2 |
| player_id | Yes | FACEIT player_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It implicitly indicates a read operation and describes the return shape, but omits details like pagination behavior, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the verb and resource. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward list tool, the description covers purpose and return type well. It lacks context on how to use pagination (though limit/offset are in schema) and how the tool relates to sibling tools, but these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning over the schema's parameter descriptions, though it does reinforce what the returned list contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a player's recent CS2 match history, with specific output elements (match ids, results, timestamps) and platform (FACEIT). This distinguishes it from siblings like get_player_stats or get_match_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that match ids could be used with get_match_stats or get_match_details, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed per-round, per-player stats for a specific FACEIT match (kills, ADR, KAST, headshots, rounds, etc). Use a match_id from faceit_get_match_history.
| Name | Required | Description | Default |
|---|---|---|---|
| match_id | Yes | FACEIT match_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of behavioral disclosure. It lists included stats (kills, ADR, KAST, headshots, rounds) but does not mention error handling, rate limits, or confirmation that it is read-only. The verb 'Get' implies a safe read, but more detail could be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with purpose and followed by a practical usage hint. Every word earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with no output schema, the description is mostly complete: it states what the tool returns (stats) and where to get the input. It could be slightly more complete by mentioning failure cases or whether all rounds are included, but overall it adequately covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for match_id is minimal ('FACEIT match_id'), and coverage is 100%. The tool description adds meaningful value by specifying the source of the match_id ('Use a match_id from faceit_get_match_history'), which directly aids the agent in populating the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('detailed per-round, per-player stats for a specific FACEIT match') and scope. It distinguishes from sibling tools like faceit_get_match_details by emphasizing the granular per-round/per-player nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear contextual guidance by telling the agent to use a match_id from faceit_get_match_history, which is a useful prerequisite. However, it does not explicitly state when not to use this tool or name alternative sibling tools for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a player's lifetime CS2 stats on FACEIT (K/D, ADR, win rate, headshot %, etc.) using their player_id.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | No | Game id, default 'cs2' | cs2 |
| player_id | Yes | FACEIT player_id (get via faceit_find_player) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the scope ('lifetime') and hints at the output ('K/D, ADR, win rate, headshot %, etc.'). However, it does not mention behavior on missing players, rate limits, authentication, or return format details beyond the stats list. This is adequate but leaves gaps for robustness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and scope. Every word earns its place: verb, resource, stats examples, and input. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 params, no output schema), the description covers the essentials: what it does and the key input. It does not fully detail the return structure, but the listed stats (K/D, ADR, win rate, headshot %) provide a sufficient overview for an agent to know what to expect. A 4 reflects a small gap in output specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already fully documented. The tool description adds no extra semantic value beyond restating 'player_id'. Per the baseline rule for high coverage, a score of 3 is appropriate; the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get'), the target resource ('a player's lifetime CS2 stats'), and the input ('using their player_id'). It distinguishes itself from sibling tools like match history/stats by focusing on lifetime player stats, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (when lifetime CS2 stats are needed) and specifies the required input ('player_id'). It does not explicitly mention when not to use it or name alternatives, but the pointer in the parameter description to faceit_find_player implies a workflow. Given the absence of explicit alternatives in the description itself, a 4 is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0faceit_find_playerfaceit_get_match_detailsfaceit_get_match_historyfaceit_get_match_statsfaceit_get_player_statsScored across 5 tools
Each tool targets a distinct resource and action: player lookup, player stats, match history, match stats, and match details. The descriptions clearly differentiate match stats (per-round/per-player numbers) from match details (general info), so an agent can reliably choose the right tool.
All tools follow a faceit_<verb>_<noun> pattern with snake_case. The only deviation is 'find_player' using 'find' instead of 'get', but this is minor and the pattern remains predictable across the set.
Five tools is well-scoped for a focused FACEIT CS2 stats server. Each tool covers a necessary lookup or retrieval step without redundancy, and the count is squarely in the ideal 3-15 range.
The tool surface covers the core read-only workflow: finding a player, retrieving their stats, listing match history, and then fetching both summary and detailed stats for a match. There are no obvious dead ends for typical use cases; the missing operations are not essential for this domain.
Steam profiles, SteamID conversion, bans, FACEIT stats, friends and comparisons. Free, no API key.
Teamfight Tactics data & AI coaching for Claude and ChatGPT — 19 tools, built-in Riot key.
Provide detailed Pokémon data and information through a standardized MCP interface. Enable LLMs an…
Live competitive-game predictions, meta data and decision tools for AI agents.