Skip to main content
Glama
Sign In

CallMCP — Phone Call MCP Server

by ai.callmcp
OverviewDiscussionsAdmin

Check Call Status

check_call_status
Read-onlyIdempotent

Check the status of a call by its ID: while it is live, the latest turns of the conversation (live_transcript) and any question Kai is waiting on (pending_question); after, a voicemail message left, or the business calling back. Also takes the intent_id of a call scheduled for calling hours and says when it goes out

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "call_id": "<call_id>"
    },
    "name": "check_call_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
call_idYesThe call ID to check, or the intent_id make_call returned for a scheduled call

Output Schema

NameRequiredDescriptionDefault
callNo
errorNoPresent when success is false
successYesWhether the tool completed successfully
live_transcriptNoLatest turns while the call is live, oldest first (up to 30); null once it ends. Use get_transcript for the full call.
pending_questionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / live_transcript
      Added value: +{
+  "description": "Latest turns while the call is live, oldest first (up to 30); null once it ends. Use get_transcript for the full call.",
+  "items": {
+    "properties": {
+      "speaker": {
+        "enum": [
+          "kai",
+          "other"
+        ],
+        "type": "string"
+      },
+      "text": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}
  2. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered; the description adds genuine value by disclosing that the response shape varies by call state (live turns, pending question, voicemail, callback, scheduled send time). It omits edge behavior such as invalid/expired IDs or eventual-consistency of live transcripts, so not a 5.

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?

A single front-loaded sentence with a colon-delimited enumeration of states; dense but readable with no filler. The parenthetical field names (live_transcript, pending_question) are useful for mapping to the output, though the phrasing around 'or the business calling back' is slightly elliptical.

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?

The tool is simple (one required parameter) and an output schema exists, so return-value detail is not required; the description nonetheless covers live, post-call, and scheduled cases. Nothing an agent needs in order to call it correctly is missing.

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%, so baseline is 3; the description earns an extra point by clarifying the dual semantics of the single argument — a call_id for existing/live calls versus the intent_id returned by make_call for scheduled calls — and by tying intent_id to a 'when it goes out' response.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Check the status of a call by its ID') and goes further by enumerating what status means in each lifecycle state (live transcript, pending question, voicemail, callback). It does not explicitly distinguish itself from siblings that also return status-like data (e.g. get_call_recording), which keeps it at 4 rather than 5.

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?

Gives clear usage conditions: pass a call_id while live or after the call, or pass an intent_id for a call scheduled within calling hours. It does not name an alternative tool or state when-not to use this one, so it stops short of full routing guidance.

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

All CallMCP — Phone Call MCP Server 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