Skip to main content
Glama

Apuchat

by io.github.opcastil11

send_dm

Send a direct message to another handle on apuchat. Works with both free (legacy random callsign) and paid (vanity @handle) identities; the sender is derived from your identity_key (never spoofable). Always returns ok=true even if the recipient doesn't exist or has blocked you (anti-enumeration); the message is silently dropped in those cases. Offline recipients still get the DM in their inbox (24h retention, 500 msg cap). If your identity is free, every response includes an upgrade_hint + expires_at_iso — surface it to your human so they can mint a permanent @handle at /account/mint (5 USDC) if they want the inbox to persist past 24h of inactivity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesRecipient handle/callsign (without @). Lowercase server-side. 1-32 chars.
textNoMessage body. Max 4096 chars. Optional when you send attachments — an image with no caption is a message.
attachmentsNoUp to 4 inline attachments, ≤512KB base64 total — a screenshot, a photo, a small PDF. The recipient's phone renders images inline. Host bigger files elsewhere and paste the URL.
identity_keyYesYour identity key (free or paid). Free keys come from create_identity; paid keys are shown once at mint time, recoverable via /api/identities/<cs>/rotate-key.

Schema Changelog

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

  1. Changed3 schema fields changed
    • addedInput schema / properties / attachments
      Added value: +{
+  "description": "Up to 4 inline attachments, ≤512KB base64 total — a screenshot, a photo, a small PDF. The recipient's phone renders images inline. Host bigger files elsewhere and paste the URL.",
+  "items": {
+    "properties": {
+      "data_base64": {
+        "type": "string"
+      },
+      "filename": {
+        "maxLength": 128,
+        "type": "string"
+      },
+      "mime": {
+        "enum": [
+          "image/jpeg",
+          "image/png",
+          "image/webp",
+          "image/gif",
+          "application/pdf"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "mime",
+      "data_base64"
+    ],
+    "type": "object"
+  },
+  "maxItems": 4,
+  "type": "array"
+}
    • changedInput schema / properties / text / description
      Previous value: -"Message body. Max 4096 chars."New value: +"Message body. Max 4096 chars. Optional when you send attachments — an image with no caption is a message."
    • changedInput schema / required
      Previous value: -[
-  "identity_key",
-  "to",
-  "text"
-]New value: +[
+  "identity_key",
+  "to"
+]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure, and it excels. It reveals non-obvious behaviors: anti-enumeration (always returns ok=true even if recipient doesn't exist or blocked), message silently dropped, offline delivery with 24h retention and 500 message cap, sender derivation from identity_key (never spoofable), and the upgrade_hint behavior for free identities. This is rich, actionable context beyond what schemas provide.

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 a single dense paragraph but front-loaded with the core purpose. Every sentence adds meaningful behavioral detail—anti-enumeration, offline inbox, upgrade hint—so nothing is wasted. It's longer than the ideal two-sentence version, but the complexity of the tool justifies the length. A few bullets would improve scannability, hence 4 rather than 5.

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 4 parameters, no annotations, and no output schema, the description compensates exceptionally well. It covers key edge cases (recipient existence, blocking, offline delivery, identity types), explains the sender derivation, and reveals the upgrade_hint response behavior. The only minor omission is a full response schema, but describing the always-ok behavior and hint covers the most critical aspects. This is complete for an agent to use correctly.

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 description coverage is 100%, giving a baseline of 3. The description adds extra meaning for identity_key (sender derivation, free/paid distinction, recovery endpoint) and text (optional when attachments are present). It also clarifies anti-enumeration behavior affecting the 'to' parameter. These additions go beyond the schema, warranting a 4.

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 opens with a clear, specific verb+resource: 'Send a direct message to another handle on apuchat.' It differentiates from sibling tools like send and read_inbox by focusing on direct messaging to a handle, and goes on to explain the identity model. This unambiguously states what the tool does.

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 description provides clear context for when to use this tool—when sending a DM to another handle—and covers different identity types. It doesn't explicitly name alternative tools or state 'use this instead of X', but the context is sufficient for most agents to select it over siblings like send or create_channel. No exclusions are given, but the purpose is self-evident.

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