mcp-server

by SAS-AII

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most chess tools are clearly distinct (stats, matches, analysis by PGN or ID), but the generic 'chess' tool duplicates all their functionality, creating ambiguity about which tool to use. web_search and roll_dice are unrelated and easy to distinguish.
Naming Consistency3/5
web_search and roll_dice use verb_noun pattern consistently. Chess tools mostly follow chess_verb_noun but include exceptions like 'chess_player_stats' (noun_noun) and 'chess_recent_matches' (adjective_noun). The plain 'chess' tool breaks the pattern entirely.
Tool Count3/5
10 tools is a reasonable number, but the inclusion of the redundant 'chess' tool and the mix of unrelated domains (web search, dice, chess) makes the surface feel slightly bloated. Could be streamlined by removing the generic chess tool.
Completeness3/5
The chess subdomain covers stats, recent matches, and PGN analysis well, but lacks features like game archiving or move-by-move play. web_search and roll_dice are single-purpose and complete. Overall the surface is adequate but not deep in any area.
Average 3.4/5 across 10 of 10 tools scored. Lowest: 2.6/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'Run engine analysis' with no information about side effects (e.g., mutating state), rate limits, authorization needs, or output nature (return format, what analysis includes). This is a significant gap for a tool that performs computation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence plus parameter list and example) but somewhat redundant: the example echoes the parameter listing. It is not formatted as a structured specification. Some critical information is omitted (behavior, output). Conciseness is achieved at the cost of clarity.
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?
Although an output schema exists, the description does not state what the analysis returns (e.g., move evaluations, best lines, scores). For a tool that 'runs analysis', the agent needs to know the type and granularity of output. The description leaves the agent to infer from the output schema, but context about the analysis purpose (e.g., depth, limited to recent games) is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning beyond the schema by explaining game_index (which recent game, default 0 is latest) and movetime_ms (time in milliseconds, default 500). The example reinforces usage. However, the explanations are brief and lack format constraints (e.g., range for movetime_ms).
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 'Run engine analysis' and resource 'recent games', with a specific indexing scheme (0 = latest). It distinguishes from siblings like chess_analyze_pgn (PGN input) and chess_analyze_game_id (arbitrary game ID) but does not explicitly state that this tool is limited to the user's own recent games.
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?
No when-to-use or when-not-to-use guidance is given. The description does not compare with sibling tools like chess_analyze_game_id or chess_analyze_pgn, nor does it suggest prerequisites (e.g., must have played recent games). The example only shows parameter values, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention authentication requirements, data freshness, error handling, or any side effects. The description is a single sentence that does not reveal any behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus an example), which is concise but not well-structured. It lacks any breakdown of purpose, usage, or behavior. It earns its place in terms of brevity, but the lack of structure makes it less helpful for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters but an output schema exists, the description should clarify the user context (e.g., authenticated user or requires a username from the environment). It does not mention any prerequisites or the scope of the profile. The description is incomplete for an agent to reliably use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. The description adds minimal meaning beyond the schema by specifying 'profile and ratings summary,' which is slightly more descriptive than just 'stats.' The baseline for 0 parameters is 4, and the description does not detract from that.
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 'Get your Chess.com profile and ratings summary,' which specifies a verb and resource. The word 'your' implies it returns the authenticated user's profile, differentiating it from sibling tools like chess_recent_matches that require a username parameter. However, it does not explicitly state whose profile is fetched, leaving some ambiguity.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Sibling tools like chess_recent_matches and chess_analyze_* are not referenced, leaving the agent to infer appropriate usage without support.
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 provided, so the description carries full burden. It states analysis with Stockfish and mentions a default time per move (500 ms), but does not disclose what 'analyze' means—e.g., whether it returns evaluations, best moves, or a full analysis report. The return format or side effects are not described. The tool modifies no state, but this is implied rather than stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is reasonably concise with a parameter list and example. However, it repeats structural elements (parameter list, example) common to many tools. The example uses placeholders ('...'), which could be more specific. The description could be more compact without losing value.
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 has an output schema (likely describing analysis results), the description does not need to detail return values. However, with no annotations and two parameters (one undocumented in schema), the description leaves some gaps: it doesn't explain what constitutes a valid PGN, error handling, or whether the analysis is synchronous. The example helps but is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists parameters: pgn_string (PGN of the game to analyze) and movetime_ms (time per move, default 500). However, it does not specify the format expected for pgn_string (e.g., must be a full PGN with headers? move text only?), nor the valid range or semantics of movetime_ms (e.g., is it milliseconds? does the engine respect it?). The example is helpful but not enough to fully cover undocumented parameters.
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?
Description clearly states 'Analyze a single PGN string with Stockfish', which pairs a specific verb ('analyze') with a resource ('single PGN string'). It distinguishes from siblings like 'chess_analyze_game_id' (analysis from a game ID) and 'chess_analyze_multiple_pgn' (analysis of multiple PGNs). The purpose is clear and specific.
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 through the example and parameter defaults, but does not explicitly state when to use this tool versus alternatives. For example, it doesn't clarify that this is for a single PGN string, while 'chess_analyze_multiple_pgn' is for multiple. No explicit guidance on excluding other tools.
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 only states 'List your most recent games' and provides a parameter example, but omits details such as authentication requirements, pagination, error handling, or what happens when no games exist. The description adds minimal behavioral context beyond the schema.
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 concise: a one-sentence purpose, a parameter description, and a usage example. Every part is direct and useful. No wasted words, and the structure front-loads the core action.
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 existence of an output schema, the description does not need to detail return values. However, it lacks context about whose recent games are listed (implicitly the authenticated user) and fails to differentiate from the sibling 'chess_player_stats' which also lists recent games. The tool is simple, but the description could be more complete to avoid ambiguity.
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 0%, so the description must compensate. It effectively clarifies the 'limit' parameter with 'Number of games to list (default 5)', which adds meaning beyond the schema's type and default. The example reinforces usage. This is adequate for a single parameter.
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 'List your most recent games,' identifying the verb (list) and resource (games). It distinguishes from sibling 'chess_last_match' (single game) but does not specify that the games belong to the authenticated user, leaving room for confusion with 'chess_player_stats'.
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 offers no guidance on when to use this tool versus siblings like 'chess_last_match' or 'chess_player_stats'. It does not indicate prerequisites (e.g., authentication) or scenarios where an alternative would be better, leaving the agent to infer usage 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?
Since no annotations are provided, the description must carry the burden of behavioral transparency. It only states it searches the web, without disclosing any potential side effects, limitations, required permissions, or data handling. For a read-only tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and direct, with a clear parameter list and a helpful example. It is slightly redundant with the schema's parameter list, but the structure is 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 simplicity of the tool (one parameter, no nested objects), the description is adequate but lacks detail on output format or potential variations in results. The presence of an output schema reduces the need for describing return values, but more context on search behavior would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'query' parameter (coverage=0%), but the description adds minimal value by labeling it as 'the search query' and showing usage in an example. However, it does not specify query formatting, length limits, or special characters.
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 indicates the tool performs web searches for a given query, with a verb (Search) and resource (the web). It is distinguishable from the chess-related sibling tools, but it does not explicitly differentiate itself from potential other search tools.
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 information retrieval via example, but it lacks explicit guidance on when to use this tool versus alternatives or any exclusions. No cautionary notes about scope or limitations 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 full responsibility. It states the purpose but discloses no behavioral traits such as required authentication, side effects, caching, or data recency. For a read-only tool, the lack of transparency is moderate; the description does not confirm safety or scope beyond the basic function.
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: two short sentences, including a functional example. Every word adds value, with no redundancy or fluff. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with an output schema, the description is mostly adequate. However, it does not explain what 'details' encompass or how 'most recent finished game' is determined (e.g., by date, by time control). The sibling tools hint at potential overlap, and the description lacks contextual cues to differentiate further. The example helps but does not fully close the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (trivially). The description adds value by showing an example call with empty parentheses, confirming the parameterless nature. No further clarification is needed, as the schema already exhaustively defines the input.
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 ('Show details') and the specific resource ('your most recent finished game'). It distinguishes from siblings like 'chess_recent_matches' (which likely lists multiple matches) and 'chess_analyze_recent_game' (which implies analysis, not just details). The example reinforces the zero-parameter call.
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?
No explicit guidance on when to use this tool versus alternatives like 'chess_recent_matches' or 'chess_analyze_recent_game'. The description does not mention prerequisites, limitations, or conditions for use. It provides merely an example, which hints at usage but lacks comparative 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 must fully disclose behavioral traits. It only lists action signatures and parameters, with no mention of side effects, authentication, rate limits, or error handling. This is insufficient for a tool with multiple sub-actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear introduction, a list of actions with parameter objects, and examples. It is front-loaded with the preference note. Slightly verbose but each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 sub-actions) and the presence of an output schema, the description covers all necessary invocation details: action names, parameter formats, and a delimiter for multiple PGNs. It is sufficient for correct invocation, though it could mention the output schema briefly.
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 schema has 0% parameter description coverage, but the description compensates by detailing the expected params for each action (e.g., 'limit': int = 5) and providing examples. This adds significant meaning beyond the empty schema. Could be improved by explaining the output schema or constraints.
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 it is a 'Unified Chess tool' and lists the specific actions it supports, distinguishing it from the sibling chess_* tools. However, it is not a single verb+resource but a collection, which slightly reduces clarity.
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?
Explicitly says 'prefer the specific chess_* tools instead,' providing clear guidance on when to use this tool versus the alternatives. It also lists all supported actions, enabling the agent to decide when this unified tool is appropriate.
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 only states the action without disclosing behavioral traits like randomness, error handling, valid notation range, or return format. This is insufficient for a tool with no annotations.
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, a parameter list, and an example. Every element earns its place, and the main action is front-loaded.
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 low complexity and the presence of an output schema, the description is adequate. It covers the basic usage and parameters, though it could be improved by noting that the output is a list of results.
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% description coverage, so the description compensates by explaining 'notation: Dice notation like 2d6+1' and 'num_rolls: Number of times to roll (default 1)'. This adds meaningful context beyond the schema's type and title.
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 'Roll dice with the given notation' using a specific verb and resource. It is distinct from sibling tools, all of which are chess-related, so there is no ambiguity.
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?
While the purpose is clear, the description does not explicitly state when to use this tool versus alternatives or provide exclusions. Since there are no competing dice-rolling tools among siblings, the lack of guidance is less critical, but still missing.
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 must disclose behavioral traits. It reveals that engine analysis occurs per move and defaults to 500ms, but does not state whether the tool is read-only or destructive, rate limits, or any side effects. The example is helpful but limited.
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: one line of purpose, two lines of parameter details, and one example. Every sentence adds value with no redundancy or filler. Front-loaded structure is effective.
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 moderate complexity (2 params, one required) and without annotations, the description covers the essential input semantics. An output schema exists but is not detailed; the description does not explain return format, though it should. Still, it is largely sufficient for an analysis tool.
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 0%, meaning the schema provides no parameter descriptions. The tool description adds significant meaning: it explains the pgn_strings format (supported delimiters) and clarifies movetime_ms as time per move with a default. This compensates well for the schema gap.
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 analyzes multiple PGNs separated by specific delimiters. It distinctly differentiates itself from sibling tools like chess_analyze_pgn, chess_analyze_game_id, and chess_analyze_recent_game by focusing on batch analysis of user-provided PGN strings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear syntax for input format and includes a parameter example, but does not explicitly guide when to use this tool versus chess_analyze_pgn (single PGN) or other analysis tools. It implies usage for batch PGN analysis but lacks when-not-to-use guidance.
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. It discloses the engine used (Stockfish), default move time (500 ms), and the dependent parameter (game_id). It does not, however, specify output format or limits (e.g., max time, engine strength), but given minimal annotation burden, this is sufficient for a simple analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a sentence, parameter list, and example. The example is useful but uses inconsistent quoting (double quotes inside string). Minimal waste, though the parameter list could be integrated into prose for better flow.
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 low complexity (2 params, no nested objects) and presence of an output schema, the description covers input sufficiently. It lacks details on output or edge cases (e.g., invalid game_id), but with an output schema present, return values are documented elsewhere. Adequate for the tool's scope.
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 coverage is 0%, so the description must compensate. It explains game_id as 'UUID or numeric from the game's URL' and movetime_ms as 'Time per move for engine analysis', adding context beyond the schema's basic types and defaults. An example is also provided. The semantic clarity over schema fields is high.
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 analyzes a Chess.com game by game ID using Stockfish, including a specific verb ('analyze'), resource ('Chess.com game by its game ID'), and method ('using Stockfish'). It distinguishes from siblings like chess_analyze_pgn and chess_analyze_recent_game by focusing on game IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus siblings (e.g., chess_analyze_recent_game for recent games, chess_analyze_pgn for PGN data). The context is implied through the parameter focus on game_id, but exclusions or alternatives are absent.
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:

[![aie7-mcp-session-assigment MCP server](https://glama.ai/mcp/servers/SAS-AII/aie7-mcp-session-assigment/badges/card.svg)](https://glama.ai/mcp/servers/SAS-AII/aie7-mcp-session-assigment)

Score Badge

Copy to your README.md:

[![aie7-mcp-session-assigment MCP server](https://glama.ai/mcp/servers/SAS-AII/aie7-mcp-session-assigment/badges/score.svg)](https://glama.ai/mcp/servers/SAS-AII/aie7-mcp-session-assigment)

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/SAS-AII/aie7-mcp-session-assigment'

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