voicehook

Speak in the call

say

Destructive

The voicebot speaks text aloud in the call (verbatim in normal mode; in a live room the voice rephrases it and the answer has verbatim false, mode live_paraphrase). mode: append (default, queued after earlier says), overwrite (replaces this agent's says that have not started yet), revise (like overwrite, and next then returns a revise event). ref (optional) ties the sentence to a card or decision: the person sees it highlighted while you speak. Returns ok and seq.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "session": "<session>",
      "text": "<text>"
    },
    "name": "say"
  }
}

Input Schema

Name	Required	Description	Default
`ref`	No	Optional: the card or decision this sentence is about, "card:<card id>" (id from show) or "decision:<number>". While the sentence plays, the person sees it highlighted (its window opens if closed). Unknown ids are ignored, the sentence is spoken anyway.
`mode`	No		append
`text`	Yes	What to say, max 4000 chars.
`session`	Yes	The `session` value returned by join.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / ref

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional: the card or decision this sentence is about, \"card:<card id>\" (id from show) or \"decision:<number>\". While the sentence plays, the person sees it highlighted (its window opens if closed). Unknown ids are ignored, the sentence is spoken anyway.",
+  "title": "Ref"
+}

First observedOct 17, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already flag destructive, non-idempotent, and open-world behavior, and the description adds concrete consequences: overwrite discards not-yet-started says, revise changes the next event, live rooms paraphrase and return verbatim false, and ref highlights a card while speaking. It also discloses the return values ok and seq. This is consistent with destructiveHint=true rather than contradicting it.

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?

The description is front-loaded with purpose, then modes, ref, and return values, and every sentence carries useful information. The parenthetical 'verbatim false, mode live_paraphrase' is slightly dense, but it does not waste space.

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?

With an output schema, rich annotations, and mostly documented parameters, the description is complete enough for correct invocation. It adds the key behavioral nuance around destructive overwrites and live-room paraphrasing that an agent otherwise would not know.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, and the description supplies the missing mode semantics in detail, including append, overwrite, and revise behavior. It also explains ref's highlighting effect and notes text is spoken verbatim in normal mode, adding meaning beyond the schema descriptions.

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?

The description uses a specific verb and resource: the voicebot speaks `text` aloud in the call. The title reinforces this, and the tool is clearly the speech primitive rather than a data, notification, or decision tool.

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 gives explicit mode-selection guidance: append queues after earlier says, overwrite replaces this agent's not-yet-started says, and revise also causes the next tool to return a revise event. It does not explicitly compare the tool with siblings like notify_me or send_data, so it stops short of a 5.

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

All voicehook 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.