lichess-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct purpose: user profile, player search, recent games, game analysis, opening stats, daily puzzle, position evaluation, and tournament info. There is no overlapping functionality or ambiguity between tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern: get_* for retrieval, search_players for search, and analyze_position for analysis. The verbs are clear and the nouns are specific, making the naming predictable and uniform.
Tool Count5/5
With 8 tools, the set is well-scoped for a chess data server. It covers core Lichess features without feeling bloated or sparse, and each tool contributes a necessary capability.
Completeness4/5
The tool set covers the main read-only Lichess workflows: user profiles, game retrieval, analysis, openings, puzzles, positions, and tournaments. Minor gaps exist, such as no direct way to fetch a user's full game history or a specific game by ID, but these can be worked around via recent games and analysis.
Average 3.7/5 across 8 of 8 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions scanning recent games and aggregating by opening name, which adds some context. However, it implies that opening_name and color are required ('specific opening', 'given colour') while the schema marks them optional, creating ambiguity. It also does not disclose how 'recent' is determined or how missing/empty stats are handled.
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?
The description is very concise: two sentences, no fluff. The first sentence states the core function, and the second adds a brief note on how it works. All content is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and a 0% schema coverage, the description is insufficient. It covers the basic purpose but leaves out important context about optional filters, interpretation of 'recent games', and potential edge cases. While the output schema exists and mitigates the need to describe return values, the description still omits guidance on how to use format and max_games.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It partially explains the meaning of username, opening_name, and color, but completely omits format and max_games, which the schema leaves unexplained. The description's mention of 'specific opening' conflicts with the schema's optional opening_name, and it does not clarify the role of max_games or format filters.
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?
The description clearly states the tool's purpose: 'Win/draw/loss breakdown for one player in a specific opening, as a given colour.' It specifies a specific resource (opening stats) and a precise verb (breakdown), and it distinguishes from sibling tools like get_recent_games by focusing on aggregated results per opening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool vs alternatives. The description only implies usage through its purpose, but does not mention any exclusions or sibling alternatives. For example, it does not clarify when to use get_opening_stats instead of get_recent_games or get_game_analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 read-only nature via 'Fetch' and lists the return data, giving a basic sense of behavior. However, it omits details about authentication requirements, pagination, rate limits, or error handling, leaving gaps in behavioral transparency for a networked API tool.
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?
The description is a single, efficiently structured sentence that front-loads the core action and target, then lists the key return fields and optional filters. There is no redundant wording or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has six parameters with zero schema descriptions and no annotations, the one-sentence description is too sparse to provide complete context. While an output schema exists and relieves the need to explain return values, the parameter semantics and operational constraints remain largely undocumented, making this incomplete for confident tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description is the only source of parameter meaning. It explains that 'format' and 'color' are optional filters, but it does not mention 'username', 'count', 'rated_only', or 'include_pgn', leaving the agent to guess from their names. This is insufficient for a six-parameter tool.
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 the specific verb 'Fetch' with a clear resource ('a player's most recent games') and enumerates the returned fields (PGN, result, opponent, opening, accuracy), making the tool's purpose clear. However, it does not explicitly differentiate from sibling tools like get_game_analysis, so it lacks the sibling contrast seen in higher-scoring examples.
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?
The primary use case is evident: fetching a player's recent games with selected data, and the optional filters for format and color imply when to use those variations. There is no explicit guidance on when not to use this tool or which sibling to choose instead, but the description provides sufficient context for a straightforward fetch operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of describing behavior. It lists the information returned, which is helpful, but it does not explicitly state that this is a read-only operation or mention any prerequisites or limitations. It is adequate but not rich in behavioral detail.
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?
The description is a single, well-structured sentence that front-loads the core purpose and then lists concrete data points. Every word contributes value, and it is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description explains its main output. However, the 'top' parameter is not explained, and the description does not clarify the role of the tournament ID beyond the schema's name. The existence of an output schema covers return structure but not parameter semantics, leaving a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for parameter meaning. It does not mention 'tournament_id' or 'top' at all, leaving the purpose of 'top' unclear. The description lists return fields but nothing about inputs.
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?
The description clearly states the tool provides 'Details and standings for a Lichess arena or Swiss tournament' and lists specific data (name, time control, player count, games played, leaderboard). This distinguishes it from sibling tools about players, games, puzzles, and analysis, so the purpose is unambiguous.
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?
The description gives clear context that this is the tool for tournament details and standings. It does not explicitly name alternatives or exclusion criteria, but its scope is distinct from the sibling tools, making when to use it clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It describes the returned data in detail but does not mention whether the game must already be analyzed, whether it triggers on-demand engine analysis, or any error/edge cases. The description implies a read-only analysis but does not explicitly state side-effect-free behavior.
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?
The entire description is one sentence that efficiently packs all key output details without redundancy. Each clause contributes new information, making it very concise and well-structured.
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?
With one parameter and an output schema available, the description gives a solid overview of the tool's purpose and result content. However, it omits usage caveats (e.g., game must be finished, may require existing analysis) and fails to explicitly differentiate from sibling tools, leaving some completeness gaps.
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?
The schema has no description for game_id (0% coverage), so the description must add meaning. It mentions 'single Lichess game', which implies game_id is the game ID, but it does not specify format or how to obtain it. This adds partial but insufficient semantics for full parameter understanding.
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?
The description uses the specific verb 'get' with resource 'game analysis', and clearly specifies it applies to a single Lichess game. It enumerates the analysis contents (accuracy, centipawn loss, blunders/mistakes/inaccuracies) and thus distinguishes itself from sibling tools like analyze_position or get_opening_stats.
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?
The description provides clear context that this is for analyzing a single completed game, but it does not explicitly state when to use it versus alternatives like analyze_position or get_opening_stats. There are no direct exclusion or alternative recommendations, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 mentions 'cloud engine cache' suggesting a read-only query, but does not disclose potential rate limits, authentication needs, error behavior for invalid FENs, or whether results are cached/network-dependent. This is moderate transparency, but gaps remain.
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?
Two concise sentences with no fluff. The first sentence front-loads the core action and resource, and the second specifies the output format. Every word earns its place.
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?
The tool is simple (2 params) and has an output schema, so the description need not explain return values in detail. It covers the input format, the analysis engine, and the output style. The only notable omission is clarification of the 'lines' parameter, but that is minor given the schema and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the description does not explicitly map parameters. 'fen' is covered implicitly ('given as a FEN'), but the 'lines' parameter is not explained at all. The description adds minimal value beyond the schema, leaving the optional parameter ambiguous.
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?
The description uses a specific verb 'Evaluate' and identifies a clear resource (a chess position in FEN) and method (Lichess' cloud engine cache). It also states the output (top engine lines with evaluations in SAN notation). This clearly distinguishes it from siblings like get_game_analysis or get_opening_stats, which target different resources.
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?
The description implies the use case: when you have a FEN and need engine analysis. It provides clear context but does not explicitly mention when not to use the tool or name alternative tools. It lacks exclusions, but the context is strong enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It lists the return fields but does not disclose error behavior, rate limits, or the effect of the include_streak parameter. It adds moderate value beyond the title.
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?
The description is a single, front-loaded sentence that efficiently lists what is returned without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup with an output schema, the description covers the main purpose and key fields, but misses guidance on when to use it and parameter nuances, and lacks any error handling context. It is adequate but not thorough.
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 coverage is 0%, so the description must compensate. It explains what username refers to via context, and mentions the streak which relates to include_streak, but does not explicitly describe the boolean parameter or its effects.
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?
The description clearly states the tool looks up a Lichess player and lists specific data returned (ratings, title, country, account stats, streak), distinguishing it from search_players and other tools.
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?
The description clearly implies usage for looking up an existing player's profile, but does not explicitly mention when to prefer this over search_players or other alternatives. Context is clear, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions the core autocomplete behavior and the 'partial string' input, but does not address potential details like result limits, ordering, case-insensitivity, or error cases. For a simple read-only search, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every sentence adds value. The usage guidance is integrated efficiently without redundancy.
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?
This is a simple search tool with two parameters and an output schema. The description covers the essential purpose and usage context. While it omits behavioral details like limit semantics, the output schema likely documents return values, so the overall description is reasonably complete for the tool's complexity.
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 0%, so the description must compensate. It explains that 'pattern' is a partial string, adding meaning beyond the schema. However, 'limit' is left completely unexplained; the schema only shows it is an integer with a default of 10. This partial compensation warrants a middle score.
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?
The description clearly states a specific verb+resource: 'Autocomplete Lichess usernames from a partial string.' This distinguishes it from sibling tools like get_user_profile and get_recent_games, which focus on retrieving data, not search.
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?
The description provides clear context: 'Use this to resolve a half-remembered or misspelled username before calling other tools.' This explicitly tells the agent when to use it, though it does not mention when not to use it or name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It lists the output fields, which is helpful, but it does not mention authentication requirements, rate limits, or timezone dependence for 'today.' These are not critical for a simple read-only tool, but the lack of any discussion of behavior beyond the content leaves gaps.
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?
The description is a single, information-dense sentence that front-loads the core purpose ('Today's Lichess daily puzzle') and then enumerates the returned components. Every word earns its place, with no wasted verbiage.
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?
For a simple, parameterless tool with an output schema, the description covers the essential contents. The only notable gap is the lack of timezone specificity for 'today,' which could affect interpretation. Overall, it is sufficiently complete for an agent to select and invoke the tool correctly.
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?
The tool has zero parameters, and the schema confirms an empty object. The baseline for 0 parameters is 4, and the description does not need to explain parameter details since there are none. No additional parameter semantics are required.
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?
The description clearly identifies the tool's function: retrieving Lichess's daily puzzle. It specifies the exact contents returned (FEN, side to move, rating, themes, solution in UCI/SAN), which also distinguishes it from all sibling tools that focus on users, games, or analysis.
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?
The purpose is self-evident: use this when you need the daily puzzle. No explicit comparison to alternatives is given, but since no sibling tool offers puzzle data, the unique scope serves as implicit guidance. It lacks explicit exclusions but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![lichess-mcp MCP server](https://glama.ai/mcp/servers/Anay704/lichess-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Anay704/lichess-mcp)

Score Badge

Copy to your README.md:

[![lichess-mcp MCP server](https://glama.ai/mcp/servers/Anay704/lichess-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Anay704/lichess-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Anay704/lichess-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server