Skip to main content
Glama

Tomorrow Lives Engines

by com.tomorrowlives
OverviewDiscussionsAdmin

Grade a practice

pull_practice

Grades a practice of five drills: match (the spread of the taps against the click), hold (the click falls silent and the person keeps the beat), follow (the click moves its tempo once, at a beat nobody is told), lead (the click follows the person) and duet (the click meets the person a quarter of the way). Each drill is rounds of taps against a click, graded on one number in milliseconds against its level's tolerance, and printed beside the input's own jitter (practice.input: the clock that stamps the taps and its stated jitter), with a sentence saying so when the input cannot tell the person's spread from its own. The staircase is pinned: two passes in a row move a drill up one level and a miss moves it down one, 20 levels at most. The answer's session (each drill's next level and score) goes back in as the next practice's history, oldest first, and a drill the history holds gets a trend over the sessions. A drill's recorded rounds ([{clicks_ms, taps_ms}], a client's own click and tap times) are graded as played; without them a simulated person (a timekeeper and a motor, correcting toward the click) plays the drill, and practice.person sets it. The engine plays no click and hears no input: the client does both. Give a practice document (pull_schema lists its keys under practice), or nothing, or seed alone, for the default practice of all five drills. Every sentence is checked for wellness language and the answer carries the not-a-medical-device sentence; a drill name the check refuses refuses the whole answer. Answers at once, within 30 seconds. Costs 1 unit.

Input Schema

NameRequiredDescriptionDefault
seedNoA whole number that makes the run reproducible: the same seed and inputs give the same answer.
practiceNoThe practice document: the five drills and the taps recorded for each, as JSON.

Output Schema

NameRequiredDescriptionDefault
msNoMilliseconds the run took.
jobYesThe job id; the job tool reads it.
verbNoThe tool that made it.
filesNoFiles made, each with a name, type, size and a signed URL.
unitsNoUnits this call cost.
resultNoThe engine's own answer, a JSON document.
statusNoqueued when the job runs in the background.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / practice / description
      Added value: +"The practice document: the five drills and the taps recorded for each, as JSON."
    • addedInput schema / properties / seed / description
      Added value: +"A whole number that makes the run reproducible: the same seed and inputs give the same answer."
    • 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"
+}
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations it discloses cost ('costs 1 unit'), latency ('within 30 seconds'), determinism under seed, the engine/client split ('the engine plays no click and hears no input'), and partial-failure semantics (a refused drill name refuses the whole answer). These are real behaviours an agent could not infer from readOnlyHint/destructiveHint alone. It stops short of describing failure modes for the simulation path.

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 largely earns its place, but it is delivered as a single dense run-on block with nested parentheticals, so the essential 'what it grades' and 'how to call it' points are not front-loaded or scannable. Size is defensible for the complexity; structure is not.

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?

An output schema exists, so return values need not be restated, yet the description still explains the answer's shape (each drill's next level and score, trends over history). Combined with input-mode coverage, cost, latency and refusal rules, an agent has enough to call the tool correctly.

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 genuine meaning: it explains that practice keys live in pull_schema, that practice.person configures the simulated player, and the format and effect of recorded rounds ('[{clicks_ms, taps_ms}] ... graded as played'). It goes beyond restating the schema.

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?

It states a specific verb and resource ('Grades a practice of five drills') and enumerates the five drills, so an agent knows exactly what the tool computes. It does not, however, contrast itself against neighbouring pull_* tools such as pull_analyse or pull_replay, so sibling routing is left to the name alone.

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?

It spells out the input permutations clearly ('give a practice document ... or nothing, or seed alone, for the default practice of all five drills') and describes the iterative workflow where the returned session is fed back as the next practice's history. It gives context but no explicit when-not or alternative-tool 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 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