Skip to main content
Glama

Apuchat

by io.github.opcastil11

make_remote_link

Retrofit a phone-control link onto an EXISTING channel. Use when agents are already in a channel and the human shows up later wanting to drive from a phone — instead of creating a new channel and migrating everyone, this mints a phone identity + (if not already set) an owner_password, and returns a mobile_url + QR pointing at the SAME channel. Required args: channel_id, channel_token (proves the caller is authorized on the channel), session_token (the account the phone identity will be minted on — required because the phone needs an identity_key to join under require_identity=true channels). Compared to open_remote_control: this DOES NOT mint a new channel, DOES NOT mint an agent identity (the agent — you — is presumed to already be in the channel), and DOES NOT change trust_mode / require_identity / session_ttl (whatever the channel was created with stays). It only adds the phone affordance. If the channel ALREADY has an owner_password set, this tool does NOT rotate it (would invalidate every peer who joined with the old one); the response sets owner_password_existing: true and owner_password: null, and you should tell the operator to use the password they already have OOB. If the channel had no password, one is minted and returned in owner_password — relay it OOB to the human; they type it on /remote after opening mobile_url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
channel_idYesThe existing channel id (e.g. 'silly-otter-6739').
channel_tokenYesBearer token for the channel — proves caller is authorized.
session_tokenYesAccount session token. The phone identity is minted on this account (so it shows up in /account → Identities). Required.

Schema Changelog

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

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden — and fully delivers. It discloses exact side effects: mints a phone identity, mints/returns an owner_password if none exists, sets owner_password_existing flag when there's already one, and explicitly states the tool does NOT rotate an existing password to avoid invalidating peers. Also covers auth requirements (channel_token proves authorization) and return values (mobile_url, QR).

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 dense and information-rich but also quite lengthy. Every sentence earns its place — the contrast with open_remote_control, password rotation semantics, and OOB relay instructions are all essential. However, it could be trimmed or structured with clearer segmentation (the run-on paragraph blends purpose, parameters, and operational steps in one block).

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 mutation tool with no annotations and no output schema, this description is exceptionally complete. It covers the response fields returned (mobile_url, QR, owner_password, owner_password_existing: true/false), the side effects on the channel's existing settings, and clear operational steps for the operator including what to tell the human (type the password on /remote after opening mobile_url). Nothing material is left unexplained.

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 coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds real value beyond this: it explains WHY session_token is required (the phone needs an identity_key to join under require_identity=true channels) and clarifies that channel_token proves caller authorization. This goes beyond the schema's attribute-level descriptions.

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 specific verb+resource ('Retrofit a phone-control link onto an EXISTING channel') and explicitly contrasts with the sibling tool `open_remote_control`, distinguishing exactly what this tool does not do (mint channel, mint agent identity, change trust settings). This is a textbook example of purpose clarity.

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?

Explicitly states when to use ('agents are already in a channel and the human shows up later wanting to drive from a phone') and names the alternative `open_remote_control` with a bullet-list comparison of what each does. Also provides operational guidance on when the tool does/doesn't rotate the password and how to relay results OOB to the operator.

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