Key Takeaways
- create_webhook via MCP should wrap the same POST /webhooks REST flow — not invent a parallel callback bus.
- Agents that can register URLs can redirect delivery and inbound events; treat the tool as privileged.
- Verify X-SmsGateway-Signature (or the live header name in OpenAPI) on every receiver before trusting payloads.
- Webhooks report radio reality (delivered/failed/received). MCP success ≠ carrier delivery.
- You still bring Android + operator credit. Pricing remains devices plus send volume.
Search intent create webhook via mcp usually means: “can my agent register delivery callbacks?” Yes — if your MCP server wraps the documented webhook API. Concepts: create webhook via MCP concepts. Product guide: webhooks. Spec: SMS API documentation.
You need a working Android phone with a SIM and SMS credit from your mobile operator. Operator message costs are yours—we do not sell carrier SMS balance. Service pricing is based on device count and total SMS sent through the gateway.
Why register via MCP
Agents that spin up staging environments may need a temporary callback URL. That is useful in labs and risky in production: a wrong URL leaks inbound SMS and DLR. Prefer human-reviewed registration for prod, or a tool that only allows an allowlisted host suffix.
create_webhook is privileged write access to your event pipe. Wrap REST; require confirm; verify signatures on the receiver — not in the chat transcript.
Tool → webhook API
| Agent action | REST wrapping target | Guardrail |
|---|---|---|
| Register URL + events | POST /webhooks (confirm in OpenAPI) | Allowlist domains; staging key only on laptops |
| List / delete hooks | Documented list/delete routes | Audit every mutation |
| Receive events | Your server, not MCP | HMAC verify before parse |
| Map message.failed | Same payload as any REST client | Do not invent status enums |
Setup steps
- Stand up an HTTPS receiver that logs raw headers (no OTP bodies in shared Slack).
- Confirm live create fields in Developer Center.
- Implement create_webhook in the MCP server: URL, event types, secret handling per OpenAPI.
- Call the tool once from the host; confirm the dashboard shows the same webhook.
- Send a staff SMS and wait for delivered/failed — or use the panel test if available.
Verify signatures
Reject unsigned or mismatched bodies. Signature verification is application code on your receiver, not an MCP “trust me” flag. Auth for the create tool itself stays Bearer-in-env: MCP auth setup.
Ops checks
After OEM updates or URL changes, re-register and re-test. Inbound STOP still lands on the SIM — wire message.received to your opt-out store. Feature context: auto-reply and STOP, delivery reports.
Next steps
Pair error handling next: MCP error handling for failed SMS. Keep titles honest — no Unlimited SMS framing for webhook tutorials.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- SMS webhook integrationInbound and status events
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
- device setup guidePair and go live
