Skip to main content
Glama
Omnidim

@omnidim-ai/mcp-server

by Omnidim

createBulkCall

Destructive

Launch a bulk-call campaign by providing a name, phone number ID, and contact list; optionally add rotation, filtering, scheduling, retries, or drafts to control dialing behavior.

Instructions

Create a new bulk-call campaign. Only name, phone_number_id and a contact_list are needed to dial a list now; every other field adds one behavior on top (drafts, rotation, filtering, scheduling, retries, dynamic feeding).

The guide below the field reference walks the whole journey: the first campaign and its response, each behavior with a working request, every refusal message with its fix, and the endpoints that operate a campaign once it runs.

(Tags: Bulk calls)

Input Schema

NameRequiredDescriptionDefault
requestBodyYesThe JSON request body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.11.1
    • addedInput schema / properties / requestBody / properties / bot_id
      Added value: +{
      +  "description": "Agent to run the campaign. Defaults to the agent attached\nto `phone_number_id`; required when the number has none.\n",
      +  "type": "number"
      +}
    • addedInput schema / properties / requestBody / properties / call_conditions
      Added value: +{
      +  "description": "Dial only the contacts that match every condition; the rest\nare kept as `Skipped`. See Filtering in the guide below.\n",
      +  "items": {
      +    "properties": {
      +      "column": {
      +        "description": "Key on the contact row to test.",
      +        "type": "string"
      +      },
      +      "operator": {
      +        "default": "equals",
      +        "description": "`contains` is case-insensitive. `greater_than` and\n`less_than` compare numerically, and a row whose value\nis not a number fails the condition rather than\nerroring.\n",
      +        "enum": [
      +          "equals",
      +          "not_equals",
      +          "contains",
      +          "greater_than",
      +          "less_than"
      +        ],
      +        "type": "string"
      +      },
      +      "value": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "column",
      +      "operator",
      +      "value"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / requestBody / properties / contact_list / description
      Previous value: -"Array of contact objects. Each row needs `phone_number`.\nAny other key you add on the row (e.g. `customer_name`,\n`account_id`, `priority`) is passed to the agent as a\ncontext variable for that specific call, so the agent\ncan reference it during the conversation.\n\nRequired for static campaigns. Optional when `is_dynamic`\nis `true` (you can omit it and add contacts later via the\nwebhook).\n"New value: +"Who to call. Each row needs `phone_number`; any other key\nreaches the agent as context for that one call.\n"
    • changedInput schema / properties / requestBody / properties / is_dynamic / description
      Previous value: -"Set to `true` to create a dynamic campaign that accepts\ncontacts in real time via the Add contact to dynamic\ncampaign webhook. When `true`, `contact_list` is optional\nand may be omitted to start the campaign empty.\n"New value: +"A dynamic campaign stays alive accepting contacts via the\nadd-contact webhooks, and `contact_list` becomes optional.\n"
    • changedInput schema / properties / requestBody / properties / phone_number_id / description
      Previous value: -"Your phone number id to use for making calls."New value: +"The number this campaign calls from. With a `rotation`, the\nrotation numbers dial instead and this one is the standby.\n"
    • changedInput schema / properties / requestBody / properties / retry_config / properties / retry_limit / default
      Previous value: -0New value: +1
    • changedInput schema / properties / requestBody / properties / retry_config / properties / retry_limit / description
      Previous value: -"Maximum number of retry attempts (0–5)."New value: +"Retry attempts, 1 to 10. To disable retries omit it and\nleave `auto_retry` false; never send `0`.\n"
    • changedInput schema / properties / requestBody / properties / retry_config / properties / retry_limit / maximum
      Previous value: -5New value: +10
    • changedInput schema / properties / requestBody / properties / retry_config / properties / retry_limit / minimum
      Previous value: -0New value: +1
    • addedInput schema / properties / requestBody / properties / rotation
      Added value: +{
      +  "description": "Rotate the campaign across several of your numbers, so no\nsingle number burns out. See Rotation in the guide below.\n",
      +  "properties": {
      +    "calls_per_number": {
      +      "default": 50,
      +      "description": "Calls before moving on. Used by `fixed_count` and `both`.",
      +      "type": "number"
      +    },
      +    "fallback": {
      +      "default": "pause",
      +      "description": "When every number is unhealthy: `pause` the campaign,\nor `continue_best` with the healthiest one.\n",
      +      "enum": [
      +        "pause",
      +        "continue_best"
      +      ],
      +      "type": "string"
      +    },
      +    "health_threshold": {
      +      "default": 30,
      +      "description": "Health score below which a number is rotated away from.\nUsed by `cpr_threshold` and `both`.\n",
      +      "type": "number"
      +    },
      +    "numbers": {
      +      "description": "The numbers to rotate across; each must be yours and\nlisted once.\n",
      +      "items": {
      +        "properties": {
      +          "phone_number_id": {
      +            "description": "One of your numbers, from List phone numbers.",
      +            "type": "number"
      +          },
      +          "sequence": {
      +            "default": 10,
      +            "description": "Rotation order. Lowest dials first.",
      +            "type": "number"
      +          }
      +        },
      +        "required": [
      +          "phone_number_id"
      +        ],
      +        "type": "object"
      +      },
      +      "minItems": 1,
      +      "type": "array"
      +    },
      +    "strategy": {
      +      "default": "fixed_count",
      +      "description": "When to move to the next number: every\n`calls_per_number` calls, on low health score, both, or\nnever.\n",
      +      "enum": [
      +        "fixed_count",
      +        "cpr_threshold",
      +        "both",
      +        "none"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "numbers"
      +  ],
      +  "type": "object"
      +}
    • addedInput schema / properties / requestBody / properties / save_as_draft
      Added value: +{
      +  "default": false,
      +  "description": "Store the campaign without dialing; start it later with the\nstart endpoint. See Drafts in the guide below.\n",
      +  "type": "boolean"
      +}
  2. First observedv0.9.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds real context — that the campaign dials immediately unless saved as a draft, and that the reference documents refusal messages and their fixes — but says nothing about authorization requirements, side effects on existing campaigns, or idempotency.

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 and the minimum payload are front-loaded in the first sentence, with the behavior taxonomy following immediately. The second paragraph leans on phrasing about a 'journey' and a guide that isn't contained in the definition, which is slightly promotional but still short and earns its place as a pointer to documentation.

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 deeply nested, behavior-dense tool with 100% schema coverage and annotations covering safety and openness, the description supplies the missing orientation layer: minimum required input and a taxonomy of optional behaviors. Return values are not described, but no output schema exists and the description points to a reference that documents the response.

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 100%, so the baseline is 3 and the schema does the heavy lifting. The description nonetheless adds a synthesis the schema lacks: it identifies the minimal required trio (name, phone_number_id, contact_list) and groups every remaining field by the single behavior it activates, giving the agent a mental model for progressive configuration.

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?

The description states a specific verb and resource ('Create a new bulk-call campaign') and immediately clarifies the minimum viable payload, so the agent knows exactly what the call produces. It gestures at sibling territory ('the endpoints that operate a campaign once it runs') but never names a sibling tool, so differentiation stays implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does say what is needed to 'dial a list now' versus the incremental fields that layer on behaviors (drafts, rotation, filtering, scheduling, retries, dynamic feeding), which is genuinely useful field-selection guidance. However it gives no guidance on when to choose this tool over alternatives such as dispatchCall or createWorkflow, and no prerequisites or exclusions are stated.

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