Tomorrow Lives Engines

Price a pull call

pull_cost

Read-onlyIdempotent

Prices a call without making it: give the arguments of pull_twin (a twin document, or condition, coupling, planted, field, sessions as a number and seed; nothing at all is the default twin), of pull_analyse (a sessions document, with prereg, replication, surrogates and pairs) or of pull_lab (a theory, one-dimensional or with a model, or reference skyrme or hopfion). The engine counts the document without running it: a twin's or an analysis's sessions, events, draws, work and an estimate of CPU-seconds (cpu_pairs and cpu_note say which part of a group's estimate repeats for each pair), a lab theory's lattice, the steps priced and its CPU-seconds. The answer adds what this service makes of the count: for, the call it priced; units, what that call would be charged, null when it would be refused (a queued call's price is the engine's count, so a lattice or a system generator, which the formula that routes a call cannot see, is priced as it will be); queued, whether it would be queued (202) rather than answer at once; within_limits, and when it is false the limit it breaks. A one-dimensional theory is counted too and is queued like any theory (an ordinary one at 1 unit), and the one-dimensional references, which are not counted, are refused here by name. Runs and renders nothing. Costs no units.

Input Schema

Name	Required	Description
`seed`	No	A whole number that makes the run reproducible: the same seed and inputs give the same answer.
`twin`	No	A twin document written inline, as for pull_twin.
`field`	No	The field to price in, by name.
`pairs`	No	True to price the pair analysis as well.
`prereg`	No	A pre-registration, to price an analysis under it.
`theory`	No	A theory document, to price a lab run.
`planted`	No	The planted effect as a pair of numbers between -2 and 2.
`coupling`	No	Coupling to price at, 0 to 1.
`sessions`	No	A session count for a twin run, or the sessions of an analysis to price.
`condition`	No	The condition to price: P or R followed by 1 to 4.
`reference`	No	True, or a reference name, to price the lab's reference run.
`surrogates`	No	Surrogate runs to price, 19 to 9999.
`replication`	No	Replication sessions, to price an analysis with them.

Output Schema

Name	Required	Description
`ms`	No	Milliseconds the run took.
`job`	Yes	The job id; the job tool reads it.
`verb`	No	The tool that made it.
`files`	No	Files made, each with a name, type, size and a signed URL.
`units`	No	Units this call cost.
`result`	No	The engine's own answer, a JSON document.
`status`	No	queued when the job runs in the background.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedOct 14, 2026

addedInput schema / properties / condition / description

Added value: +"The condition to price: P or R followed by 1 to 4."

addedInput schema / properties / coupling / description
```
Added value: +"Coupling to price at, 0 to 1."
```
addedInput schema / properties / field / description
```
Added value: +"The field to price in, by name."
```

addedInput schema / properties / pairs / description

Added value: +"True to price the pair analysis as well."

addedInput schema / properties / planted / description

Added value: +"The planted effect as a pair of numbers between -2 and 2."

addedInput schema / properties / prereg / description

Added value: +"A pre-registration, to price an analysis under it."

addedInput schema / properties / reference / description

Added value: +"True, or a reference name, to price the lab's reference run."

addedInput schema / properties / replication / description

Added value: +"Replication sessions, to price an analysis with them."

addedInput schema / properties / seed / description

Added value: +"A whole number that makes the run reproducible: the same seed and inputs give the same answer."

addedInput schema / properties / sessions / description

Added value: +"A session count for a twin run, or the sessions of an analysis to price."

addedInput schema / properties / surrogates / description
```
Added value: +"Surrogate runs to price, 19 to 9999."
```

addedInput schema / properties / theory / description

Added value: +"A theory document, to price a lab run."

addedInput schema / properties / twin / description

Added value: +"A twin document written inline, as for pull_twin."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "files": {
+      "description": "Files made, each with a name, type, size and a signed URL.",
+      "items": {
+        "additionalProperties": {},
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "job": {
+      "description": "The job id; the job tool reads it.",
+      "type": "string"
+    },
+    "ms": {
+      "description": "Milliseconds the run took.",
+      "type": "number"
+    },
+    "result": {
+      "description": "The engine's own answer, a JSON document."
+    },
+    "status": {
+      "description": "queued when the job runs in the background.",
+      "type": "string"
+    },
+    "units": {
+      "description": "Units this call cost.",
+      "type": "number"
+    },
+    "verb": {
+      "description": "The tool that made it.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "job"
+  ],
+  "type": "object"
+}

First observedOct 14, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: 'Runs and renders nothing. Costs no units.' plus the refusal semantics and the note that a queued call's price is the engine count. This is genuine added value that the annotations cannot express.

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 first clause is well front-loaded, but the body is a dense run-on with nested parentheticals and repetitive 'price/priced' wording that is hard to parse. The length is partly justified by 13 parameters and three input modes, yet the structure could be much cleaner.

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 13-parameter, multi-mode tool with nested objects, the description covers the key facts an agent needs: what is and isn't run, that it costs no units, and the meaning of the answer (for/units/queued/within_limits) even though an output schema exists. It falls just short of complete because mode-selection and refusal conditions are stated obliquely.

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 the baseline is 3, but the description adds a semantic grouping the flat schema lacks: it explains which parameter clusters belong to the twin mode (twin, condition, coupling, planted, field, sessions, seed) versus the analysis mode (prereg, replication, surrogates, pairs) versus the lab mode (theory, reference). That mode-mapping meaningfully helps an agent pick the right arguments.

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?

The opening clause 'Prices a call without making it' gives a specific verb and resource and states the key scope (a dry-run cost estimate). It goes on to name the sibling tools whose arguments it accepts (pull_twin, pull_analyse, pull_lab), which helps distinguish it. However the phrasing is so convoluted that the crisp differentiator against pull_call is buried rather than front-and-center.

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: you feed it the arguments of pull_twin/pull_analyse/pull_lab to learn what a call would cost, and 'nothing at all is the default twin' gives a fallback. It also names an exclusion (the one-dimensional references 'are refused here by name'). But there is no explicit when-to-use-this-instead-of-calling guidance.

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

All Tomorrow Lives Engines tools Inspect

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

Need Help?