Skip to main content
Glama
Sign In

voicehook

by io.github.voicehook-ai
OverviewDiscussionsAdmin

Show something on the call page

show

Put a card on the person's call page (never spoken): text, code, a link or an image. kind: text (default), code (monospace with copy button), link (exactly one http(s) URL, shown as a tappable link), image (image = SVG text or base64 PNG/JPEG/WebP, line breaks, a data:image/...;base64, prefix and missing padding are accepted; or file_id of an image uploaded with the REST endpoint POST /api/bridge/upload, which keeps large base64 out of the tool call). kind image REQUIRES context: the full text of everything in the image (numbers, table rows, labels); it is never shown, the voicebot cannot see images and answers questions from it. A new card appears as a small preview top left; panel cards opens the cards view, board, log or decisions open those panels, none closes them. large: true opens the cards view big in the middle with this card at full size (diagrams, swimlanes; implies panel cards). SVG may draw anything (no scripts, no foreignObject, no external references). Files (reports, tables): kind pdf (preview with page turning and download), csv (table preview of the first rows and download) or md (Markdown, rendered safely, and download) with data = the file as base64 and name = file name (e.g. report.pdf), or file_id from POST /api/bridge/upload. Limits: text 4000 chars, title 80, SVG 300 KB, raster 1024 KB, pdf 10 MB, csv and md 2 MB (UTF-8).

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": "show"
  }
}

Input Schema

NameRequiredDescriptionDefault
dataNokind pdf, csv or md: the file as base64 (pdf max 10 MB, csv/md max 2 MB UTF-8).
goalNoOptional 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).
kindNo
nameNokind pdf, csv or md: file name shown on the card and used for the download.
textNoCard text, max 4000 chars (code: the code; link: the URL).
imageNokind image: SVG text or base64 PNG/JPEG/WebP (SVG max 300 KB, raster max 1 MB).
largeNoOpen the cards view big in the middle with this card at full size.
panelNo
titleNoOptional title, max 80 chars.
contextNoRequired for kind image: the full text of everything in the image (numbers, table rows, labels). Invisible on the page; the voicebot reads it to answer questions about the image. Max 4000 chars.
file_idNokind image, pdf, csv or md: id from POST /api/bridge/upload (same call, same limits and checks); instead of image or data.
sessionYesThe `session` value returned by join.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / context
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Required for kind image: the full text of everything in the image (numbers, table rows, labels). Invisible on the page; the voicebot reads it to answer questions about the image. Max 4000 chars.",
+  "title": "Context"
+}
  3. Changed4 schema fields changed
    • addedInput schema / properties / data
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "kind pdf, csv or md: the file as base64 (pdf max 10 MB, csv/md max 2 MB UTF-8).",
+  "title": "Data"
+}
    • changedInput schema / properties / file_id / description
      Previous value: -"kind image: id from POST /api/bridge/upload (same call, same limits and checks as image); instead of image."New value: +"kind image, pdf, csv or md: id from POST /api/bridge/upload (same call, same limits and checks); instead of image or data."
    • changedInput schema / properties / kind / anyOf
      Previous value: -[
-  {
-    "enum": [
-      "text",
-      "code",
-      "link",
-      "image"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "text",
+      "code",
+      "link",
+      "image",
+      "pdf",
+      "csv",
+      "md"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / name
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "kind pdf, csv or md: file name shown on the card and used for the download.",
+  "title": "Name"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / file_id
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "kind image: id from POST /api/bridge/upload (same call, same limits and checks as image); instead of image.",
+  "title": "File Id"
+}
  5. Changed2 schema fields changed
    • changedInput schema / properties / image / description
      Previous value: -"kind image: SVG text or base64 PNG/JPEG/WebP (SVG max 100 KB, raster max 1 MB)."New value: +"kind image: SVG text or base64 PNG/JPEG/WebP (SVG max 300 KB, raster max 1 MB)."
    • addedInput schema / properties / large
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Open the cards view big in the middle with this card at full size.",
+  "title": "Large"
+}
  6. First observed

TDQS

A4.4/5.0
Behavior5/5

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

The description goes well past the annotations, which only say readOnlyHint=false, destructiveHint=false, openWorldHint=true. It discloses visible side effects (a preview appears top left, panels open or close), the hidden `context` channel the voicebot reads instead of the image, SVG sandbox restrictions (no scripts, no foreignObject, no external references), and per-kind size limits — all behavior an agent could not infer from structured fields.

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 purpose is front-loaded correctly, but the rest is a single dense run-on paragraph mixing content kinds, panel semantics, SVG rules, file kinds and limits, which makes it hard to scan. Some sentences duplicate what the schema already documents (the 4000/80/300 KB/1024 KB/10 MB/2 MB limits appear in both places), so not every sentence earns its place.

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 a 12-parameter tool with seven rendering kinds, the description covers the decisions an agent must make: which kind, when `context` is mandatory, when `file_id` replaces inline data, and what the page does afterward. An output schema exists so return values need no explanation, but the description is silent on failure behavior when a limit is exceeded and on the relationship to `helper_show`.

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?

With schema coverage at 83% the baseline is already 3, and the description pushes higher by explaining cross-parameter constraints the schema states only in isolation: image kind REQUIRES `context`, `large` implies panel cards, `link` takes exactly one URL, and `file_id` exists specifically to keep large base64 out of the tool call. It loses a point for repeating size limits already in the schema and for saying nothing about the `goal` parameter's inheritance behavior.

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 opening sentence gives a concrete verb and resource — "Put a card on the person's call page" — and immediately bounds the scope with "(never spoken)", which cleanly separates it from the sibling `say`. It then enumerates the exact content kinds it renders (text, code, link, image, plus pdf/csv/md later), so an agent can tell what it is for without consulting 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 Guidelines4/5

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

Guidance is rich at the level of kinds: code is monospace with a copy button, link takes exactly one http(s) URL, image requires `context`, `large: true` is for diagrams and swimlanes, `panel` opens/`none` closes specific views. What it never does is name the alternatives explicitly (e.g. `say` for spoken output, `helper_show`, `send_data`), so the routing decision is implied by "never spoken" rather than stated as a when-to-use rule.

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

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