voicehook

Update the status board

status

DestructiveIdempotent

Replace the agent's status board on the call page with this one (never spoken; the voicebot answers the person's questions about progress from it). Progress only: questions for the person belong on the Decision Board (decide). doing: current step and ETA (max 400 chars). open / done: max 10 items each, 200 chars per item. faq: up to 6 question/answer pairs the voicebot can answer directly. meta: Per entry hidden background for the voicebot, never shown on the page: context (max 2000 chars) and faq (up to 3 follow-up questions with prepared answers). Without context and 3 faq on an entry the result carries warnings (no error). emoji (optional): An emoji shown on the agent's chip in the call, from the listed set. Empty string removes it, left out keeps it. Whole board max 2000 chars. Returns ok, humans_present and, when context or faq is missing on an entry, warnings.

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>"
    },
    "name": "status"
  }
}

Input Schema

Name	Required	Description
`faq`	No	Max 6 pairs [{"q": "question", "a": "short answer"}].
`done`	No	Done items, max 10.
`goal`	No	Optional goal of this entry: number or title of a goal of the account (0 or empty = no goal). Unknown goals are ignored. Without it the entry inherits the goal of your last status (helpers: no inheriting).
`meta`	No	Per entry hidden background for the voicebot, never shown on the page: context (max 2000 chars) and faq (up to 3 follow-up questions with prepared answers). Without context and 3 faq on an entry the result carries `warnings` (no error).
`open`	No	Open items, max 10.
`doing`	No	Current step + ETA, max 400 chars.
`emoji`	No	An emoji shown on the agent's chip in the call, from the listed set. "" removes it.
`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 changedNov 5, 2026

addedInput schema / properties / goal

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Optional goal of this entry: number or title of a goal of the account (0 or empty = no goal). Unknown goals are ignored. Without it the entry inherits the goal of your last status (helpers: no inheriting).",
+  "title": "Goal"
+}

Changed2 schema fields changedOct 20, 2026

addedInput schema / $defs

Added value: +{
+  "BoardMeta": {
+    "properties": {
+      "doing": {
+        "anyOf": [
+          {
+            "$ref": "#/$defs/ItemMeta"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Background of `doing`."
+      },
+      "done": {
+        "anyOf": [
+          {
+            "items": {
+              "$ref": "#/$defs/ItemMeta"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Background per done item, same order as `done`.",
+        "title": "Done"
+      },
+      "open": {
+        "anyOf": [
+          {
+            "items": {
+              "$ref": "#/$defs/ItemMeta"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Background per open item, same order as `open`.",
+        "title": "Open"
+      }
+    },
+    "title": "BoardMeta",
+    "type": "object"
+  },
+  "FaqPair": {
+    "properties": {
+      "a": {
+        "description": "The prepared answer, max 200 chars.",
+        "title": "A",
+        "type": "string"
+      },
+      "q": {
+        "description": "A likely follow-up question of the person, max 200 chars.",
+        "title": "Q",
+        "type": "string"
+      }
+    },
+    "required": [
+      "q",
+      "a"
+    ],
+    "title": "FaqPair",
+    "type": "object"
+  },
+  "ItemMeta": {
+    "properties": {
+      "context": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Background of this entry for the voicebot (what, why, current state), max 2000 chars.",
+        "title": "Context"
+      },
+      "faq": {
+        "anyOf": [
+          {
+            "items": {
+              "$ref": "#/$defs/FaqPair"
+            },
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Up to 3 likely follow-up questions with prepared answers.",
+        "title": "Faq"
+      }
+    },
+    "title": "ItemMeta",
+    "type": "object"
+  }
+}

addedInput schema / properties / meta

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/BoardMeta"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Per entry hidden background for the voicebot, never shown on the page: context (max 2000 chars) and faq (up to 3 follow-up questions with prepared answers). Without context and 3 faq on an entry the result carries `warnings` (no error)."
+}

First observedOct 17, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses replacement semantics, hidden-vs-visible meta content, the warnings-not-error degradation when context/faq are missing, and the emoji keep/remove behavior. It stops short of saying what the prior board's contents are lost or how partial updates behave, but the destructive overwrite is clearly implied.

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?

Front-loaded with the core action and the sibling routing, then limits and meta semantics. It is dense and somewhat run-on with per-field char caps inline, but nearly every clause carries operational information rather than restating the name.

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 an 8-parameter mutation tool with an output schema and annotations, the description covers board structure, hidden meta, warnings behavior, and the return fields (ok, humans_present, warnings). The `goal` inheritance parameter is only handled by the schema, which is a minor gap given the otherwise thorough coverage.

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 real meaning: meta entries are hidden background never shown on the page, missing context/faq yields warnings rather than failure, and emoji empty-string removes while omission keeps. It does not touch `goal` or `session`, leaving those entirely to the schema.

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 opens with a specific verb and resource ('Replace the agent's status board on the call page with this one') and immediately clarifies the artifact is never spoken but read by the voicebot. It also distinguishes itself from the sibling decision board by routing person-directed questions to 'decide'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the boundary: this board is for progress only, and questions for the person belong on the Decision Board (decide). That is a concrete when-to-use/when-not-to-use rule tied to a named sibling, so an agent can route correctly without inference.

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.