CallMCP — Phone Call MCP Server

Request Email Sending Domain

request_email_sender

Destructive

Set up a sending address for a business's email campaigns on a domain the business controls (for example mail.example.com). Registers the domain with the email delivery provider and returns the DNS records the owner must add where the domain is hosted. May replace an existing reply address, enabled state and sending limit, and may provision provider inbound routing, inbox and webhook. Sends no email. The sender becomes ready on its own once the records verify; check_email_sender re-checks now. 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>",
      "domain": "<domain>",
      "from": "<from>",
      "reply_to": "<reply_to>"
    },
    "name": "request_email_sender"
  }
}

Input Schema

Name	Required	Description
`from`	Yes	The From address on that domain.
`domain`	Yes	The sending domain, e.g. mail.example.com.
`reply_to`	Yes	Where customer replies go. Must also be an address on that domain.
`business_id`	Yes	The business that sends the email.

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

A3.9/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description usefully adds what is destroyed or provisioned: it "may replace an existing reply address, enabled state and sending limit, and may provision provider inbound routing, inbox and webhook". The async lifecycle ("becomes ready on its own once the records verify") and "Sends no email" also add real signal. However, the closing sentence about campaign eligibility, permission and Kai-level daily limits describes downstream sending policy rather than this call's behavior, so it dilutes rather than deepens behavioral disclosure.

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 definition is front-loaded: purpose, then side effects, then readiness, then prerequisites. Most sentences earn their place, but the final sentence on campaign eligibility, consent and Kai-level daily amounts is tangential to registering a domain and could be cut without losing invocation guidance.

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?

An output schema exists and annotations cover the safety profile, so the description only needs to cover prerequisites, side effects and lifecycle – all of which it does. It is complete enough to call correctly; only failure modes (domain already registered elsewhere, domain not verified) are untouched.

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 each of the four required fields already carries its own description, so the schema does the heavy lifting. The description restates "domain the business controls (for example mail.example.com)" and implies reply_to must live on that domain, but adds no format, validation or constraint detail beyond the schema (e.g. what happens on a mismatched domain). Baseline 3 is appropriate.

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-plus-resource ("Set up a sending address ... on a domain the business controls") and immediately narrows what it actually does ("Registers the domain with the email delivery provider and returns the DNS records"). It also names the sibling boundary ("Sends no email", "check_email_sender re-checks now"), so an agent can distinguish it from request_* and check_email_sender without opening any 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 gives a clear trigger (business needs its own verified sending domain), a hard prerequisite ("Needs an admin of the business"), and a routing hint toward the alternative ("check_email_sender re-checks now") instead of calling this again. It stops short of an explicit "do not call this if a sender already exists" exclusion, which is the only real gap.

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.