Skip to main content
Glama

Compute step

compute_step
Read-onlyIdempotent

Computes one anchored step of one card and returns the state it lands on, in decimals and exact hex, with its cryptographic proof (sha384_seal) and a receipt. parameters holds the card's phase fields, its load fields and dt_s, as describe_card gives them. A step whose request or whose landing state is outside the card is refused in one sentence, with the refusal's name in round brackets when it has one, and no proof is issued for that state. With from, the step starts from a sealed run, which is computed again first. On this open connection one address holds at most 1 physics permit at a time, and long work (a solve, a plan of runs or of solves, a run of more than 10000 steps, or a verification that computes one again) runs 1 at a time. A call that finds no permit or no place is answered "Too many concurrent physics tasks." and nothing waits: the same call sent later is answered once one is free. An answer is waited for 60 seconds, and long work is stopped there.

Input Schema

NameRequiredDescriptionDefault
cardYesThe card of the pair, as list_cards names it.
fromNoOptional: a sealed run to start from, as run_trajectory takes it.
domainYesThe domain of the pair, as list_cards names it.
parametersYesThe step's inputs: the card's phase fields, its load fields and dt_s, each a number (a vector field is an array of three numbers), and no other key. describe_card gives the fields of the pair, with each unit and bound. A required field left out is refused as InputMissing, in a sentence that names the field, and a card the engine does not serve as UnknownCard; nothing is filled in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / from / properties / run_seal / pattern
      Previous value: -"^[0-9a-f]{64}$"New value: +"^[0-9a-f]{96}$"
  2. Added

TDQS

A4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that out-of-card steps are refused in one sentence with the refusal name and no proof, that one address holds at most one physics permit (with 1-at-a-time long work), the exact 'Too many concurrent physics tasks.' response with no queueing, and a 60-second wait cutoff. These are concrete operational limits an agent cannot get from readOnly/idempotent hints.

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?

Front-loads the core action and result before the caveats, and every sentence carries non-redundant behavioral information. It is dense and clause-heavy with jargon ('physics permit', 'anchored'), which slightly hurts readability, but there is little waste.

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 complex, nested-input tool with no output schema, the description covers the return payload (state, proof, receipt), refusal behavior, concurrency, and timeout. The only soft spot is that the 'receipt' contents are not characterized, but nothing essential to calling it correctly is missing.

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 100%, so baseline is 3, but the description adds real meaning: parameters must hold exactly the card's phase and load fields plus dt_s with correct units/bounds from describe_card, and it names the InputMissing and UnknownCard refusal modes. This clarifies failure semantics beyond the schema's field list.

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?

States a specific verb and resource ('Computes one anchored step of one card') plus what it returns (landing state in decimals/hex, sha384_seal proof, receipt). It does not explicitly contrast itself with the related siblings verify_step or run_trajectory, so an agent must infer the distinction.

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?

Usage is implied rather than stated: 'With from, the step starts from a sealed run' gives a conditional for one parameter, and 'parameters ... as describe_card gives them' routes to a sibling for input shape. There is no explicit when-to-use-this-vs-verify_step guidance or prerequisite statement.

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