voicehook

Helper: set own status board

helper_status

Destructive

For a helper session that is not in the call: sets its own status board on the call page, shown as 'Helper : <helper_name>' below the main agent; the main agent's board stays as it is. Same limits as status (doing max 400 chars, open / done max 10 items). 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). Empty doing, open and done removes the helper's board. Returns ok and, when context or faq is missing on an entry, warnings.

Input Schema

Name	Required	Description
`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.
`credential`	Yes	Helper credential `token` from helper_credential or POST /api/helper/credential.
`helper_name`	Yes	Name of this helper session, 1-40 chars (shown on the call page as `from`).

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)."
+}

AddedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: empty doing/open/done removes the helper's board (the destructive effect behind destructiveHint=true), meta is hidden background for the voicebot and never shown on the page, missing context/faq produces `warnings` rather than an error, and helpers do not inherit goals. These are exactly the operational details an agent needs and are not present in the annotation flags.

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 identity/scope sentence, then limits, then meta, then removal and return behavior. It is dense and sentence-long in places, but every clause carries operational information; minor readability cost without waste.

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 present, the description still covers the parts schemas cannot: display placement, page-vs-voicebot visibility, warning-not-error behavior, and the destructive empty-payload case. Nothing material for correct invocation is missing for a helper-scoped board mutation.

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: the `meta` entries are explicitly invisible to the page and consumed by the voicebot, and the warnings coupling with context/faq is only stated here. It also clarifies the empty-value removal semantics for doing/open/done beyond the schema's max-length notes.

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 and resource ('sets its own status board on the call page') plus the exact rendering ('Helper <label>: <helper_name>' below the main agent). It explicitly separates itself from the sibling `status` by noting the main agent's board stays unchanged and that limits match `status`, so an agent can differentiate without opening schemas.

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 a clear applicability condition ('For a helper session that is not in the call') and implies the alternative (`status`) by reference to its limits. It does not explicitly state when NOT to use it or name which sibling to pick for a non-helper session, so it falls short of full when/when-not/alternatives guidance.

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.