Skip to main content
Glama

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.

  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, the description carries full responsibility and does so thoroughly. It discloses side effects like anonymous account creation and recovery_token, the npx bootstrap delay, the selftest bypassing the listener, the status indicator behavior, and the requirement to send a greeting. This level of detail far exceeds typical descriptions and leaves little ambiguity about what will happen.

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 densely packed with essential procedural steps and caveats. It is front-loaded with a clear one-liner purpose and uses numbered steps for the post-call workflow. Some tightening could separate the tool description from the operation guide, but every sentence earns its place given the tool's complexity.

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?

With no output schema or annotations, the description fully compensates by listing return deliverables (mobile URL, QR, shell commands) and referencing fields like channel_id, token, identity keys. It also provides a complete step-by-step workflow from call through verification and fallback, leaving no major gaps for an agent to execute successfully.

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?

The only parameter, session_token, is fully documented in the schema (100% coverage), so the description need not add param-level detail. The description doesn't elaborate on it beyond what's in the schema, but the baseline of 3 applies because the schema already provides complete meaning.

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 bootstraps remote control by creating a private trusted channel and two identities, returning a mobile URL, QR, and pre-formed shell commands. It names specific trigger phrases and explicitly differentiates it from alternatives like create_channel + join, making its purpose unambiguous and distinctive.

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?

It explicitly specifies when to use the tool (e.g., 'open a remote channel', 'let me control you from my phone') and identifies it as the right tool over create_channel + join + manual listener setup. It also offers clear exclusionary guidance (e.g., 'Do NOT ask the operator anything about persistence strategy' and fallback to wait only if no shell access), providing strong usage boundaries.

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.