Tomorrow Lives Engines

Draw a perturbation schedule

pull_schedule

Draws a schedule of perturbations (tempo up or down, phase advance or delay, and catch trials where nothing changes) placed with a lead-in and random gaps; spec sets its trials, gaps and beat (pull_schema lists the keys). By default the randomness is 32 bytes of this server's operating-system randomness, graded hardware_seeded; seed draws from software instead (graded software, which a research run refuses); entropy_hex with grade brings your own bytes and says where they came from. research refuses software randomness. Returns the schedule and its text, which pull_seal seals. Nothing is kept here. Costs 1 unit.

Input Schema

Name	Required	Description
`seed`	No	A whole number that makes the run reproducible: the same seed and inputs give the same answer.
`spec`	No	The schedule specification written inline as JSON; pull_schema lists its keys.
`grade`	No	How the entropy you brought was produced, recorded with the schedule.
`entropy`	No	The entropy source: os, the server's own.
`research`	No	True to draw the schedule for a research run.
`entropy_hex`	No	Your own entropy as hex, in place of the server's, when you must bring the bytes yourself; grade then says where they came from.

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.

Changed7 schema fields changedOct 14, 2026

addedInput schema / properties / entropy / description

Added value: +"The entropy source: os, the server's own."

addedInput schema / properties / entropy_hex / description

Added value: +"Your own entropy as hex, in place of the server's, when you must bring the bytes yourself; grade then says where they came from."

addedInput schema / properties / grade / description

Added value: +"How the entropy you brought was produced, recorded with the schedule."

addedInput schema / properties / research / description

Added value: +"True to draw the schedule for a research run."

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 / spec / description

Added value: +"The schedule specification written inline as JSON; pull_schema lists its keys."

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

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, but the description adds real operational context beyond them: it costs 1 unit, persists nothing ("Nothing is kept here"), returns both schedule and text, and grades randomness sources. These additions are consistent with the annotations, not contradictory.

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?

Purpose is front-loaded and the trailing short sentences ("Returns the schedule and its text... Nothing is kept here. Costs 1 unit.") are crisp and high-value. The middle entropy sentence is long and slightly overloaded, and "research refuses software randomness" is stated twice, costing a little efficiency.

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?

For a 6-param, nested-spec tool with an output schema, the description covers everything an agent needs: what the spec controls, where its keys live, how entropy/grade/seed interact, persistence, cost, and the research restriction. Nothing material is left to guesswork.

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 cross-parameter meaning the schema cannot: the mutual relationship between entropy (default os + hardware_seeded grade), seed (software grade), and entropy_hex + grade, plus the research interaction that rejects software randomness. This is genuine semantic value over the field-level docs.

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+resource ("Draws a schedule of perturbations") and enumerates the perturbation types, so the agent knows exactly what is produced. It also references siblings pull_schema (key list) and pull_seal (sealing), giving partial differentiation, though it never states how it differs from other pull_* generation tools.

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?

Gives clear conditional guidance for choosing the entropy path (default OS randomness, seed, or entropy_hex with a grade) and an explicit exclusion (research refuses software randomness). It lacks any tool-level routing such as when to pick this over pull_lab, pull_practice, or pull_replay.

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?