When we walked the Devotel Orbit MCP server's tool surface in August, the honest summary was that a prompt could finish at send: the assistant could send an approved SMS or WhatsApp template, place a call, start a campaign, and report the delivery rate. What it could not do was the work that happens before send. Authoring a template, drafting one with the AI generator, and pointing delivery events at a callback URL all meant leaving the assistant and opening the dashboard. This week's release closes that loop with four write-side tools.
The prompt used to stop at send
The four tools map to the four manual steps an operator used to perform in the console:
- create_template — author a reusable message template for SMS,
WhatsApp, email, RCS, MMS, and the other supported channels. On approval-required channels the template is submitted for carrier review exactly as it is from the dashboard; on platform-only channels it lands ready to send.
- generate_template — describe what the message should achieve and get
back a drafted WhatsApp template (name, body, components, category) ready for your review. Nothing is submitted for approval; the draft waits for a person.
- configure_webhook — register a new webhook endpoint, or update an
existing one's URL, event subscriptions, and active state. Creating one returns the signing secret you use to verify deliveries.
- list_webhooks — inspect the endpoints currently configured for the
workspace before you change one.
The before/after is easiest to see in one sentence: previously the assistant's part in a template launch ended at "here is the approved template, send it", and now the assistant carries the loop from first draft to registered webhook, with the person still sitting at the review and approval steps.
Same backend, same guardrails
None of the four is a parallel integration. Each tool wraps the same backend the dashboard's template editor and webhook settings call, so a template created from a prompt is the same record you open in the dashboard a minute later, and a webhook registered by the assistant delivers the same signed events.
The controls carry over unchanged:
- Scopes and billing. The tools respect the same API-key scopes and
billing as their dashboard equivalents. A key without template write access cannot create a template; there is nothing new to provision.
- Carrier review. Approval-required channels keep their approval path.
create_template submits for review; it does not bypass it, and generate_template submits nothing at all. The draft-to-approval gap stays a human step.
- Server guardrails. The session controls the August post described —
scoped credentials exchanged per task, a per-session spend cap that refuses chargeable calls past a ceiling, and a read-only mode limited to GET tools — apply to the new tools because they are tools on the same server.
Prompt to live: a worked sequence
The full loop, as one conversation:
- Draft. "Draft a WhatsApp template telling customers their order
shipped, with a tracking link placeholder." generate_template returns a named template with body, components, and category — a draft, nothing submitted.
- Review. You read the draft, adjust the wording, and tell the
assistant to create it. create_template submits it; WhatsApp being approval-required, it enters carrier review.
- Register the webhook. "Point delivery events for this workspace at
https://example.com/hooks/orbit." configure_webhook registers the endpoint and returns its signing secret; you store it where your service verifies signatures. (list_webhooks first, if you want to see what is already configured.)
- Send. Once the template is approved, "send the order-shipped
template to +49 151 2345 678" executes against the same account the dashboard shows.
- Receive. Your endpoint receives the delivery event for that send,
signed with the secret from step 3, and the assistant can pull the same delivery status with the read tools.
Draft, review, approve, send, and the webhook hears about the delivery — one prompt surface end to end, with a person at the two steps where a person belongs.
What this means for the read-write server debate
Our September head-to-head scored the four official communications MCP servers on a row labelled "read-write tool calls (send, dial, create)". The authoring tier sharpens what that row should measure. Sending is the last step of the loop; the loop begins with authoring the message and wiring the endpoint that reports its delivery. A server that executes sends but leaves authoring in the console completes half the loop and calls it read-write.
The three objections a careful buyer raises about read-write servers carry over to the authoring tier, and all three still hold:
- Spend risk. Authoring is cheap in the literal sense: creating a
template sends nothing, and registering a webhook has operational consequence, not spend. The spend gate stays where it was, on the chargeable send, behind the per-session cap.
- Scoping. The argument for scoped credentials gets stronger, not
weaker: the same scopes that separate template writes from sends in the dashboard now separate them in the assistant, so a key delegated for sending cannot quietly become a key that authors.
- The human approval step. Approval-required channels keep carrier
review outside the assistant entirely, and generate_template stops at a draft by design. The assistant proposes; a person, or a carrier, approves.
The head-to-head's test protocol — prompt each server with the same action and watch what completes — now has a second instrumented prompt: "draft and register the webhook for this template launch." The servers that cannot pass the first row cannot reach the second.
Disclosure and further reading
One disclosure, standard for vendor-authored posts: we build Devotel Orbit, so treat the framing above as ours. What is stated as live is live — the four tools shipped this week on every account whose API key carries the scopes, at no separate licence fee, and this post claims nothing beyond that.
Set up the connection with the MCP guide in the docs, which carries copy-paste configs for Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, Cline, Zed, and Continue, plus sandbox mode. The send-side surface and the guardrail model are walked in the Orbit MCP server walkthrough, and the competitive field in the four-vendor head-to-head.
Frequently asked questions
Which channels can create_template author for?
SMS, WhatsApp, email, RCS, MMS, and the other supported channels. Approval-required channels are submitted for carrier review exactly as they are from the dashboard; platform-only channels land ready to send.
Does generate_template submit the draft for approval?
No. It returns a drafted WhatsApp template — name, body, components, category — ready for review, and submits nothing. Submitting is a separate, deliberate step via create_template or the dashboard.
What does configure_webhook return?
When creating an endpoint it returns the signing secret for verifying deliveries. It can also update an existing endpoint's URL, event subscriptions, and active state; list_webhooks shows what is configured before you change anything.
Do the new tools cost extra or need new provisioning?
No. They respect the same API-key scopes and billing as their dashboard equivalents, and a sandbox key exercises every tool without sending messages or charging anything.