Skip to main content
Glama

Helper: show something on the call page

helper_show

For a helper session that is not in the call: puts a card on the person's call page (never spoken), shown with the sender 'Helper : <helper_name>'. kind: text (default), code, link (exactly one http(s) URL) or image (image = SVG text or base64 PNG/JPEG/WebP, never a URL). Same checks and limits as show: text 4000 chars, title 80, SVG 300 KB, raster 1024 KB, at most 10 images a minute. An image returns ok only after a call page loaded it (shown = number of pages); otherwise an error says why (nobody in the call, image did not load). kind image REQUIRES context (the full text of everything in the image, invisible, for the voicebot). Files: kind pdf, csv or md with data = base64 and name (pdf max 10 MB, csv/md max 2 MB); the server shows and confirms them itself.

Input Schema

NameRequiredDescriptionDefault
dataNokind pdf, csv or md: the file as base64.
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.
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).
titleNoOptional title, max 80 chars.
contextNoRequired for kind image: the full text of everything in the image (numbers, table rows, labels), invisible. Max 4000 chars.
credentialYesHelper credential `token` from helper_credential or POST /api/helper/credential.
helper_nameYesName of this helper session, 1-40 chars (shown on the call page as `from`).

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. Max 4000 chars.",
      +  "title": "Context"
      +}
  3. Changed3 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.",
      +  "title": "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.",
      +  "title": "Name"
      +}
  4. Added

TDQS

A4.3/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the visible sender string format 'Helper <label>: <helper_name>', that images return ok only after a call page loads them (with a shown count) and otherwise error with a stated reason, rate limits (10 images/minute), size caps, and that the server self-confirms pdf/csv/md. Annotations only say non-read-only, open-world and non-idempotent, so this detail is genuinely additive.

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 comes first and every sentence carries operational detail. The kind-by-kind constraint dump makes it a dense single paragraph that is slower to scan than a short bulleted structure would be, but there is little outright filler.

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?

Covers the practical picture for a 10-parameter mutation tool: what appears on the page, sender labeling, per-kind payload rules, failure modes and limits. With an output schema present and required parameters documented, 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.

Parameters4/5

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

Schema coverage is already 90%, yet the description still adds semantics the schema lacks: link must contain exactly one http(s) URL, image must be SVG or base64 raster and never a URL, image requires context, and the per-kind meaning of `text`. The generous size limits are useful reinforcement rather than new information.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete action and resource: places a card on the person's call page from a helper session that is not in the call, and explicitly notes it is never spoken. The scoping clause 'not in the call' separates it from the related 'show' tool, though the phrasing is embedded mid-sentence rather than front-loaded.

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?

The opening condition ('For a helper session that is not in the call') tells the agent when this tool applies and implicitly when the plain 'show' tool does instead. It references 'show' for shared limits but does not explicitly say to use 'show' when the helper is in the call, so no exclusions are spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.