CallMCP — Phone Call MCP Server

Launch Email Campaign

launch_email_campaign

Destructive

Queue an owner-approved email campaign for sending to real customers, within its daily limit. Business owner only. Emails cannot be unsent once delivered; cancel_email_campaign stops what has not gone out yet. A queued result is not proof any email was delivered. Campaign email only goes from the business’s own verified sending domain, to customers with recorded email permission who are not on the do-not-email list, within the daily amount the business’s Kai level allows.

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": {
      "business_id": "<business_id>",
      "campaign_id": "<campaign_id>"
    },
    "name": "launch_email_campaign"
  }
}

Input Schema

Name	Required	Description	Default
`business_id`	Yes	The business that sends the email.
`campaign_id`	Yes	The approved campaign.

Output Schema

Name	Required	Description
`id`	No
`code`	No
`error`	No	Present when success is false
`action`	No
`status`	No
`success`	Yes	Whether the tool completed successfully
`senderId`	No
`fingerprint`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 12, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already flag destructive=true, openWorld=true and idempotent=false, and the description adds real substance on top: emails cannot be unsent, cancellation only affects what has not yet gone out, and a queued result is not proof of delivery. It also discloses the eligibility gates (verified sending domain, recorded consent, do-not-email exclusion, Kai-level daily cap), which are exactly the behavioral facts an agent needs before invoking a destructive, non-idempotent action.

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 critical irreversible-action warning is front-loaded in the second sentence and the eligibility constraints are consolidated rather than scattered. The final sentence is long and packs several independent restrictions together, which slightly hurts scanability but the content is not 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 two-parameter destructive action with an output schema, the description covers preconditions (owner approval, verified domain, consent, do-not-email list, daily cap) and the irreversibility caveat, and it correctly avoids restating return values since an output schema exists. Nothing an agent needs in order to call it safely is missing.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters already carry descriptions (business_id, campaign_id), so the schema does the heavy lifting. The description adds contextual meaning about what makes a campaign eligible but says nothing further about the parameters themselves, which is the expected baseline here.

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+resource ("Queue an owner-approved email campaign") and immediately scopes it ("sending to real customers, within its daily limit"). It also explicitly separates this tool from cancel_email_campaign, so an agent can distinguish it from the sibling without reading either 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 states the key precondition ("owner-approved campaign", "Business owner only") and names the alternative action for undoing sends ("cancel_email_campaign stops what has not gone out yet"). It doesn't explicitly route the agent through the approve/draft siblings first, so the when-to-use picture is clear but not fully enumerated.

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.