Lichess MCP

by jamespdaily

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.1.1
Disambiguation5/5
Every tool has a clearly distinct purpose targeting specific actions within the Lichess chess platform, such as game management (abort, resign, make_move), challenge handling (accept, decline, create), and data retrieval (get_user, get_leaderboard). There is no overlap or ambiguity; each tool's function is well-defined and non-redundant.
Naming Consistency5/5
All tools follow a consistent 'lichess_verb_noun' naming pattern with snake_case, such as lichess_accept_challenge and lichess_get_leaderboard. This uniformity makes the tool set predictable and easy to navigate, with no deviations in style or structure.
Tool Count3/5
With 28 tools, the count is borderline high for a chess server, potentially overwhelming for an agent. While it covers many aspects of Lichess, some tools could be consolidated (e.g., multiple puzzle-related tools), making the set feel slightly heavy and less streamlined.
Completeness5/5
The tool set provides comprehensive coverage of the Lichess chess domain, including authentication, game lifecycle (create, move, resign), challenges, puzzles, user data, and real-time streaming. There are no obvious gaps; it supports full CRUD and interactive operations for chess gameplay and account management.
Average 3.7/5 across 28 of 28 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits 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 provided, the description carries the full burden of behavioral disclosure. It states the action and outcome but lacks details on permissions required, rate limits, error conditions, or what happens after acceptance (e.g., game state changes). For a mutation tool with zero annotation coverage, this is insufficient.
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 extremely concise with two sentences that directly convey the tool's purpose and outcome. Every word earns its place, and it's front-loaded with the core action.
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 performs a mutation (accepting a challenge) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, side effects, or response format, leaving significant gaps for an AI agent.
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 description adds no parameter-specific information beyond what the schema provides. With 100% schema description coverage (the 'challengeId' parameter is fully documented in the schema), the baseline score is 3, as the schema does the heavy lifting.
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 clearly states the action ('Accept') and resource ('incoming chess challenge on Lichess'), with a specific outcome ('Start the game with the challenger'). It distinguishes from obvious siblings like 'decline_challenge' but doesn't explicitly differentiate from other challenge-related tools like 'cancel_challenge' or 'create_challenge'.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an incoming challenge), when not to use it, or how it relates to sibling tools like 'decline_challenge' or 'list_challenges' for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the action is for 'active' games, hinting at a precondition, but lacks details on permissions (e.g., if user must be a player/spectator), rate limits, response behavior, or error cases. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence that front-loads the core purpose without waste. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured.
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 no annotations, no output schema, and a mutation tool (sending chat implies write operation), the description is incomplete. It lacks details on behavioral traits (e.g., auth needs, errors), output expectations, and usage context, making it insufficient for reliable agent invocation.
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%, so the schema fully documents parameters (gameId, text, room with enum). The description adds no additional meaning beyond implying 'active' game context, which slightly clarifies gameId usage but doesn't compensate for gaps. Baseline 3 is appropriate as the schema does the heavy lifting.
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 clearly states the action ('send a chat message') and target ('in an active Lichess chess game'), specifying both the recipient scope ('to the player or spectator chat room'). It distinguishes from siblings like 'lichess_make_move' or 'lichess_offer_draw' by focusing on communication, though it doesn't explicitly differentiate from non-existent chat-related siblings.
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?
The description provides minimal guidance: it implies usage during an active game but doesn't specify when to use this tool versus alternatives (e.g., no mention of prerequisites like authentication or game state). No explicit when-not or alternative tools are mentioned, leaving gaps for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the tool retrieves historical rating data but doesn't describe output format (e.g., time-series data, JSON structure), rate limits, error handling (e.g., for invalid usernames), or data freshness. For a read-only tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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, efficient sentence that front-loads the core purpose without unnecessary details. Every word contributes to understanding the tool's function, making it appropriately sized and well-structured for quick comprehension.
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?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally complete but has gaps. It covers what the tool does but lacks details on output behavior, error cases, and usage context. For a simple read operation, this is adequate but not fully informative, aligning with a baseline score.
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 input schema has 100% description coverage, with the 'username' parameter documented as 'Lichess username'. The description adds no additional semantic context beyond this, such as format requirements (e.g., case sensitivity) or examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.
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 clearly states the tool's purpose: 'Get the chess rating history over time for a Lichess player across all time controls'. It specifies the verb ('Get'), resource ('rating history'), and scope ('all time controls'). However, it doesn't explicitly differentiate from sibling tools like 'lichess_get_user' or 'lichess_get_leaderboard', which might also provide rating-related data, preventing a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the username must exist), exclusions, or comparisons to siblings like 'lichess_get_user' (which might include current ratings) or 'lichess_get_leaderboard' (which focuses on rankings). Usage is implied by the purpose but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this requires authentication, if it's idempotent, what happens on invalid challenge IDs, or if there are rate limits—critical for a mutation tool in a gaming API context.
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 perfectly concise—two sentences with zero waste. The first sentence states the core purpose, and the second adds key optional functionality, making it front-loaded and efficient.
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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like authentication requirements, error handling, side effects (e.g., notifying the challenger), or what happens after declining—significant gaps given the tool's role in a real-time gaming system.
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%, so the schema fully documents both parameters. The description adds minimal value by mentioning the optional reason parameter but doesn't provide additional semantics beyond what's in the schema (e.g., explaining enum choices like 'tooFast' vs 'tooSlow').
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 specific action ('Decline an incoming chess challenge') and resource ('on Lichess'), distinguishing it from sibling tools like 'lichess_accept_challenge' and 'lichess_cancel_challenge' which perform different actions on challenges.
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 implies usage context ('incoming chess challenge') but doesn't explicitly state when to use this tool versus alternatives like 'lichess_accept_challenge' or 'lichess_cancel_challenge', nor does it mention prerequisites like needing an active challenge ID from 'lichess_list_challenges'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool fetches a 'next recommended' puzzle based on user data, which implies it's a read operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, or what happens if no puzzle is available. The description is minimal and lacks critical operational details.
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, efficient sentence that front-loads the core purpose ('Get your next recommended Lichess chess puzzle') and adds qualifying details ('based on your puzzle rating and history'). There is no wasted verbiage or redundancy.
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?
Given no annotations, no output schema, and 0 parameters, the description is adequate for a simple read tool but lacks completeness. It doesn't explain return values (e.g., puzzle format, error cases) or behavioral aspects like auth needs, which are important for a tool relying on user-specific data. The description meets minimum viability but has clear gaps.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds context about the recommendation being based on 'puzzle rating and history', which provides semantic insight beyond the empty schema, though this is minimal. Baseline for 0 params is 4.
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 clearly states the verb 'Get' and resource 'next recommended Lichess chess puzzle', specifying it's based on puzzle rating and history. It distinguishes from sibling tools like 'lichess_get_daily_puzzle' (general daily puzzle) and 'lichess_get_puzzle' (specific puzzle by ID) by focusing on personalized recommendations, though it doesn't explicitly name these alternatives.
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 implies usage context ('based on your puzzle rating and history') suggesting it's for personalized recommendations, but doesn't explicitly state when to use this vs. alternatives like 'lichess_get_daily_puzzle' or 'lichess_get_puzzle'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the action ('Request, accept, or decline a takeback') but does not describe key behaviors such as whether this requires specific permissions, if it's rate-limited, what happens if the game is not active, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that front-loads the core functionality ('Request, accept, or decline a takeback') and includes essential context ('undo last move' and 'in an active Lichess chess game'). Every part earns its place with no wasted words, making it highly concise and well-structured.
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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., error conditions, side effects), usage prerequisites, and return values. While the purpose is clear, the overall context for safe and effective use by an AI agent is insufficient.
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%, so the schema already documents both parameters (gameId and accept). The description adds no additional meaning beyond what's in the schema, such as explaining the semantics of 'accept' (e.g., that true can mean either request or accept depending on context) or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 specific action ('Request, accept, or decline a takeback') and resource ('in an active Lichess chess game'), with 'undo last move' providing additional context. It distinguishes this tool from siblings like lichess_make_move (which makes moves) and lichess_offer_draw (which handles draws), as takebacks are a distinct game interaction.
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 implies usage context ('in an active Lichess chess game') but does not explicitly state when to use this tool versus alternatives. For example, it doesn't clarify if takebacks are only available in certain game modes or time controls, or how it relates to tools like lichess_abort or lichess_resign for ending games. The context is clear but lacks explicit exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the tool 'returns' analysis results, implying a read-only operation, but doesn't specify rate limits, authentication needs, data freshness, or error handling. For a cloud-based tool with no annotation coverage, this leaves significant behavioral 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 two sentences with zero waste: the first sentence states the purpose and input, the second specifies the output. It's front-loaded with essential information and appropriately sized for the tool's complexity.
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?
Given no annotations and no output schema, the description adequately covers the basic purpose and output but lacks details on behavioral aspects like rate limits or error cases. For a cloud evaluation tool with two parameters, it's minimally viable but could benefit from more context on usage constraints and result interpretation.
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%, with clear documentation for both parameters (fen and multiPV). The description adds minimal value beyond the schema by mentioning FEN notation and Stockfish analysis, but doesn't provide additional context like FEN validation rules or multiPV impact on performance. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('Get Lichess cloud engine evaluation'), the resource ('for a chess position in FEN notation'), and the output ('Returns the best move, score, and top lines from Stockfish cloud analysis'). It distinguishes itself from sibling tools that focus on game management, challenges, puzzles, and user data rather than position analysis.
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 implies usage for evaluating chess positions via cloud analysis, but provides no explicit guidance on when to use this tool versus alternatives (e.g., local analysis tools or other evaluation methods). It doesn't mention prerequisites, limitations, or exclusions, leaving usage context inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions what data is returned (total games and scores) but lacks details on rate limits, authentication needs, error handling, or data freshness. For a tool with no annotation coverage, this leaves significant gaps in understanding its operational 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 description is front-loaded with the core purpose in the first sentence and adds clarifying detail in the second. Both sentences earn their place by providing essential information without redundancy, making it efficiently structured and easy to parse.
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?
Given the tool's low complexity (2 simple parameters) and no output schema, the description adequately covers the basic purpose and output format. However, it lacks details on behavioral aspects like rate limits or error cases, which are important for a tool with no annotations. This makes it minimally viable but with clear gaps in completeness.
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 input schema has 100% description coverage, clearly documenting both parameters as Lichess usernames. The description adds no additional parameter semantics beyond what the schema provides, such as format constraints or examples. With high schema coverage, the baseline score of 3 is appropriate as the description does not compensate but also does not detract.
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 specific action ('Get the head-to-head record') and resource ('between two Lichess players'), with explicit details on what information is returned ('Shows total games and score for each player'). It distinguishes itself from sibling tools like 'lichess_get_user' or 'lichess_get_my_games' by focusing on comparative player statistics rather than individual data or game lists.
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 implies usage when comparing two players' performance, but it does not explicitly state when to use this tool versus alternatives like 'lichess_get_user' for individual stats or 'lichess_get_my_games' for game details. No exclusions or prerequisites are mentioned, leaving the context somewhat open-ended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions what the tool does but lacks behavioral details like whether this is a read-only operation (implied by 'Get'), rate limits, authentication requirements, or response format. For a tool with no annotations, this leaves significant gaps in understanding operational constraints.
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, efficient sentence that front-loads the core purpose ('Get the Lichess leaderboard') and adds essential context ('top players by rating for a specific time control'). Every word earns its place with zero redundancy.
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?
Given no annotations and no output schema, the description adequately covers the basic purpose but lacks details on behavioral traits, response format, or error handling. For a simple read operation with full parameter documentation in the schema, it's minimally viable but could be more complete by addressing missing operational context.
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%, so the schema fully documents both parameters (nb and perfType) with descriptions, constraints, and enum values. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline for high schema coverage.
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 action ('Get') and resource ('Lichess leaderboard — top players by rating') with specific scope ('for a specific time control'). It distinguishes from siblings like 'lichess_get_user' or 'lichess_get_rating_history' by focusing on leaderboard rankings rather than individual user data or historical trends.
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 implies usage when needing top players by rating for a time control, but doesn't explicitly state when to use this tool versus alternatives like 'lichess_get_user' for individual stats or 'lichess_get_crosstable' for head-to-head comparisons. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the tool retrieves history but doesn't disclose behavioral traits like authentication requirements (implied by 'your'), rate limits, pagination, or response format. For a tool with no annotations, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose. Every word earns its place by specifying the resource and key data points without redundancy or 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?
Given no annotations and no output schema, the description is moderately complete for a simple read operation. It covers the purpose and data scope but lacks details on authentication, rate limits, or return structure, which are important for a tool accessing personal history.
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%, with the single parameter 'max' well-documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline of 3 for high schema coverage.
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 verb 'Get' and the resource 'your Lichess puzzle activity history', specifying what data is retrieved (recent puzzles, results, ratings, themes). It distinguishes from siblings like 'lichess_get_puzzle' (single puzzle) and 'lichess_get_next_puzzle' (next puzzle) by focusing on historical activity.
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 implies usage for viewing personal puzzle history, but doesn't explicitly state when to use this tool versus alternatives like 'lichess_get_rating_history' or 'lichess_get_my_games'. No exclusions or prerequisites are mentioned, leaving some ambiguity about context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool can 'offer, accept, or decline' but does not specify permissions required, rate limits, whether the action is reversible, or what happens after invocation (e.g., game state changes). For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its 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?
Two sentences with zero waste: the first states the core purpose and scope, the second clarifies the dual functionality. It is appropriately sized and front-loaded, with every sentence earning its place by adding clarity without redundancy.
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?
Given the tool's moderate complexity (a mutation in an active game), no annotations, and no output schema, the description is adequate but incomplete. It covers the basic purpose and parameters but lacks details on behavioral aspects like error conditions, side effects, or response format, which are important for a tool that modifies game state.
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%, so the schema already documents both parameters (gameId and accept). The description adds marginal value by implying the accept parameter's dual role for offering/accepting versus declining, but does not provide additional syntax, format, or constraints beyond what the schema states. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Offer, accept, or decline a draw') on a specific resource ('in an active Lichess chess game'), and distinguishes it from siblings like lichess_resign, lichess_abort, and lichess_make_move by focusing on draw-related actions only. The second sentence elaborates on the dual nature of the tool for both proposing and responding to draw offers.
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 implies usage context ('in an active Lichess chess game') and mentions responding to opponent offers, but does not explicitly state when to use this tool versus alternatives like lichess_resign or lichess_abort, nor does it provide exclusions or prerequisites beyond the implied active game requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it states the action (challenge AI), it doesn't mention important behavioral aspects: whether this requires authentication, what happens after the challenge is created (does it start immediately?), what the response format is, or any rate limits. The description is minimal beyond stating the basic purpose.
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, efficient sentence that front-loads the core purpose and lists all configurable aspects. Every word earns its place with zero wasted text, making it easy for an agent to quickly understand the tool's function.
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?
For a tool that creates game challenges (a write/mutation operation) with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after invocation (e.g., does it return a game ID? does the game start automatically?), authentication requirements, or error conditions. The description should provide more context given the tool's complexity and lack of structured metadata.
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%, so the schema already documents all parameters thoroughly. The description mentions the parameters (difficulty level, time control, color, variant) but doesn't add meaningful semantic context beyond what's in the schema descriptions. This meets the baseline expectation when schema coverage is complete.
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 specific action ('Challenge the Lichess AI (Stockfish) to a chess game') and identifies the resource (Lichess AI/Stockfish). It distinguishes this from sibling tools like 'lichess_create_challenge' (which appears to be for human opponents) by specifying it's for AI opponents only.
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 about when to use this tool (to play against the Lichess AI with configurable difficulty and game settings). However, it doesn't explicitly state when NOT to use it or mention alternatives like 'lichess_create_challenge' for human opponents, which would be helpful given the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the action ('cancel') but doesn't mention permissions required (e.g., if you must be the sender), whether the cancellation is reversible, potential side effects (e.g., notifications to the opponent), or error conditions (e.g., invalid challenge ID).
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, efficient sentence that front-loads the core action ('cancel an outgoing chess challenge') without any unnecessary words. It directly communicates the purpose, making it easy to parse and understand quickly.
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?
Given the tool's moderate complexity (a mutation action with no annotations and no output schema), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like permissions, side effects, or return values. For a tool that modifies state, more context would be helpful for safe and correct usage.
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 input schema has 100% description coverage, with the parameter 'challengeId' documented as 'Challenge ID to cancel.' The description doesn't add extra semantic details about the parameter (e.g., format or source), but with high schema coverage, the baseline is 3. Since there's only one parameter, the description's clarity on the tool's purpose indirectly supports parameter understanding, warranting a score of 4.
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 specific action ('cancel'), target resource ('outgoing chess challenge'), and scope ('you sent on Lichess'). It distinguishes this tool from siblings like 'lichess_decline_challenge' (which declines incoming challenges) and 'lichess_abort' (which aborts ongoing games).
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 implies usage context by specifying 'outgoing chess challenge you sent,' which suggests it's for challenges initiated by the user. However, it doesn't explicitly state when to use this tool versus alternatives (e.g., 'lichess_decline_challenge' for incoming challenges) or list any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions the action ('send a game invite') but lacks details on permissions required, rate limits, whether the challenge is revocable, error handling, or what happens upon success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 efficiently conveys the tool's purpose and key parameters without redundancy. It is front-loaded with the main action and includes essential details, making it easy to understand quickly with zero wasted words.
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?
Given the tool's complexity (a mutation with 5 parameters, no annotations, and no output schema), the description is moderately complete. It covers the core action and parameter semantics but lacks behavioral details like error handling, response format, or usage constraints. For a tool that initiates a game challenge, more context on outcomes and limitations would be beneficial.
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 description coverage is 60%, and the description adds meaningful context beyond the schema by explaining that time control includes categories like 'bullet, blitz, rapid, classical, correspondence' and specifying 'color choice' and 'rated or casual', which helps interpret parameters like 'clockLimit' and 'rated'. However, it does not fully cover all parameters (e.g., 'clockIncrement' is only briefly implied).
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 with a specific verb ('challenge'), resource ('a Lichess player'), and details the action ('send a game invite') with key customizable aspects (time control, color choice, rated/casual). It distinguishes itself from sibling tools like 'lichess_accept_challenge' or 'lichess_challenge_ai' by focusing on initiating a challenge to another player.
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 implies usage context by mentioning 'challenge a Lichess player' and specifying parameters like time control and rated/casual, but it does not explicitly state when to use this tool versus alternatives such as 'lichess_challenge_ai' (for AI challenges) or 'lichess_accept_challenge' (for accepting incoming challenges). No exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It mentions what data is returned ('game history including moves, result, opponent, time control, and opening') but lacks details on authentication needs, rate limits, pagination, or error handling, which are critical for a tool fetching user-specific data from an external API.
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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second adding filtering details. Every sentence earns its place without redundancy, making it efficient and easy to parse.
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?
Given no annotations, no output schema, and 3 parameters with full schema coverage, the description is moderately complete. It covers the purpose and basic filtering but lacks details on authentication, rate limits, or return format specifics, which are important for a tool interacting with an external service like Lichess.
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%, so the schema already documents all parameters fully. The description adds minimal value by mentioning filtering by 'color (white/black) or rated/casual', which aligns with the schema but does not provide additional semantics beyond it, meeting the baseline for high coverage.
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 specific action ('Fetch your recent chess games from Lichess') and resource ('chess games'), distinguishing it from siblings like 'lichess_get_my_profile' or 'lichess_get_ongoing_games' by focusing on historical games rather than profile data, current games, or other 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 provides clear context for when to use this tool ('Fetch your recent chess games') and implies usage by mentioning filtering options. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as 'lichess_get_ongoing_games' for current games instead of historical ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only mentions the action ('Play a chess move') and timing ('during a live game'). It omits critical behavioral details like authentication requirements, rate limits, error conditions, or what happens if the move is invalid, leaving significant gaps for an AI agent.
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 front-loaded with the core action and uses two efficient sentences: one for the move mechanics and one for timing. Every sentence adds essential information without redundancy, making it highly concise and well-structured.
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?
Given no annotations and no output schema, the description is incomplete for a mutation tool: it covers the basic action and parameters but lacks details on authentication, error handling, or return values. It's adequate as a minimum viable description but has clear gaps in behavioral context.
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%, so the schema already documents both parameters (gameId and move). The description adds value by explaining UCI notation with examples (e.g., e7e8q for promotion), but doesn't provide additional semantics beyond what the schema covers, meeting the baseline for high coverage.
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 specific action ('Play a chess move'), resource ('in an active Lichess game'), and method ('using UCI notation'), distinguishing it from siblings like lichess_resign or lichess_offer_draw. It provides concrete examples (e.g., e2e4, e7e8q) that reinforce the purpose.
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 specifies context ('during a live game'), implying when to use it versus alternatives like lichess_abort or lichess_resign. However, it lacks explicit exclusions (e.g., not for completed games) or direct naming of sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It states the action ('Resign and forfeit') and outcome ('Concedes the game'), but lacks details on permissions required, irreversible consequences, or error conditions (e.g., if the game ID is invalid). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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 concise sentences with zero waste: the first states the action and resource, and the second clarifies the outcome. It is front-loaded with the core purpose, making it efficient and easy to parse without unnecessary details.
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?
Given the tool's complexity (a simple mutation with one parameter) and lack of annotations or output schema, the description is minimally complete but has gaps. It covers what the tool does but omits behavioral context like error handling or side effects. For a tool with no structured safety hints, more detail would improve completeness.
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%, with the parameter 'gameId' documented as 'Lichess game ID'. The description does not add any meaning beyond this, such as format examples or where to find the ID. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 specific action ('Resign and forfeit') and resource ('an active Lichess chess game'), distinguishing it from siblings like 'lichess_abort' (which ends a game before it starts) and 'lichess_offer_draw' (which proposes a tie). The phrase 'Concedes the game to your opponent' reinforces the outcome, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'an active Lichess chess game', suggesting it should be used during ongoing play rather than for challenges or other states. However, it does not explicitly state when not to use it (e.g., for completed games) or name alternatives like 'lichess_abort' for unstarted games, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 'stream' and 'real-time updates', implying a continuous or event-driven operation, but doesn't disclose critical behavioral traits like whether this is a long-running connection, how updates are delivered (e.g., push vs. poll), error handling, or rate limits. For a streaming tool with zero annotation coverage, this is a significant gap.
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 core purpose and followed by additional details. Every phrase adds value (e.g., specifying 'live board state, moves, and game events' and 'real-time updates including position, clocks, and chat'), with no wasted words or redundancy.
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?
Given the complexity of a streaming tool with no annotations and no output schema, the description is incomplete. It covers the purpose and some outputs but lacks details on behavior (e.g., streaming mechanism, duration), error cases, or return format. This is adequate as a minimum but leaves clear gaps for an agent to operate effectively.
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 description coverage is 100% for the single parameter 'gameId', so the schema already documents it fully. The description doesn't add any parameter-specific details beyond what's in the schema, but with 0 parameters needing extra explanation (since coverage is complete), a baseline of 4 is appropriate as it doesn't detract from 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 clearly states the verb ('stream') and resource ('live board state, moves, and game events for an ongoing Lichess chess game'), with specific details like 'real-time updates including position, clocks, and chat'. It distinguishes from siblings like lichess_stream_events (which likely streams user events) and lichess_get_ongoing_games (which lists games rather than streaming one).
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 implies usage for 'ongoing Lichess chess game', suggesting it's not for completed games, but it doesn't explicitly state when to use this vs. alternatives like lichess_get_ongoing_games or lichess_stream_events. No exclusions or prerequisites are mentioned, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 the tool streams events, implying a real-time, ongoing operation, but does not disclose critical behavioral traits such as whether it's a blocking call, how to stop the stream, error handling, rate limits, or authentication requirements. This is a significant gap for a streaming 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, efficient sentence that front-loads the key action ('Stream incoming Lichess events') and provides specific examples. Every word earns its place with no waste or redundancy.
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 complexity of a streaming tool, no annotations, and no output schema, the description is incomplete. It lacks details on how the stream works (e.g., format, termination, errors), which is crucial for an AI agent to use it correctly. The description does not compensate for the missing structured information.
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 input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description does not add parameter details, which is appropriate. Baseline is 4 for 0 parameters, as it avoids unnecessary information.
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 with a specific verb ('Stream') and resource ('incoming Lichess events'), and distinguishes it from siblings by specifying the types of events (game starts, incoming challenges, correspondence game moves). It's not a tautology and provides concrete details.
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 usage context by specifying what events are streamed, but does not explicitly state when to use this tool versus alternatives (e.g., when real-time updates are needed vs. fetching static data from other tools). It provides clear context but lacks explicit exclusions or named 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 provided, the description carries the full burden. It discloses key behavioral traits: it's a mutation tool (aborting a game), has timing constraints ('first few moves'), and implies it affects game state. However, it lacks details on permissions (e.g., if user must be a player), side effects, or error handling, which are important for a mutation 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 two sentences, front-loaded with the core action, and every word earns its place by specifying timing constraints without redundancy. It efficiently conveys the tool's purpose and limitations in minimal text.
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?
Given no annotations and no output schema, the description is moderately complete for a mutation tool. It covers the what and when, but lacks details on permissions, return values, or error cases. For a tool that modifies game state, more behavioral context would improve completeness.
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%, with the schema fully documenting the 'gameId' parameter. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema handles the parameter documentation adequately.
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 verb 'abort' and the resource 'an active Lichess chess game', specifying it only works 'before it has started properly' and 'in the first few moves'. This distinguishes it from siblings like 'lichess_resign' (ending a game in progress) and 'lichess_cancel_challenge' (canceling a challenge before a game starts).
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 on when to use it ('before it has started properly' and 'in the first few moves'), but does not explicitly state when not to use it or name alternatives. For example, it doesn't clarify if this is for aborting games you created or any game, or contrast with 'lichess_resign' for later stages.
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 discloses the tool fetches public data, which is useful context, but doesn't mention behavioral traits like rate limits, error handling for invalid usernames, or response format. This leaves gaps in understanding how the tool behaves beyond its basic purpose.
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 front-loaded with the core purpose in the first sentence and uses a second sentence to reinforce usage, with zero wasted words. Every sentence earns its place by clarifying the tool's scope and application efficiently.
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?
Given the tool's low complexity (single parameter, no output schema, no annotations), the description is adequate but incomplete. It covers the purpose and basic usage but lacks details on behavioral aspects like response structure or error cases, which would be helpful for an agent to use it correctly without annotations.
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 input schema has 100% description coverage, with the 'username' parameter fully documented. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage without compensating value.
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 specific action ('Get'), resource ('Lichess user's public chess profile, ratings, and stats'), and target ('by username'), distinguishing it from siblings like lichess_get_my_profile (which fetches the authenticated user's data) and lichess_get_leaderboard (which retrieves rankings).
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?
It provides clear context for when to use this tool ('Look up any player on Lichess'), implying it's for public user data. However, it lacks explicit exclusions or alternatives, such as not specifying when to use lichess_get_my_profile instead for authenticated users or lichess_get_crosstable for head-to-head stats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It describes a read-only listing operation but lacks details on permissions needed, rate limits, pagination, or the format of returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its 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 description is front-loaded with the core purpose in the first sentence and adds clarifying detail in the second. Both sentences earn their place by specifying scope and context without any redundant or verbose language.
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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is adequate but incomplete. It explains what the tool does but lacks behavioral details like response format or limitations, which are important for a read operation in a gaming context with potential rate constraints.
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 input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately does not discuss parameters, and since there are none, it meets the baseline of 4 for not introducing unnecessary details.
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 specific action ('List') and resource ('your incoming and outgoing chess challenges on Lichess'), distinguishing it from siblings like 'lichess_accept_challenge' or 'lichess_create_challenge' which perform different operations on challenges. It explicitly mentions both 'pending game invites you have received or sent,' which clarifies the scope beyond just one direction.
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 usage context by specifying 'your incoming and outgoing chess challenges,' indicating it's for viewing personal challenge statuses. However, it does not explicitly state when to use this tool versus alternatives like 'lichess_get_my_games' for ongoing games or provide exclusions, such as not being for modifying challenges.
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 discloses that the tool returns position, solution, and metadata, which is useful behavioral context. However, it does not mention rate limits, authentication needs, or other operational traits, leaving gaps in transparency for a tool with no annotation coverage.
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 efficiently conveys the purpose and output without any wasted words. It is front-loaded with the core action and resource.
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?
Given no annotations, no output schema, and 0 parameters, the description is complete enough for basic understanding but lacks details on output format (e.g., structure of position/solution/metadata) and behavioral aspects like rate limits or errors. It meets minimum viability but has clear gaps in a server with many sibling tools.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a baseline score of 4 for not adding unnecessary information beyond the schema.
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 specific action ('Get today's Lichess daily chess puzzle') and resource ('puzzle of the day'), distinguishing it from sibling tools like 'lichess_get_puzzle' or 'lichess_get_next_puzzle' by specifying it's for the daily puzzle only.
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 usage context ('today's daily chess puzzle') but does not explicitly state when to use this tool versus alternatives like 'lichess_get_puzzle' or 'lichess_get_next_puzzle'. It provides clear context but lacks explicit exclusions or named 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?
No annotations are provided, so the description carries the full burden. It discloses the return content ('board position, moves, theme, and difficulty rating'), which is useful behavioral context. However, it lacks details on error handling (e.g., what happens with an invalid ID), rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.
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 front-loaded with the core purpose in the first sentence and adds return details in the second. Both sentences earn their place by providing essential information without redundancy, making it appropriately sized and efficient.
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?
Given no annotations and no output schema, the description is moderately complete: it covers the purpose and return values but lacks error handling, authentication, or rate limit details. For a simple read operation with one parameter, it's adequate but has clear gaps in behavioral transparency that could hinder agent usage.
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 input schema has 100% description coverage, with the parameter 'id' documented as 'Puzzle ID'. The description adds value by specifying that it's for 'a specific Lichess chess puzzle', providing context beyond the schema's technical definition. With only one parameter, the baseline is high, and this extra semantic detail compensates well.
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 specific action ('Get a specific Lichess chess puzzle by ID') and resource ('puzzle'), distinguishing it from sibling tools like 'lichess_get_daily_puzzle' (which fetches a daily puzzle) and 'lichess_get_next_puzzle' (which likely fetches a random or next puzzle). It explicitly mentions the ID requirement, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'by ID', suggesting it should be used when a puzzle ID is known, unlike 'lichess_get_daily_puzzle' which doesn't require an ID. However, it doesn't explicitly state when not to use it or name alternatives, such as clarifying that 'lichess_get_next_puzzle' is for random puzzles without an ID.
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 discloses that the tool returns profile data, ratings, and stats across time controls, which is useful behavioral context. However, it does not mention potential authentication needs, rate limits, or error conditions, leaving gaps for a tool that likely requires user authentication to access personal data.
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 that are front-loaded with the core purpose and followed by specifics on return values. Every sentence adds value: the first states what is retrieved, and the second details the content, with no wasted words or 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?
Given the tool's complexity is low (no parameters, simple retrieval), no annotations, and no output schema, the description is mostly complete. It explains what data is returned (ratings, username, performance across time controls), but lacks details on authentication requirements or output format, which could be helpful for an agent to use it 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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. A baseline of 4 is applied for zero parameters, as it efficiently avoids unnecessary information.
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 verb 'Get' and the resource 'your Lichess account profile, ratings, and stats', specifying what is retrieved. It distinguishes from siblings like 'lichess_get_user' (which gets another user's profile) by emphasizing 'your' account, and from 'lichess_get_rating_history' (which focuses on historical data) by covering current ratings and stats.
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 usage for retrieving one's own profile data, but does not explicitly state when to use this tool versus alternatives like 'lichess_get_user' for other users' profiles or 'lichess_get_rating_history' for historical trends. It provides clear context (your account) but lacks explicit exclusions or named 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 provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's function and output format ('Lists all games... including board position and whose turn it is'), but lacks details on authentication requirements, rate limits, or error handling. It doesn't contradict annotations, but could be more comprehensive given the absence of structured metadata.
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 perfectly concise and front-loaded: the first sentence states the core purpose, and the second adds essential output details. Every sentence earns its place with no wasted words, making it easy for an AI agent to quickly understand the tool's function.
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?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is largely complete—it explains what the tool does and what information it returns. However, it could improve by mentioning authentication needs or rate limits, which are relevant for API tools. The absence of an output schema is partially mitigated by the description's details on return values.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately focuses on the tool's purpose and output without redundant parameter details, earning a high baseline score. It adds value by explaining what the tool returns, compensating for the lack of an output schema.
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 specific action ('Get your currently active or in-progress chess games') and resource ('on Lichess'), distinguishing it from siblings like 'lichess_get_my_games' (which likely retrieves completed games) and 'lichess_stream_game' (which streams a specific game). It precisely defines scope with 'currently active or in-progress' and includes details like board position and turn information.
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 for when to use this tool ('Get your currently active or in-progress chess games'), implying it's for real-time game status rather than historical data. However, it does not explicitly state when not to use it or name alternatives (e.g., 'lichess_get_my_games' for past games), which prevents a perfect score.
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 of behavioral disclosure. It describes the tool's purpose and output ('return account info'), but does not specify what 'account info' includes, whether it requires prior authentication, or any rate limits or error conditions. This leaves gaps in behavioral understanding for a tool that interacts with authentication status.
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 concise sentences that are front-loaded with the core purpose and followed by usage guidance. Every word adds value without redundancy, making it efficient and easy to parse.
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?
Given the tool's moderate complexity (authentication status check), no annotations, and no output schema, the description is somewhat complete but lacks details on what 'account info' includes, potential error responses, or prerequisites. It covers purpose and usage well but falls short on full behavioral context needed for robust agent interaction.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage. This meets the baseline for tools with no parameters.
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 specific action ('Check if you are authenticated') and resource ('Lichess'), distinguishing it from sibling tools like 'lichess_auth_start' (which initiates authentication) and 'lichess_get_my_profile' (which retrieves profile details). It explicitly mentions returning 'account info' to verify login status and confirm the connected account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'to verify login status or confirm which Lichess chess account is connected.' This provides clear context for its purpose, distinguishing it from other authentication-related tools like 'lichess_auth_start' (for starting authentication) and profile tools like 'lichess_get_my_profile' (for detailed profile data).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 effectively describes key behaviors: it initiates an OAuth flow, opens a browser for user interaction, and is used for authentication purposes. However, it does not mention potential side effects like requiring user interaction, timeouts, or error handling.
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 highly concise and front-loaded, with two sentences that directly explain the tool's function and usage without any wasted words. Each sentence adds essential information about the OAuth flow and its purpose.
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?
Given the tool's complexity (authentication flow with browser interaction) and lack of annotations or output schema, the description is mostly complete but could benefit from mentioning what happens after authorization (e.g., token storage) or error scenarios. It adequately covers the core purpose and mechanism.
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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately does not discuss parameters, as none exist, and instead focuses on the tool's action and purpose.
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 specific action ('Start the Lichess OAuth login flow') and resource ('Lichess chess account'), distinguishing it from sibling tools like 'lichess_auth_status' which checks authentication status rather than initiating it. The mention of 'Opens a browser for authorization' adds concrete implementation detail.
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 for when to use this tool ('to connect, sign in, or authenticate your Lichess chess account'), but does not explicitly state when not to use it or name alternatives like 'lichess_auth_status' for checking existing authentication. The guidance is sufficient but lacks explicit exclusions.
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/jamespdaily/lichess-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jamespdaily/lichess-mcp)

Score Badge

Copy to your README.md:

[![lichess-mcp MCP server](https://glama.ai/mcp/servers/jamespdaily/lichess-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jamespdaily/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/jamespdaily/lichess-mcp'

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