The Model Context Protocol (MCP) is a standard for giving AI assistants structured, typed access to external tools. Instead of writing integration code that calls your API, you describe a set of tools to the agent, and the agent calls them as part of a conversation or autonomous task.
zend.sh ships an MCP server with 58 tools covering the full product surface. Here's what that actually enables.
What the MCP server is
The zend.sh MCP server runs at a fixed HTTP endpoint and speaks the MCP protocol over streamable HTTP transport — the same transport used by Claude.ai's web interface, which means it works with any MCP client that supports SSE-based streaming.
Each tool is typed: inputs are validated, outputs are structured, and errors are returned in a consistent schema. This matters for agents: a tool that sometimes returns a string and sometimes returns an object is hard to reason about reliably. Every zend.sh MCP tool returns a typed response or a structured error, never a free-form string.
The 58 tools cover:
- Inbox management — list, create, pause, resume, delete, health check
- Campaign operations — create, launch, pause, clone, archive
- Contact management — import, search, tag, suppress
- Sequence configuration — create steps, set variants, configure delays
- Deliverability — check DNS health, view blacklist status, get spam scores
- Analytics — fetch campaign stats, inbox performance, bounce/complaint breakdown
- Webhooks — configure endpoints, test delivery, inspect payloads
Full tool reference is in the MCP docs.
Concrete agent use-cases
Provision and launch a campaign conversationally
The natural starting point. Instead of scripting the provisioning + launch flow, you describe it to an agent:
"Provision two fresh inboxes for the domain outreach.acme.com, warm them for 28 days, then launch a three-step sequence targeting the SaaS segment from our leads database. Daily limit of 35 per inbox."
The agent calls the provisioning tool, sets up warmup configuration, imports the relevant contacts, creates the sequence, and launches it. Each step is a typed MCP call — the agent can check the response, handle errors, and adapt if something unexpected happens (for example, if a DNS record is missing and provisioning fails with a structured error pointing to the SPF record).
Monitor health and get a daily brief
Agent: "What's the health summary for all active campaigns?"
→ [calls list_campaigns]
→ [calls get_campaign_stats for each active campaign]
→ [calls get_inbox_health for each associated inbox]
Agent: "Three campaigns active. Campaign 'Q3 outbound — fintech' has a 1.8% bounce rate
on inbox inbox_03ghi — below threshold but climbing. The other two are healthy.
Do you want me to set an alert or reduce the daily limit on that inbox?"The agent isn't just fetching and displaying data — it's reasoning over the results and flagging what needs attention. The structured tool outputs (not free-form text) make it possible to write reliable evaluation logic.
Triage replies conversationally
Reply handling is one of the higher-leverage applications. When a campaign generates replies, an agent can:
- Fetch new replies via the replies tool
- Classify intent (interested, not now, wrong person, out of office, unsubscribe)
- Suppress unsubscribes immediately
- Draft suggested responses for interested replies and queue them for human review
- Tag contacts based on classification for follow-up segmentation
The classification step is where the LLM adds genuine value — it's exactly the kind of unstructured-to-structured transformation that language models are good at. The action steps (suppress, draft, tag) are structured MCP calls with deterministic outcomes.
A/B test analysis and iteration
After a campaign runs for a week with two subject line variants:
"Compare performance of variant A vs variant B on the Q3 fintech campaign. Recommend which to scale."
The agent fetches stats per variant, computes open rate and reply rate for each, and synthesizes a recommendation. If you approve, it calls the update_sequence tool to set the winner to 100% weight and archive the losing variant.
The guardrails that still apply
Giving an agent control over sending doesn't remove the safety mechanisms that protect your sender reputation — it just changes who's triggering them.
Auto-pause on thresholds fires regardless of whether the send was triggered by a human or an agent. If bounce rate exceeds 2% or complaint rate exceeds 0.3%, the inbox pauses. The agent cannot override this via the MCP tools — the tools respect the same business logic as the REST API.
Suppression is enforced at the platform level. An agent calling the contact import tool cannot re-import suppressed addresses — the tool returns a structured response indicating which contacts were skipped and why.
Warmup is not bypassable. If an agent tries to launch a campaign on an inbox that hasn't completed its warmup period, the launch tool returns an error with the current warmup status and the estimated completion date.
DNS health checks run continuously independently of what the agent is doing. The agent can query the current status, but the monitoring isn't contingent on the agent asking.
The pattern here is deliberate: the MCP tools expose the full operational surface, but the safety invariants are enforced in the platform, not delegated to the agent. An agent that makes mistakes (or is adversarially prompted) can't override the sending health guardrails.
Connecting to the MCP server
The MCP server speaks streamable HTTP. In Claude Desktop:
{
"mcpServers": {
"zend": {
"type": "http",
"url": "https://zend.sh/api/mcp",
"headers": {
"Authorization": "Bearer YOUR_API_KEY"
}
}
}
}Any MCP-compatible client that supports streamable HTTP transport works the same way.
The Build pillar docs cover the full connection setup, authentication, and tool reference: /mcp. If you want to see the raw tool schema before connecting, the MCP server exposes a /tools/list endpoint that returns the full typed manifest.