Skip to main content
Glama
Sign In

Zero-Trust Physics

by com.zerotrustphysics
OverviewDiscussionsAdmin

Verify step

verify_step
Read-onlyIdempotent

Computes one anchored step of one card, as compute_step does: verify_step is the earlier name of compute_step, served for this one version beside it, and takes the same arguments and gives the same answer, byte for byte. The name compute_step is the one that stays. 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. Changed1 schema field changed
    • changedInput schema / properties / parameters / description
      Previous value: -"The 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."New value: +"The 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."
  3. Changed1 schema field changed
    • changedInput schema / description
      Previous value: -"One anchored step. The same request as POST /verify_physics. The shape of parameters depends on the pair: read describe_card for it."New value: +"One anchored step. The shape of parameters depends on the pair: describe_card gives it."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark it read-only, idempotent, non-destructive, but the description goes well beyond: one physics permit per connection, serialization of long work, the exact refusal message 'Too many concurrent physics tasks.', no-waiting semantics, and a 60-second timeout at which long work is stopped. 'Byte for byte' also confirms the idempotent hint meaningfully.

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-loaded with the most decision-relevant fact (equivalence to compute_step and which name survives), and the operational constraints earn their place. Slightly verbose in enumerating long-work cases ('a solve, a plan of runs or of solves, a run of more than 10000 steps...'), which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description supplies the equivalence guarantee ('same answer, byte for byte' as compute_step), the concurrency and timeout envelope, and refusal behavior, while the rich schema carries parameter detail. Nothing an agent needs to call it correctly is missing.

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% and the schema already explains card, domain, from/run_seal, and the parameters contract including InputMissing/UnknownCard errors. The description adds only 'takes the same arguments' and the byte-identical answer claim, so per the baseline rule a 3 is correct.

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?

States a specific verb and resource ('computes one anchored step of one card') and immediately distinguishes itself from the sibling compute_step by declaring itself the earlier name served only for this version. An agent can tell exactly what it does and that a preferred equivalent exists without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: verify_step is the earlier name, compute_step is 'the one that stays', and the two take the same arguments and return the same answer. This is a direct when-to-use/when-not signal, plus descriptions of when calls will be refused (no permit/place) and how retries behave.

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

All Zero-Trust Physics toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources