Skip to main content
Glama

send

Send messages as text, audio voice notes (TTS), or files, with Markdown formatting and interactive prompts like choices and confirmations.

Instructions

Send a message as text, audio (TTS), or both. text only → text message with auto-split and Markdown. audio only → TTS voice note (spoken content). Both → voice note with text as caption (keep brief — topic context before playback). At least one of text or audio is required. For structured status, use notify. For file attachments, use send_file. For interactive prompts, use ask, choose, or confirm. Pass type: "" to route to a specific mode. Call with no args to see available types.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoEmission mode: "text" (default), "file", "notification", "choice", "dm", "append", "animation", "checklist", "progress", "question". Optional — omit to default to "text". The "text" type handles text-only, audio-only, and audio+text (voice note with caption) automatically.
textNoText message OR caption when audio is also provided. At least one of text/audio required.
audioNoSpoken TTS content. When present, sends a voice note. Requires TTS to be configured.
parse_modeNoFor text content only. Default Markdown (auto-converted).Markdown
disable_notificationNoSend silently (no sound/notification)
reply_toNoReply to this message ID
asyncNoApplies to audio sends only. Defaults to async when audio is present — returns message_id_pending immediately; pass false to block until TTS completes and receive real message_id. Has no effect on non-audio sends.
fileNoLocal path, HTTPS URL, or file_id (for type: "file")
file_typeNoMedia type for file upload (default: auto-detect by extension)auto
captionNoFile caption (for type: "file")
titleNoHeading (for type: "notification", "checklist", "progress"). For checklist/progress, `text` is accepted as an alias.
severityNoSeverity level for notificationsinfo
messageNoAlias for text in all modes. When provided and text is absent, resolves to text. Canonical parameter: 'text'.
target_sidNoTarget session ID (for type: "dm")
targetNoAlias for target_sid (for type: "dm"). Use either target or target_sid, not both.
message_idNoMessage ID to append to (for type: "append")
separatorNoSeparator for append mode
stream_idNoActive stream ID (for type: "stream/chunk" and "stream/flush")
optionsNoButton options (for type: "choice"; also accepted as alias for "choose" in type: "question")
chooseNoButton options for type: "question" choose mode (alias: "options")
columnsNoButtons per row (default 2)
ignore_parityNoBypass button emoji parity check
presetNoAnimation preset name
framesNoAnimation frame strings
intervalNoFrame interval ms
timeoutNoAnimation auto-cleanup timeout in seconds (min 5, max 600, default 60). Pass a low value (e.g. 5) to auto-cancel after N seconds.
persistentNoKeep animation running after messages
allow_breaking_spacesNoAllow breaking spaces in animation
notify_animationNoNotify on animation start
priorityNoAnimation priority level
stepsNoChecklist steps (for type: "checklist")
percentNoProgress percentage 0–100 (for type: "progress")
widthNoProgress bar width (default 10)
subtextNoProgress bar subtext
askNoFree-text question for type: "question" ask mode
confirmNoConfirmation text for type: "question" confirm mode
timeout_secondsNoTimeout for interactive question types (seconds). Omit to use the server maximum (24 h).
ignore_pendingNoSkip pending-updates check for interactive types
yes_textNoAffirmative button label (for confirm)OK
no_textNoNegative button label (for confirm)Cancel
yes_dataNoAffirmative callback dataconfirm_yes
no_dataNoNegative callback dataconfirm_no
yes_styleNoAffirmative button colorprimary
no_styleNoNegative button color
topicNoPer-message topic override. When provided, uses this string as the topic header for THIS message only — overrides the profile-level topic without mutating it. Pass an empty string to suppress the topic for this one message.
tokenNoSession token from action(type: 'session/start') (sid * 1_000_000 + suffix). Required for all send paths.
response_formatNoResponse format. "compact" omits inferrable fields (split: true, split_count, timed_out: false, voice: true) to reduce token usage. Defaults to "default".
Behavior4/5

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

With no annotations, the description must disclose behaviors. It explains auto-split, Markdown, TTS configuration requirement, and captioning for voice notes. However, it omits details like error handling, side effects (message sent), and permission requirements, leaving some gaps for a complex tool.

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 core purpose and uses a clear arrow-format for modes. It is concise but covers essential guidance. A slightly more structured layout could improve readability, but currently it is efficient with no wasted sentences.

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?

Given the tool's complexity (47 params, no output schema, no annotations), the description covers main modes and sibling differentiation. It misses some context like default behaviors for complex interactions, but overall provides sufficient context for an AI agent to understand primary usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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

Schema coverage is 100%, so each parameter has a description in the schema. The tool description adds value for key params (text, audio) but does not elaborate on many others. Baseline of 3 is appropriate as the schema already handles parameter semantics.

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 clearly states the tool's core function: sending messages as text, audio, or both. It details the three modes (text-only, audio-only, both) and distinguishes from sibling tools like notify, send_file, and interactive prompts, providing a specific verb+resource description.

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?

Explicit guidance on when to use this tool vs alternatives: 'For structured status, use notify. For file attachments, use send_file. For interactive prompts, use ask, choose, or confirm.' Also advises to call with no args to see available types, covering both when to use and how to explore.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/electrified-cortex/Telegram-Bridge-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server