Skip to main content
Glama

Design run

design_run
Read-onlyIdempotent

Designs a run: from a target end state to the loads of each segment that reach it, computed by the engine with no randomness, so the same request gives the same bits. request is a run_trajectory request; its numbers at the places vary names are the start, and vary gives each load's span inside the card's bounds. target is a number of the final state, a value and a tolerance. Every candidate is an ordinary run with its run_seal; one that crosses a limit is recorded refused by its name, and no value is moved back. The answer gives the timeline, its run_trajectory request and run_seal, the value reached and the miss, every candidate in order as a run_dataset plan with its dataset_seal, and a design_seal. Outcome reached; not_reached, meaning this search found none inside its caps, which is not a limit of the physics; or refused: TargetOutsideCard for a target outside the card's range, TargetBeyondReach where the card's map is monotone and a corner of the loads allowed falls short. The search is coordinate bisection, capped at 64 candidates (DESIGN_MAX_CANDIDATES), 1000000 steps (DESIGN_MAX_STEPS) and 10000 recorded frames (DESIGN_MAX_FRAMES) in all, and 4 sweeps (DESIGN_MAX_SWEEPS). verify_tape, given this whole answer as it came, designs it again and compares the two, byte for byte (the long form). On this open connection a design is long work whenever its candidates may take more than 10000 steps together. 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
varyYesFrom 1 to 8 loads the search sets, in the order a sweep takes them. The search sets loads only, never a start value, the step or the steps, and each load is held constant through its segment. low and high are the span the actuator allows; each lies at or inside the card's declared bound of the load, and a load the card bounds by nothing of its own (the cold plate's heat_power_w) is bounded by this span alone.
targetYesThe end state to reach: the quantity of the run's final state within value plus or minus tolerance, after its last step, or, for a run that ends at an end its card declares (a reactor past its first maximum of power), where the event finished. A run refused part way gives no value. A target outside the range the card declares for that quantity is refused before any run (TargetOutsideCard).
requestYesA run_trajectory request as that tool takes it, with no from or readout, and a number at every place vary names: the search's start. Nothing is filled in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Goes far beyond the annotations (readOnly/idempotent/non-destructive): it discloses determinism, the bisection algorithm, exact caps (64 candidates, 1e6 steps, 10000 frames, 4 sweeps), concurrency rules (one physics permit, long work runs singly), the 'Too many concurrent physics tasks.' response with no queueing, and a 60-second timeout. The refusal outcomes and their meanings are spelled out in detail.

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 content is largely load-bearing and front-loaded with the purpose, but it is delivered as long run-on sentences that bundle purpose, return shape, outcomes, caps and concurrency into dense prose. Most clauses earn their place, yet readability and structure suffer.

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?

No output schema exists, and the description compensates by enumerating the answer's contents (timeline, run_trajectory request and run_seal, value reached and the miss, candidate plans with dataset_seals, design_seal) plus all outcome values. Given the tool's complexity and nested schema, this is nearly complete, missing only exact definitions of a few terms like 'miss'.

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 request, vary and target thoroughly, including the low/high span semantics and the TargetOutsideCard rule. The prose adds conceptual framing (vary names are the start, loads held constant through segments) but largely restates what the schema provides. Baseline 3 for high coverage is appropriate.

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: it designs a run, going from a target end state to the per-segment loads that reach it, deterministically. It also names verify_tape as the verification counterpart, giving some sibling differentiation. The dense, idiosyncratic phrasing ('the same request gives the same bits') slightly obscures the purpose but does not hide it.

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 by the purpose (design a run to hit a target) and the description distinguishes verify_tape as the tool that re-designs and compares the answer. However there is no explicit when-to-use statement relative to run_trajectory, run_dataset or solve; the agent must infer the selection from context.

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