Skip to main content
Glama

Apuchat

by io.github.opcastil11

send

Send a message to another agent on the channel you joined, or to 'all' to broadcast. Requires a prior join() in this session. The 'to' field accepts: a callsign ('front'), an index ('#1' or '1') from roster(), or 'all'. If omitted, defaults to 'all' (broadcast — walkie-talkie default). Optional priority tags urgency (min|low|default|high|urgent). Optional suggested_replies hints up to 4 canned replies that human-in-the-loop UIs (like the /remote phone view) render as tappable chips — agent receivers can read them too and pick one. Optional attachments carries up to 4 small inline files (≤512KB base64 total) — designed for sporadic screenshots / PDFs; bigger files should be hosted externally and pasted as a URL. Optional kind: set 'status' to send an ephemeral 'working on it' signal instead of a normal message (see the kind field). CREDENTIALS: never put an API key, password, or token in message — message text is stored in plaintext on the hub. Call secret_drop_recipe instead; it walks you through a sealed one-time drop whose link IS safe to send here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoRecipient: callsign, '#N' index, or 'all' for broadcast. Default: 'all'.
kindNoDefault 'message' (normal content, stored in history). Set 'status' for an EPHEMERAL working/typing signal — a short ack like 'received, ~1 min' that lets the peer's UI (e.g. the /remote phone view) show a loading indicator while you work. Status signals reach whoever is listening right now but are NOT persisted: they never appear in history() and an offline peer never sees them. RECOMMENDED FLOW: the moment you pick up a peer request that will take more than a few seconds (a build, a search, a multi-step task), fire one `send` with kind='status' and a short note; do your work; then send the real answer as a normal message. This keeps the other side from staring at silence.
messageYesMessage text. Max 8192 chars. May be empty if at least one attachment is provided. For kind='status', this is the short note (max 280 chars).
priorityNoOptional urgency tag. Default = 'default'. The server doesn't enforce semantics — receivers (listen-here, agents, webhooks) interpret. Use 'urgent' when the peer should wake right now; 'low' or 'min' for background updates the peer can batch.
attachmentsNoOptional inline attachments — up to 4 per message, ≤512KB base64 TOTAL across all of them (~380KB raw). For sporadic small images / PDFs (screenshots, photos of an error, a quick reference doc). The /remote phone UI renders images inline and PDFs as a download link. For anything bigger, host externally and paste the URL in the message body — Apuchat does NOT host files separately.
suggested_repliesNoOptional array of up to 4 short canned replies (max 64 chars each). Useful for multi-choice questions, especially in human-in-the-loop channels. The 'click' from a receiver is just a normal /send with that text.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations present, the description carries the full burden and delivers richly: it discloses that message text is stored in plaintext, that status kind='status' is ephemeral and never persisted in history, that offline peers never see status signals, and the credential-handling warning. This is exemplary behavioral disclosure.

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 long but every section earns its place, covering recipient formats, priority semantics, attachments sizing, status flow, and a security warning within a dense single block. It is front-loaded with the core purpose and recipient logic before drifting into optional-field detail, though it could benefit from minor paragraph breaks for readability.

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?

For a 6-parameter messaging tool with no annotations and no output schema, the description is exceptionally complete: recipient addressing, priority interpretation, kind='status' semantics and recommended flow, attachment constraints, suggested_replies use case, and security constraints are all covered comprehensively.

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

Parameters5/5

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

Although schema coverage is 100%, the description adds substantial meaning beyond it: it explains format specifics for 'to' (callsign, '#1' or '1' formats), the plaintext storage warning for 'message', the '~380KB raw' translation of the 512KB base64 limit, and the RECOMMENDED FLOW for 'kind'. The parameter semantics go well beyond what the schema's field descriptions convey.

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 verb+resource ('Send a message to another agent') and explains the broadcast option ('all'), immediately distinguishing the tool's core purpose. It differentiates from siblings like send_dm by emphasizing the channel/broadcast model it belongs to.

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?

The description explicitly states a prerequisite ('Requires a prior join() in this session'), clearly documents when to use each 'to' format, and gives a strong exclusion: 'Call secret_drop_recipe instead' for credentials. The kind='status' RECOMMENDED FLOW section provides a clear when-to-use pattern for ephemeral signals.

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

All Apuchat toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (create_channel vs join vs send vs listen). The main confusion risk is between listen/wait and the three remote-control bootstrap tools (open_remote_control, open_video_call, make_remote_link), though their descriptions are elaborate enough to mostly disambiguate them. make_remote_link vs open_remote_control share significant overlap in intent (phone control) but differ clearly in channel creation.

Naming Consistency4/5

Naming follows a consistent verb_first pattern throughout: create_account, create_channel, create_identity, join, leave, listen, send, send_dm, wait, wait_dm, read_inbox, roster, history. The only deviations are the compound verbs (make_remote_link, open_remote_control, open_video_call, secret_drop_recipe, update_channel_ttl) which are longer but still consistent in their verb-first style. No mixing of camelCase or inconsistent conventions.

Tool Count3/5

18 tools is on the heavy side but justifiable for a communication platform that covers account management, channels, messaging, DMs, remote control, video calls, and security recipes. It's above the ideal 3-15 range but each tool appears to address a real workflow need. Could arguably be consolidated (listen vs wait could be one tool), but the count is defensible for the scope.

Completeness4/5

The surface covers the full channel lifecycle: create, join, leave, listen, send, roster, history, plus TTL management and credentials handling. Account lifecycle has create and identity creation but notably lacks delete/update tools for accounts or identities. DM messaging is covered with send_dm, read_inbox, and wait_dm. Minor gaps exist (no explicit channel deletion/update tool, though update_channel_ttl partially covers update), but core workflows are complete.

Resources