Skip to main content
Glama
pghdma

CallRail MCP

by pghdma
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

create_outbound_call

Place an outbound call. THIS ACTUALLY DIALS REAL PHONES.

Instructions

Place an outbound call. THIS ACTUALLY DIALS REAL PHONES.

CallRail dials business_phone_number FIRST; once that leg is answered it dials customer_phone_number and bridges the two. Both legs cost minutes against your bundle. Misuse can constitute unlawful telemarketing, so verify consent.

US and Canadian numbers only (CallRail does not support outbound to the UK or Australia via this endpoint).

You must pass confirm_dialing=True to actually place the call.

Args: caller_id: The number shown to the recipient. Must be one of your CallRail tracking numbers or a verified Outbound Caller ID. E.164 format. business_phone_number: The FIRST leg CallRail dials (your agent's phone). E.164 format. customer_phone_number: The SECOND leg, bridged in once the business leg answers. E.164 format. confirm_dialing: REQUIRED. Set True to actually dial. Returns an error envelope if False (default). recording_enabled: Record this call. outbound_greeting_text: Text-to-speech greeting played to the customer. outbound_greeting_recording_url: Public URL of an audio greeting, used instead of outbound_greeting_text. account_id: Auto-resolves if omitted.

Returns: The call object CallRail creates (id, etc.).

NOTE (v1.2.0): earlier versions sent {"from", "to"}, which are not fields CallRail accepts, so every call failed. The parameter names above match the documented request body.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
caller_idYes
account_idNo
confirm_dialingNo
recording_enabledNo
business_phone_numberYes
customer_phone_numberYes
outbound_greeting_textNo
outbound_greeting_recording_urlNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.2.2
    • addedInput schema / properties / business_phone_number
      Added value: +{
+  "title": "Business Phone Number",
+  "type": "string"
+}
    • addedInput schema / properties / caller_id
      Added value: +{
+  "title": "Caller Id",
+  "type": "string"
+}
    • removedInput schema / properties / company_id
      Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Company Id"
-}
    • addedInput schema / properties / customer_phone_number
      Added value: +{
+  "title": "Customer Phone Number",
+  "type": "string"
+}
    • removedInput schema / properties / from_number
      Removed value: -{
-  "title": "From Number",
-  "type": "string"
-}
    • addedInput schema / properties / outbound_greeting_recording_url
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Outbound Greeting Recording Url"
+}
    • addedInput schema / properties / outbound_greeting_text
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Outbound Greeting Text"
+}
    • addedInput schema / properties / recording_enabled
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Recording Enabled"
+}
    • removedInput schema / properties / to_number
      Removed value: -{
-  "title": "To Number",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "from_number",
-  "to_number"
-]New value: +[
+  "caller_id",
+  "business_phone_number",
+  "customer_phone_number"
+]
  2. First observedv1.0.0

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 behavioral burden and does so thoroughly: it discloses that calls actually dial real phones, explains the two-leg dialing order and bridging behavior, warns that both legs consume minutes, flags legal risk, and mandates confirm_dialing=True as an explicit safety gate. This far exceeds typical descriptions.

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

Conciseness5/5

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

The description is front-loaded with the most critical warning before diving into details. The parameter list is compact but every entry adds semantic value, and the version note about old parameter names prevents a known failure mode. No sentence is wasted.

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 high-stakes, side-effectful operation with eight parameters and no annotations, the description covers action, safeguards, geography, billing impact, parameter semantics, and return behavior. An output schema already exists, so the return-value note is sufficient. Nothing material is missing for an agent to invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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 compensate for all eight parameters. It explains every parameter in plain terms, adds E.164 format expectations, identifies which leg each phone number represents, clarifies that confirm_dialing defaults to False and returns an error envelope, and notes that account_id auto-resolves. This fully compensates for the bare schema.

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: 'Place an outbound call.' It adds a high-value qualifier, 'THIS ACTUALLY DIALS REAL PHONES,' which makes the tool's purpose unmistakable and differentiates it from read-oriented siblings like list_calls, get_call, and call_summary.

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?

The description gives clear context for when to use the tool and includes explicit exclusions: 'US and Canadian numbers only' and 'CallRail does not support outbound to the UK or Australia via this endpoint.' It also stresses consent verification as a prerequisite. It does not name alternative tools such as call_eligibility_check, but the usage context is otherwise strong.

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

Deploy Server

Other Tools