Skip to main content
Glama

Call Me

by com.callmemcp
OverviewDiscussionsAdmin

Call the human

call
Destructive

Ring the human's iPhone, read question aloud word for word, and return what they say back. It does not have to be a question: an update or a summary of the day ahead works too, up to 2000 characters (about two minutes of speech). Waits up to ~30s; if the result comes back status "ringing" or "in_call", follow up with poll_result. On a local client, read to from ~/.aiphone/config.json → user_number; this hosted server cannot read that file itself. It is a Call Me app number, not a regular phone number. If missing, returns setup_required with the App Store link. Pass a previous session_token to stay in the same thread on their phone. By default the call is a conversation: after their answer the line stays up for say until you hang_up; keep_open=false hangs up after one answer. language ("tr", "de", ...) is the language you are speaking; the call's own short lines follow it. Default English.

Input Schema

NameRequiredDescriptionDefault
toNo
languageNo
questionYes
keep_openNo
from_labelNoSomeone's AI
session_tokenNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / keep_open / anyOf
      Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / keep_open / default
      Previous value: -falseNew value: +null
    • removedInput schema / properties / keep_open / type
      Removed value: -"boolean"
  2. Changed2 schema fields changed
    • addedInput schema / properties / keep_open
      Added value: +{
+  "default": false,
+  "title": "Keep Open",
+  "type": "boolean"
+}
    • addedInput schema / properties / language
      Added value: +{
+  "default": "",
+  "title": "Language",
+  "type": "string"
+}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Despite annotations carrying the safety profile (openWorldHint, destructiveHint), the description adds substantial behavioral context beyond them: the ~30s wait, the ringing/in_call/setup_required return statuses, the requirement to read `to` from ~/.aiphone/config.json, the 'Call Me app number, not a regular phone number' constraint, and the default conversation mode with an open line until `hang_up`. None of this is recoverable from the annotations.

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 core action is front-loaded and no sentence is filler — every clause carries a distinct operational fact. It is dense and slightly run-on (a laptop-vs-hosted-client caveat jammed into the middle), but it does not pad for length's sake.

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, the description must explain return behavior, and it does: the spoken reply, the ringing/in_call statuses that trigger polling, and setup_required with an App Store link when `to` is missing. Combined with the config-file sourcing and call-lifetime semantics, an agent has everything needed to invoke and follow up 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 0%, so the description must carry all parameter meaning, and it does: `question` (read verbatim, ~2000 chars / two minutes), `to` (from config.json user_number, Call Me number), `session_token` (thread continuity), `keep_open` (one-answer vs open line), and `language` (spoken language, English default). Only `from_label` is left unexplained, which is the sole shortfall for a 6-param tool.

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 opening sentence states a precise verb+resource chain: ring the human's iPhone, read `question` aloud word for word, return their reply. This is unambiguously distinct from siblings like `text`, `say`, and `hang_up`, and an agent can select it without opening the schema.

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?

It gives concrete routing guidance: follow up with `poll_result` when status is 'ringing' or 'in_call', pass a prior `session_token` to stay in the same thread, and set `keep_open=false` to hang up after one answer. It also broadens use ('does not have to be a question'). The one gap is that it never says when to prefer the sibling `text` over placing an actual call.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Call Me toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources