Skip to main content
Glama

sim_evaluate

Destructive

Score a player's legal next moves by NEXT-MOVE ELIMINATION (the tic-tac-toe blog technique): compute the expected objective from the given marking with all moves available, then once per candidate with that move's rate zeroed — the move whose elimination loses the most is the best move. Needs the game schema (simulation.objective + simulation.players). Ungated nets use the continuous ODE relaxation; gated nets use exact seeded SSA rollouts, and the response says which — the same rule sim_scenario's "engine" choice follows (docs/engine-selection.md).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesmodel id
playerYesplayer name from simulation.players
horizonNomodel time to explore ahead (default 3)
markingNoJSON object, sparse marking override (the position to evaluate from); default = the initial marking
realizationsNoSSA rollouts per elimination (default 40)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the agent knows this is a mutating, non-idempotent operation. The description adds meaningful behavioral context beyond the annotations: it explains the two execution modes (continuous ODE relaxation vs exact seeded SSA rollouts), states that the response says which mode was used, and notes the schema dependency. It does not detail what gets destroyed or what side effects occur, but the annotations plus the mode disclosure cover the main behavioral risks.

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 dense but efficient: it front-loads the core algorithm, then covers schema requirements, engine selection, and the response's mode disclosure in three sentences. The parenthetical '(the tic-tac-toe blog technique)' is slightly informal but not wasteful. Every sentence earns its place, though the algorithm explanation could be tightened.

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?

For a tool with 5 parameters, no output schema, and a complex algorithm, the description covers the essential context: what the tool computes, how it computes it, what schema it needs, and how the engine choice is determined. It does not describe the return value structure (though no output schema exists, so the description could have helped), nor does it explain what 'destructive' means in this context. Still, the description is substantially complete for an agent to decide whether to call it.

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 five parameters. The description adds context for 'marking' (sparse marking override, the position to evaluate from) and 'realizations' (SSA rollouts per elimination), which maps to the gated-net execution mode. However, it does not explain the semantics of 'horizon' beyond 'model time to explore ahead' or clarify how 'player' interacts with the elimination algorithm. Baseline 3 is appropriate because the schema carries the load and the description adds only modest extra meaning.

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 names a specific verb ('Score'), a specific resource ('a player's legal next moves'), and a precise method (NEXT-MOVE ELIMINATION) with a one-line explanation of the algorithm. It also distinguishes itself from the sibling sim_scenario by referencing the same engine-selection rule, so an agent can tell them apart.

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 gives clear context: it needs the game schema (simulation.objective + simulation.players), and it explains the engine choice rule (ungated vs gated nets) with a pointer to docs/engine-selection.md. It does not explicitly say 'use this instead of sim_scenario when...' but the engine-rule cross-reference and the focus on next-move elimination imply the intended use case.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources