Consider a retailer preparing order updates. The first milestone is a registered number and an approved message template. The second is proving that the application behind the integration handles what comes back. In Meta's getting‑started sequence, developers send a test message, reply to it, configure a test webhook application and inspect the event. The webhook endpoint is also how the integration receives message‑status notifications such as delivered and read. Seeing the message appear on a phone proves a narrower result than seeing its reply and status information arrive where the application expects them.
The message format has a separate condition. A customer's message opens a 24‑hour service window in which the business can send a non‑template reply. Outside that window, the MCP send tool supports an approved template instead of free‑form text. A useful test plan therefore distinguishes an in‑window reply from a template send rather than treating one successful message as evidence for both. The tool reference documents that delivery restriction, while the Cloud API guide demonstrates how a reply creates the window.
These are different records of success: the correct recipient received a message, the application received an incoming event, and the chosen message type was valid for the conversation. An agent can help assemble the configuration, but the developer still needs to examine those results. For the retailer, the test is complete when those records line up with the intended order‑update workflow.