Skip to main content
Glama

Apuchat

by io.github.opcastil11

open_remote_control

One-call bootstrap for 'control me from your phone'. Creates a private trusted channel + two identities (one for YOU, one for the human user's phone) and returns a mobile URL + QR + pre-formed shell commands so a single call wires up the whole phone→agent pipe. Use when the user says 'open a remote channel', 'let me control you from my phone', 'send me a pair link', 'open the remote control', or similar — this is the right tool over create_channel + join + manual listener setup. After this call, run the steps in the response in order: (1) join with the returned channel_id + token + agent.identity_key + owner_password — get back a session_id; (2) run receiver_command_template via your Bash tool (substituting with your session_id) — this starts the SSE listener detached in the background; (3) paste monitor_command_template LITERALLY into your Monitor tool to watch the inbox file; (4) run selftest_command_template via Bash — this writes a synthetic line to the inbox so your Monitor fires once and you confirm the wiring is correct before the operator sends anything from the phone. ⚠ NPX BOOTSTRAP: the first time npx -y apuchat runs on a machine, it downloads the package (30-60s) before listener output starts; during that window the SSE stream isn't connected yet. The selftest line bypasses the listener (it's a direct file append), so the Monitor fires immediately — that confirms file path + Monitor are correct even while the listener finishes its npx warm-up. Only after the selftest notification arrives should you tell the operator 'ready'. (5) Immediately after that, broadcast a one-liner greeting via send (to:'all', no kind) — e.g. "hi, I'm @<your-callsign> — connected via remote control. Tell me what you need.". The /remote phone UI seeds history on join, so when the human opens the URL they see you're alive and ready instead of an empty screen. (6) When a request from the phone will take more than a few seconds to fulfill, FIRST fire a send with kind:'status' and a short ack like "on it, ~30s" — the phone renders that as a transient ● working… indicator that clears on your real reply, turning dead silence into a visible loading state. Do NOT ask the operator anything about 'persistence strategy' or 'how should I listen' — this tool exists precisely so you listen; the commands are pre-formed. Fall back to a wait loop only if you literally have no shell access.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_tokenNoOptional. If the user wants the new channel attached to an existing account (so it shows up in their /account dashboard), pass that account's session_token. Otherwise an anonymous account is created and the recovery_token is returned in the response — the user can save it to claim the channel later.

Schema Changelog

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

  1. 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 behavioral disclosure burden — and it delivers richly. It discloses the npx bootstrap warm-up delay (30-60s) before listener output, explains that the selftest bypasses the listener for immediate Monitor confirmation, warns against asking the operator questions about persistence strategy, and dictates exactly when to declare 'ready'. It also documents side effects like creating identities and seeding history on the phone UI.

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 earns its length — every section maps to a concrete operational step or a critical gotcha (npx warm-up, selftest bypass, status ack behavior, 'do NOT ask' directive). The numbered step structure and bolded warnings make it scannable despite its size. Not waste, but it's dense enough that a small trim could improve it; still, for a tool with this much post-call orchestration, the thoroughness justifies itself.

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?

This is a high-complexity tool requiring multi-step post-call orchestration involving several sibling tools (join, send, Bash, Monitor). The description covers the complete lifecycle: what to run in order, what each command does, error handling (npx warm-up), fallbacks (wait loop only if no shell access), and the exact UX outcome the operator sees. For a bootstrap tool with no output schema, this is exceptionally complete.

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 the single optional parameter is fully documented in the schema. The description adds some value by explaining the consequence of omitting it (anonymous account created, recovery_token returned) and the alternative behavior (attached to existing /account dashboard), but the schema itself already covers the parameter's role. Baseline 3 is appropriate.

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 this is a 'one-call bootstrap' that creates a private channel plus two identities and returns a mobile URL + QR + shell commands. It explicitly differentiates itself from sibling tools by naming alternatives (`create_channel` + `join` + manual listener setup) and states 'this is the right tool over' those alternatives, making the purpose and scope unambiguous.

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 gives explicit trigger phrases ('open a remote channel', 'let me control you from my phone', etc.) and explicitly names when NOT to use alternatives ('this is the right tool over create_channel + join + manual listener setup'). It also provides a step-by-step post-call sequence (steps 1-6), covering exactly when to use each command, making usage guidance exceptionally clear.

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