Skip to main content
Glama

Generate spoken briefing

well_generate_spoken_briefing

Read a written answer aloud and return it as one playable audio file, kept as a media row of the workspace. Use it only when the person asks to hear an answer, not after every answer. On WhatsApp the audio goes out as a voice message: title, when you pass it, goes out as one line right before the voice message, and your own text follows it.

Pass the written answer exactly as it already stands in text — this tool reads it aloud, it does not write new wording. Speech costs money by the character and shares one daily budget across every workspace, so a spent or unreadable budget, or any other reason the voice could not run, still returns success: true with audio_url: null and a reason: tell the person the text answer stands and the voice was not available.

audio_url plays with a plain HTTP GET and no auth header, and stops working at expires_at, 24 hours after the call: never promise the person a lasting link. transcript is the spoken script, for a reader who cannot listen — it is never longer than text and never speaks a figure text does not carry.

Input Schema

NameRequiredDescriptionDefault
textYesThe written answer to read aloud, exactly as it already stands.
titleNoThe card's title. Defaults to a generic 'Spoken briefing'.
languageNoThe language to read it in. Defaults to English.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several — a write lands in exactly one workspace and this call would not say which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.
idempotency_keyNoOptional client-supplied key. A retried write with the same key returns the original result instead of re-applying the operation.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output Schema

NameRequiredDescriptionDefault
textYesThe written answer this call read, unchanged.
titleYes
reasonYes
successYes
media_idYes
audio_urlYesA signed link to the stored audio (MP3 on the web, Ogg Opus on WhatsApp), or null when the call carries no audio.
expires_atYesWhen `audio_url` stops working, as an ISO 8601 time, or null when the call carries no link.
transcriptYes
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / audio_url / description
      Previous value: -"A signed link to the stored MP3, or null when the call carries no audio."New value: +"A signed link to the stored audio (MP3 on the web, Ogg Opus on WhatsApp), or null when the call carries no audio."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: it creates a media row, charges by character against a shared daily budget, and may return success true with audio_url null plus a reason. It also discloses that audio_url requires no auth and expires after 24 hours, and explains how transcript relates to the input text. These are operationally important details an agent would otherwise miss.

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 and primary usage condition, then moves into cost/failure behavior and output lifetime. It is longer than average but most sentences carry operational value. A few details, such as the transcript explanation, are slightly tangential but still relevant.

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?

Given the tool's mutation behavior, cost implications, channel-specific delivery, and expiring output URL, the description is complete enough for an agent to call and explain the result correctly. The output schema exists, and the description still provides necessary behavioral context around failures and expiry. No major gap remains.

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 schema already documents all seven parameters. The description nonetheless adds useful meaning for text and title, including that text must be passed exactly as it stands and that title becomes a WhatsApp line before the voice message. It does not explain the remaining parameters, but the schema carries those details.

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?

The description states a specific verb and resource: it reads a written answer aloud and returns one playable audio file kept as a workspace media row. It also distinguishes the tool from writing new wording and from generating voice after every answer. It does not explicitly compare itself against named sibling tools, so it falls just short of a 5.

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 usage guidance: use only when the person asks to hear an answer, not after every answer. It also explains WhatsApp delivery behavior and what to tell the user when speech cannot run. It does not name or compare against any alternative sibling tool, so the routing guidance is strong but not complete.

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.

Resources