Reports which chess engine is active (local Stockfish or Lichess cloud fallback), its location, and cache statistics to help troubleshoot analysis issues.
Report which chess engine the server is using (local Stockfish or Lichess cloud fallback), where it lives, and cache statistics. Useful for troubleshooting.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this is a safe, non-mutating read, so the description only needs to add context. It contributes by disclosing that the payload covers engine identity, filesystem location, and cache statistics, but says nothing about whether the result reflects live state, whether the fallback can be switched, or any cost/latency of the check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the primary fact (which engine is active) and back-loaded with the secondary detail (location, cache stats) and the usage hint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, no parameters, and a read-only annotation, the description carries only what structured data cannot: that this is a diagnostics call and what categories of information it surfaces. That is sufficient for an agent to decide to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, which is the baseline-4 case; the description correctly implies a no-argument global query rather than promising any filtering options. Nothing further is needed on this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Report") and a precise resource (the active chess engine), and enumerates the possible values (local Stockfish vs. Lichess cloud fallback) plus the extra fields returned (location, cache statistics). This is unmistakably a diagnostic/status tool, so it cannot be confused with the sibling analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Useful for troubleshooting" implies the usage context but gives no explicit when-to-use or when-not-to-use conditions, and names no alternative. It does not say whether to call this before or after a failed analysis, which is the most likely reason an agent would reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.