Skip to main content
Glama

Apuchat

by io.github.opcastil11

open_video_call

One-call bootstrap for 'video-call me' — talk to the human out loud, face to face. Same as open_remote_control (mints a private trusted channel + your identity + the human's identity + PIN + the pre-formed listener/reply commands), but ALSO returns a call_url: a meet.apuchat.com/call link that opens a Google-Meet-style video-call UI where your replies are spoken aloud and the human talks back by voice. Use when the human says 'video-call me', 'let me talk to you', 'call me', 'I want to speak out loud', 'talk to you like a person', or similar. YOUR side is IDENTICAL to a phone remote: you join and receive/reply plain TEXT — the human's speech is transcribed to text in their browser, and your text replies are spoken aloud in their browser. No audio/video flows through you; it stays a text channel underneath (max 8192 chars/msg). After this call: (1) join with the returned channel_id + token + agent.identity_key + owner_password; (2) arm receive with receiver_command_template (+ monitor_command_template or waiter_command_template); (3) run selftest_command_template; (4) relay operator_handoff_video to the human VERBATIM (it leads with a QR-page link + the one-tap call_url + the PIN-protected call_url_protected + the PIN). On each wake fire a send with kind:'status' first (the call shows an 'agent is working…' pose), then reply with reply_command_template.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
session_tokenNoOptional. Pass an account's session_token to attach the new channel to that account (shows up in /account). Otherwise an anonymous account is minted and a recovery_token is returned.

Schema Changelog

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

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses critical behaviors: that no audio/video flows through the agent (text channel underneath), max 8192 chars/msg, the return of a PIN-protected call_url, the identity/PIN minting, and the exact operational sequence. Rich behavioral detail — the gap is only that it doesn't explicitly state side effects like account minting coercion, which is partially implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and information-rich but runs long (roughly 200+ words in a single paragraph). It front-loads the core purpose well and uses bold for emphasis, but the step-by-step numbered sequence inside a single run-on sentence structure makes it harder to parse. Valuable content, but could be better structured with explicit line breaks/numbers for the post-call steps.

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 one-parameter tool with no output schema, this description is remarkably complete. It covers the operation setup, the post-call workflow, the wake behavior, the return artifacts, message limits, and how the human/agent interaction works. Even without an output schema, the agent has enough detail to bootstrap the entire video call flow correctly.

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% and the single parameter (session_token) is fully documented in the schema itself. The description references account minting/recovery_token behavior which aligns with the schema's session_token description. With full schema coverage, baseline 3 is appropriate; the description adds no further parameter semantics beyond what the schema already documents.

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 for video-call me' that returns a call_url for a Google-Meet-style video-call UI, distinguishing it from open_remote_control (which lacks the call_url). It gives specific verb+resource+outcome and lists exact trigger phrases. Clearly distinguishes from its nearest sibling tool.

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?

Provides explicit usage guidance: when to use ('video-call me', 'call me', etc.), exact step-by-step post-call sequence (join, arm receive, selftest, relay operator_handoff_video verbatim), and behavior on each wake (send status first, then reply). References sibling open_remote_control for comparison. This is exemplary when-to-use guidance.

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