CallMCP — Phone Call MCP Server

Send Kai Into a Meeting

join_meeting

Idempotent

Send Kai into a Zoom, Google Meet, Microsoft Teams or Webex meeting by its link. Kai joins under the agent name, takes notes, and emails the owner a summary when the meeting ends. If the meeting has a waiting room, the host must admit Kai. In the default listen mode it answers out loud when someone says its name and counts against the plan's monthly meeting minutes (a business whose plan includes none gets its first hour free, once); avatar mode joins with a talking video face and counts one avatar meeting.

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": {
      "meeting_url": "<meeting_url>"
    },
    "name": "join_meeting"
  }
}

Input Schema

Name	Required	Description
`mode`	No	'listen' (default): joins with a still camera tile and answers out loud when someone says its name. 'avatar': joins with a talking video face; counts as one avatar meeting (separate from meeting minutes; every business gets one free), stays on camera for the first 30 minutes, then continues voice-only and leaves at 60 minutes.
`agent_id`	No	Which agent joins (optional; defaults to the business's first agent).
`bot_name`	No	Name shown in the meeting and the name people say to get a reply (optional; defaults to the agent's name). Must be a short, speakable name.
`avatar_id`	No	Avatar mode only: which stock face to use (optional; an unknown id returns the list of valid ones).
`business_id`	No	Business ID (required when the token can access several businesses).
`meeting_url`	Yes	The meeting link, e.g. https://meet.google.com/abc-defg-hij or a zoom.us join link.
`instructions`	No	Context for this meeting only, e.g. "This is an onboarding call for a new customer; they need help with setup" (optional, up to 2000 characters).
`camera_image_url`	No	Public https link to a .jpg shown as the camera tile (optional).

Output Schema

Name	Required	Description
`error`	No	Present when success is false
`meeting`	No
`success`	Yes	Whether the tool completed successfully

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only establish readOnly=false, openWorld=true, idempotent=true, destructive=false. The description goes well beyond them by disclosing the join identity (agent name), side effects (note-taking and an emailed summary at meeting end), the waiting-room dependency on the host, and billing consequences per mode including the one-time free first hour.

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?

Five front-loaded sentences, each carrying distinct information about scope, effects, prerequisites, and cost. It is dense but not padded; only the billing sentence could be trimmed since the mode enum already covers avatar accounting.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that has side effects, multiple modes, and quota implications, the description covers the essentials, and the presence of an output schema removes the need to explain return values. Remaining gaps, such as failure behavior when the link is invalid or the agent is refused admission, are moderate rather than critical.

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?

With 100% schema coverage the baseline is 3, and the description does add meaning the schema does not carry in full: the listen-mode minutes consumption and the one-time free hour for a business whose plan includes none. The avatar quota detail largely repeats the mode enum description, which keeps it short of a 5.

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 and resource: 'Send Kai into a Zoom, Google Meet, Microsoft Teams or Webex meeting by its link.' The enumeration of platforms plus 'by its link' scopes it clearly enough to distinguish it from a phone-oriented sibling like join_call without needing to name it.

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 supplies real operational context: waiting-room admission by the host, default listen mode, and the fact that each mode draws on different plan quotas. What is missing is explicit routing guidance, e.g. when to prefer this over join_call or leave_meeting, so the agent must infer that from the platform list.

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 tools Inspect

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.