Skip to main content
Glama

assess_candidate_move

Verify a candidate chess move with unrestricted and forced-root engine searches at two budgets, retaining the full supplied history.

Instructions

Verify a candidate against unrestricted and forced-root searches at two budgets, retaining full supplied history.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fenYes
moveYes
historyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
fenYes
caveatYes
historyYes
root_fenYes
verifiedYes
preliminaryYes
best_move_uciYes
classificationYes
schema_versionYes
evidence_statusYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full behavioral burden. It mentions 'two budgets' and 'retaining full supplied history', which hints at cost and state behavior, but it doesn't name the budgets, state whether the call is synchronous or long-running, or clarify what is returned. For a comparatively expensive multi-search tool, this is a material 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?

A single front-loaded sentence with no wasted words. It is efficient, though the compression is partly why the behavioral and parameter details are absent.

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?

An output schema exists, so return values need not be explained. But with zero annotation coverage, zero parameter documentation, and no sibling differentiation, the description is incomplete for a 3-parameter analysis tool with several near-identical siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and all three parameters (fen, move, history) are undocumented in both schema and description. The phrase 'full supplied history' is the only hint about history, but it doesn't explain format, purpose, or when to include it. The description does essentially nothing to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Verify' and its object 'a candidate' are stated, along with the search method and budgets. However, the description does not differentiate this tool from close siblings like evaluate_move, compare_candidate_moves, or evaluate_position, which an agent would otherwise confuse.

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?

It explains what the tool does but gives no when-to-use context, no conditions under which this is preferred over evaluate_move or compare_candidate_moves, and no exclusions. The agent is left to infer the divot from the bare description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.