Tomorrow Lives Engines

Speak a line

voice_speak

Synthesises a line of English as a 44.1 kHz WAV with the engine's own voice. The voices are synthesised by the engine, never cloned from a recording, and no voice can be uploaded. seed varies the voice; woman, age (0 to 1) and machine shape it; speed (0.5 to 2) sets how fast it speaks (1 is the speaker's own); rate sets the sample rate. Every line comes back at one loudness (level_db, default -16 dBFS of speech, so lines from different voices sit together on a timeline and none clips; level_db false leaves the voice's own level) and with its silence trimmed to a breath either side (trim false keeps the voice's half-second tail). text is at most 1000 characters, and a line that presents itself as spoken by a real, famous person is refused. Costs 1 unit.

Input Schema

Name	Required	Description
`age`	No	How old the voice sounds, 0 (young) to 1 (old).
`rate`	No	Sample rate in hertz: 16000, 22050, 44100 or 48000.
`seed`	No	A whole number that varies the voice.
`text`	Yes	The English line to speak, at most 1000 characters. A line that presents itself as spoken by a real, famous person is refused.
`trim`	No	False to keep the voice's half-second silent tail; the default trims silence to a breath either side.
`speed`	No	How fast it speaks, 0.5 to 2; 1 is the speaker's own pace.
`woman`	No	True for a woman's voice, false for a man's.
`machine`	No	True to give the voice a machine quality.
`level_db`	No	Loudness in dBFS of speech, -30 to -6 (default -16); false leaves the voice's own level.

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.

Changed10 schema fields changedOct 14, 2026

addedInput schema / properties / age / description

Added value: +"How old the voice sounds, 0 (young) to 1 (old)."

addedInput schema / properties / level_db / description

Added value: +"Loudness in dBFS of speech, -30 to -6 (default -16); false leaves the voice's own level."

addedInput schema / properties / machine / description

Added value: +"True to give the voice a machine quality."

addedInput schema / properties / rate / description

Added value: +"Sample rate in hertz: 16000, 22050, 44100 or 48000."

addedInput schema / properties / seed / description

Added value: +"A whole number that varies the voice."

addedInput schema / properties / speed / description

Added value: +"How fast it speaks, 0.5 to 2; 1 is the speaker's own pace."

addedInput schema / properties / text / description

Added value: +"The English line to speak, at most 1000 characters. A line that presents itself as spoken by a real, famous person is refused."

addedInput schema / properties / trim / description

Added value: +"False to keep the voice's half-second silent tail; the default trims silence to a breath either side."

addedInput schema / properties / woman / description

Added value: +"True for a woman's voice, false for a man's."

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

Behavior5/5

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

With only thin annotations (readOnly=false, idempotent=false), the description carries the burden well: it discloses that voices are engine-synthesised and never cloned or uploadable, that lines are loudness-normalised to a shared -16 dBFS reference so cross-voice timelines sit together, that silence is trimmed to a breath unless trim=false, the 1000-char cap, the famous-person refusal policy, and the cost of 1 unit.

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 every sentence carries substantive information, but the single dense paragraph packs many clauses and some phrasing ('shape it', 'a line that presents itself as spoken by') is more ornate than needed. Still appropriately sized for a nine-parameter tool.

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?

Return values are covered by the output schema, and the description fills in policy, limits, loudness/mixing behaviour and cost. It stops short of stating whether a given seed reproduces the same voice deterministically, which matters for a non-idempotent tool, but otherwise 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%, so the schema already documents all nine parameters; the description largely restates them (speed range, level_db default, trim tail). It adds only minor cross-parameter context such as the loudness reference for timeline mixing, so the baseline 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+resource immediately: 'Synthesises a line of English as a 44.1 kHz WAV with the engine's own voice.' This cleanly distinguishes it from sibling generation tools (sound_effect, art_render, video_render) since it is the speech/voice tool, and an agent can route to it without opening the schema.

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 context is implied (speech synthesis, refuses impersonations, costs 1 unit), but no sibling is named and there is no explicit 'use this when / not when' framing. An agent must infer when voice_speak is preferred over sound_effect or other media generators.

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?