Provides tools for interacting with the Lichess public API, including user profiles, recent games, game analysis, opening statistics, position analysis, daily puzzles, player search, and tournament information.
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., "@lichess-mcp What's DrNykterstein's blitz rating, and is he on a streak right now?"
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.
An MCP server that puts the Lichess public API in front of any MCP-compatible agent, so you can ask about chess in plain language instead of reading JSON.
"How did Magnus do in blitz this week, and what did the engine think of his last loss?"
No API key, no account, no OAuth — every tool here uses Lichess' public endpoints.
Tool | What it answers |
| Ratings in every format, title, country, account stats, current win/loss streak |
| Recent games with PGN, result, opponent, opening and accuracy; filter by format or colour |
| Per-side accuracy and ACPL, plus every blunder/mistake/inaccuracy with the engine's preferred move and the eval swing |
| Win/draw/loss and score% for one opening, for one player, as a given colour |
| Top engine lines for a FEN, from Lichess' cloud evaluation cache, rendered in SAN |
| Today's daily puzzle: FEN, themes, rating, and the solution |
| Autocomplete a half-remembered username |
| Arena or Swiss tournament: time control, player count, games played, standings |
Plus a resource, lichess://api-reference, summarising the endpoints behind each tool, the
rate limits, and the known gaps — so an agent can read the manual instead of guessing.
Raw Lichess payloads bury the result of a game under ninety clock timestamps. Every tool here returns a small dict with obvious keys:
// get_recent_games("DrNykterstein", count=1, format="blitz")
{
"game_id": "kAdOQKeh",
"url": "https://lichess.org/kAdOQKeh",
"played_at": "2026-04-08T19:39:03+00:00",
"format": "blitz",
"time_control": "3+0",
"opening": "Alekhine Defense: Sämisch Attack",
"color": "black",
"result": "win",
"my_rating": 3145,
"rating_change": 8,
"my_accuracy": 93,
"opponent": { "username": "respects_55", "rating": 2644, "accuracy": 89 },
"pgn": "[Event \"Take Take Take Arena\"]\n..."
}Engine lines come back as SAN, because 1... e5 2. g3 Nf6 is legible and e7e5 g2g3 g8f6
is not. Evaluations are normalised so a positive score always favours the side to move, and
forced mates are reported as mate_in rather than a huge centipawn number.
Related MCP server: mcp-server
Requires Python 3.10+.
uvx lichess-mcpor
pip install lichess-mcpAdd this to your claude_desktop_config.json
(macOS: ~/Library/Application Support/Claude/claude_desktop_config.json,
Windows: %APPDATA%\Claude\claude_desktop_config.json), then restart Claude Desktop:
{
"mcpServers": {
"lichess": {
"command": "uvx",
"args": ["lichess-mcp"]
}
}
}If you installed with pip rather than using uvx, point at the installed script instead:
{
"mcpServers": {
"lichess": {
"command": "lichess-mcp"
}
}
}claude mcp add lichess -- uvx lichess-mcp"What's DrNykterstein's blitz rating, and is he on a streak right now?"
→ get_user_profile
"Show me my last 5 rapid games as Black and tell me which openings went badly."
→ get_recent_games, then get_opening_stats
"Pull up today's Lichess puzzle and give me the position — don't tell me the answer yet."
→ get_puzzle_of_day
"Here's a FEN from my game — r1bqkbnr/pppp1ppp/2n5/4p3/2B1P3/5N2/PPPP1PPP/RNBQK2R b KQkq - 3 3. What does the engine want to play?"
→ analyze_position
"Find every blunder in lichess.org/dmvL2duu and explain what each one missed."
→ get_game_analysis
Openings, tournaments and player search work the same way: "How do I score with the Sicilian as White over my last 200 games?", "Who won tournament W1OrjDLM?", "There's a player called something like 'penguin' — find them."
Everything is optional.
Variable | Default | Purpose |
| unset | A personal access token. Raises your rate limit and unlocks your own private data. Nothing here requires it. |
|
| Seconds between requests. Lichess asks for 1 req/sec; lower it only with a token and a good reason. |
|
| Longest 429 back-off to sit out before reporting the rate limit to the caller. |
|
| Per-request timeout in seconds. |
|
| Set to |
Lichess is free, donation-funded, and asks clients for at most one request per second.
This server enforces that globally with an async rate limiter rather than trusting each tool
to behave, and backs off politely on HTTP 429. That means tools which scan many games
(get_opening_stats with a large max_games) are deliberately unhurried.
If you want the whole games database, take it from database.lichess.org, not from this server.
Computer analysis is opt-in on Lichess. get_game_analysis and the accuracy fields
only have data for games where a player requested analysis. Games without it return
analysis_available: false and say so, rather than failing.
analyze_position reads a cache, not a live engine. Lichess' cloud eval covers
positions someone has already analysed — common openings and popular games. Novel
positions return cached: false with an explanation.
get_opening_stats samples recent games. Lichess' personal opening explorer now
requires OAuth, so this aggregates the games export instead. Results describe the last
max_games games (default 200, max 500), not a lifetime total.
Streaks are derived, not fetched — Lichess has no streak endpoint, so
get_user_profile computes the current run from the 30 most recent rated games.
git clone https://github.com/Anay704/lichess-mcp
cd lichess-mcp
python -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/pytest # offline, sub-second
.venv/bin/ruff check .The suite stubs the HTTP layer, so the default run is fast and works offline. A handful of tests that really call lichess.org are opt-in:
LICHESS_MCP_LIVE_TESTS=1 .venv/bin/pytestMIT — see LICENSE.
Not affiliated with or endorsed by Lichess. Lichess is a free/libre, open-source chess server; if you get value out of this, consider donating to them.
Evaluate a chess position given as a FEN using Lichess' cloud engine cache. Returns the top engine lines with evaluations, in readable SAN notation.
| Name | Required | Description | Default |
|---|---|---|---|
| fen | Yes | ||
| lines | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Computer analysis of a single Lichess game: per-player accuracy and average centipawn loss, plus every blunder, mistake and inaccuracy with the move that was played, the engine's preferred move, and the evaluation swing.
| Name | Required | Description | Default |
|---|---|---|---|
| game_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Win/draw/loss breakdown for one player in a specific opening, as a given colour. Scans the player's recent games and aggregates by opening name.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | ||
| format | No | ||
| username | Yes | ||
| max_games | No | ||
| opening_name | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Today's Lichess daily puzzle: the FEN to solve, whose move it is, the puzzle rating, its tactical themes, and the solution in UCI and SAN.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Fetch a player's most recent games with PGN, result, opponent, opening and accuracy. Optionally filter to one time format or one colour.
| Name | Required | Description | Default |
|---|---|---|---|
| color | No | ||
| count | No | ||
| format | No | ||
| username | Yes | ||
| rated_only | No | ||
| include_pgn | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Details and standings for a Lichess arena or Swiss tournament: name, time control, player count, games played, and the leaderboard.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| tournament_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Look up a Lichess player: ratings in every format they play, title, country, account stats, and their current win/loss/draw streak.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | ||
| include_streak | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Autocomplete Lichess usernames from a partial string. Use this to resolve a half-remembered or misspelled username before calling other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| pattern | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0analyze_positionget_game_analysisget_opening_statsget_puzzle_of_dayget_recent_gamesget_tournament_infoget_user_profilesearch_playersScored across 8 tools
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.
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.
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.
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.
MCP server exposing the Backtest360 engine API as tools for AI agents.
Hosted MCP server for live public-data APIs and Skills for AI agents.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
