Can an MCP server subscribe to WhatsApp events?

Not in the sense people mean. MCP has no mechanism that makes WhatsApp push events to an AI host. Your webhook receiver takes the event, and your application decides whether to start an agent run.

Do I need to keep my webhook endpoint after adding MCP?

Yes. Without it you receive no inbound messages and no delivery status. Removing the webhook endpoint would leave the agent unable to know anything happened.

Should the agent's send go through the same code as my existing automation?

Ideally yes, through a shared internal service. Two implementations of sending will diverge, and the divergence surfaces as inconsistent behaviour depending on which path handled the message.

How do I stop an agent duplicating a ticket after a retry?

Idempotency keys on the operation. The tool accepts a key, the service recognises a repeat, and the second call returns the original result instead of creating a new record.

What is a sensible first use case to move?

A read-heavy one. Let the agent look up orders or customer records before it sends anything, so you learn how it behaves while the blast radius is still zero.

Migrating a WhatsApp Webhook Integration to MCP

The honest answer is that you should not migrate off webhooks, because MCP cannot do what they do. Webhooks carry events that WhatsApp pushes to you, and MCP carries actions an AI application asks for. Those are opposite directions, and a working agent setup needs both.

Teams that miss this build an agent, wire it to an MCP server, and then discover nothing happens when a customer messages them. The agent has no way to find out. Something still has to receive the inbound event and decide to involve the agent.

Why This is Not a Replacement

Take a concrete sequence. A customer sends "where is my order?" at 11 pm.

WhatsApp delivers that to your webhook endpoint. Nothing in MCP would have told you it happened: there is no subscription in the protocol that makes WhatsApp push to an AI host. Your receiver acknowledges quickly, persists or enqueues the event, and only then can anything else happen.

Now the agent becomes useful. Your application decides this event deserves reasoning, starts an agent run, and the agent calls lookup_order and then send_message through the MCP server. Those tool calls are requests for action that the model chose to make.

When that outbound message is delivered or fails, the notification comes back through the webhook again, because delivery status is another provider-initiated event.

So the two layers interleave. Meta's WhatsApp Business Platform documentation describes webhooks as the mechanism for message and status events, and the MCP specification describes tools as operations a host invokes. Neither substitutes for the other.

Concern	Webhook layer	MCP layer
Direction	WhatsApp to you	AI host to your services
Trigger	A real-world event	A model decision
Guarantees you need	Fast acknowledgement, signature validation, deduplication, retries, dead-letter handling	Input schemas, authorization, tenant isolation, audit logging, idempotency
Fails badly when	Events are dropped or processed twice	A tool is over-scoped or an action repeats
Should own	Deterministic automations	Judgement-dependent actions

The Architecture That Works

Two paths, one set of shared services underneath:

The inbound path runs WhatsApp to your webhook receiver, into a queue, out to workers, and finally into shared business services. The agent path runs from the AI host to your MCP server, and into those same shared business services.

The important line is the third one. Order lookup, CRM updates, ticket creation and message sending should live in ordinary internal services that both paths call. If your webhook workers hold their own copy of the sending logic and the MCP server holds another, the two will drift, and the drift will show up as inconsistent customer experience depending on which path handled the interaction.

Expose the business operations as tools. Do not expose the webhook handler as a tool, which is a surprisingly common instinct and produces a tool that does nothing useful for a model.

A Migration Sequence That Does Not Break Production

Inventory what you have. Every webhook event you subscribe to, every automation triggered by it, retry rules, deduplication keys, signature checks, outbound API calls and correlation ids. Separate event handling from business logic on paper before you touch code.
Stabilise the webhook path first. Keep the endpoint, verify authenticity, acknowledge fast, persist or enqueue, and make workers idempotent. Resist any design where the MCP server receives WhatsApp push events.
Extract shared services. Pull the business operations out of the webhook workers into internal services with clear interfaces. This is the step that makes everything after it cheap.
Add the MCP server as a facade. Narrow, typed tools with explicit input schemas, authorization, tenant isolation, rate limits and audit logging. Start read-only. Add actions once reads are trusted.
Run the agent in shadow mode. Let it propose actions or draft replies without executing sends, refunds or cancellations. Compare its proposals against what your existing workflow did.
Migrate one bounded use case. For instance, keep the webhook-triggered support workflow and let the agent call lookup_order and create_ticket only. Measure tool errors, latency, duplicate actions, human overrides and customer outcomes.
Add controlled handoffs. A webhook worker can start an agent run when an event needs reasoning. That is still your application invoking the agent, which is the correct shape. It is not MCP acting as an event bus.
Roll out behind flags with a rollback. Route per tenant or per conversation, and keep the deterministic automation as the fallback until the agent path has earned trust.

Step 5 is the one under the most pressure to skip, and it is the one that catches schema problems and over-eager tool selection before a customer sees them. Watching which tool the model reaches for, and with what arguments, is exactly what shadow mode makes safe to observe.

Keeping the Webhook Automations Alive

While you add the agent layer, the webhook path has to keep its existing guarantees. Preserve fast acknowledgement, signature validation, event deduplication, retries, dead-letter handling and observability. Keep triggering deterministic automations straight from events. Do not replace any of it with polling, and do not expect MCP to deliver inbound messages.

Correlation is the piece that connects the two worlds. When an agent sends a message through a tool, capture the provider message id it returns, and store it against the agent action. The delivery, read or failure webhook that arrives later carries that same id, which is what lets you answer "did the agent's message actually reach the customer?" without guessing.

Idempotency deserves the same attention on both sides. Webhook workers must tolerate the same event arriving twice. Agent actions must tolerate the same tool call being repeated, because a retried call must not create a second ticket or send a second message.

Where Wati Sits in This

Wati already runs the webhook side for accounts on the platform, which changes the migration shape for teams building on it. Inbound messages and delivery status flow into the platform, and the automation surface acts on them, so the work becomes adding an agent action layer rather than building event handling from scratch.

Wati's MCP server is that action layer: named tools that mirror the agent lifecycle, per-account authorization instead of a shared secret, and scoping narrow enough that a connected assistant reaches only what it was granted. For a fuller picture of what that server exposes, see what a WhatsApp MCP server is, and for the controls the action layer needs, MCP security for WhatsApp AI agents.

If your existing automations run through an integration rather than raw webhooks, the same principle applies: keep the deterministic path, and add the agent as a controlled caller of shared operations. The HubSpot and WhatsApp integration is a good example of that deterministic path, one that keeps running exactly as-is underneath whatever agent layer gets added on top.

Schedule a free demo to get started with Wati today.