CallMCP — Phone Call MCP Server

Draft Email Campaign

draft_email_campaign

Save an email campaign for the owner to review: a subject, a plain-text body, the customers to email (lead_ids, each with recorded email permission) and the verified sender. Returns the campaign id and the fingerprint of this exact revision. Sends nothing; the owner approves it with approve_email_campaign and it only goes out after launch_email_campaign. Needs an admin of the business. 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>",
      "sender_id": "<sender_id>",
      "subject": "<subject>",
      "text": "<text>",
      "lead_ids": "<lead_ids>"
    },
    "name": "draft_email_campaign"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	The plain-text email body.
`design`	No	Optional structured email design. text must equal its rendered text version; no raw HTML. The owner approves the exact HTML and text.
`subject`	Yes	The email subject.
`lead_ids`	Yes	The customers (lead ids) to email; each needs recorded email permission.
`sender_id`	Yes	The verified sender to send from.
`business_id`	Yes	The business that sends the email.
`daily_limit`	No	Optional: most emails sent per day (default: the most the sender and the Kai level allow).

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.8/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, idempotent=false), the description discloses the return values (campaign id plus revision fingerprint), the non-sending nature of the write, the admin permission requirement, and the delivery eligibility rules (verified sending domain, recorded email permission, do-not-email exclusion, daily Kai-level cap). These are exactly the behavioral facts an agent cannot get from the annotation flags.

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?

Three sentences, front-loaded with the action and payload, then the workflow, then the constraints — no filler. The final sentence is dense and runs long with stacked eligibility conditions, which costs a point but every clause carries information.

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 non-idempotent mutation with nested design object and an output schema, the description covers what is written, what is returned, who may call it, and which downstream tools continue the flow. Nothing an agent needs before calling 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 the schema already defines all seven parameters, but the description adds real constraint meaning: lead_ids must each carry recorded email permission, sender must be verified, and daily_limit is bounded by what the sender and Kai level allow. That goes beyond the field-level descriptions, though it does not add syntax or format detail.

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 — 'Save an email campaign for the owner to review' — and immediately enumerates the payload (subject, plain-text body, lead_ids, verified sender). This clearly separates it from approve_email_campaign and launch_email_campaign, which the description names as later steps in the workflow.

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

Usage Guidelines5/5

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

It states explicitly what this tool does not do ('Sends nothing') and routes the agent to the correct alternatives with their order: approve_email_campaign for approval, launch_email_campaign for sending. The admin prerequisite is also stated, so the agent knows the call will fail for non-admins.

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.