WhatsApp Business MCP is dev-only: keep Sume generation server-side

If you build a WhatsApp flow that sends AI-generated video, put the Sume job on your own server and let the WhatsApp Business tools MCP touch only development and test traffic. The announcement summarised in the Orthotropy October 2026 platform roundup (read 2026-10-06) dates the WhatsApp Business tools MCP to 2026-09-15 and describes it as for development and testing only. A flow that depends on it in production depends on something its own announcement says not to use that way.

The practical split is simple. Generation is an asynchronous Sume job that you submit, poll or receive by webhook, and fetch from. Delivery is a separate step. Keep them apart, and the delivery step becomes the only place where the environment decides which transport runs.

Why does generation belong on your server?

Sume's job model is already server-shaped. You submit, get a job id and URLs, then wait for a terminal state, as described in Sume jobs and results. A webhook delivery is signed and retried, per Sume webhooks, which only works against a receiver you run. Nothing about that flow needs an agent or an MCP client to be in the path when real customers are on the other end, so there is no reason to let a test-grade tool become a production dependency.

How do I gate the transport?

Make the choice in one function that reads configuration and refuses to guess. In the sketch below the MCP transport is allowed only when the environment name is development or test. Anything else, including a typo or an unset variable, raises, so a missing setting stops the send instead of silently picking the test tool.

ALLOWED_MCP = {"development", "test"}

def pick_transport(env):
    name = (env or "").strip().lower()
    if not name:
        raise ValueError("APP_ENV is empty; refusing to choose a WhatsApp transport")
    if name in ALLOWED_MCP:
        return "whatsapp_business_mcp"
    if name in {"staging", "production"}:
        return "own_server_sender"
    raise ValueError("unknown APP_ENV: " + name)

assert pick_transport("test") == "whatsapp_business_mcp"
assert pick_transport("Production") == "own_server_sender"
for bad in ("", None, "prod-ish"):
    try:
        pick_transport(bad)
    except ValueError:
        pass
    else:
        raise SystemExit("gate let through " + repr(bad))
print("gate ok")

What else should be identical across environments?

Keep the same Idempotency-Key discipline in both paths. A generated clip that is submitted twice is billed twice, and a message that is sent twice is delivered twice, so derive the key from the conversation and the template or intent, not from a timestamp. Store the Sume job id and the delivery attempt together, then a retry after a crash can look up what already happened.

Two limits to check in your own pipeline: the finished artifact has to meet WhatsApp's media rules, and the delivery tool has to be able to fetch the file. Rather than repeat those numbers here, the stored posts linked below cover the video size ceiling and the media ID lifetime; read the current WhatsApp documentation before relying on any figure. If the WhatsApp announcement later changes status, only ALLOWED_MCP and the table row need to change. Until then, treat the MCP as a way to rehearse conversations against a test number, check that your templates render, and let a coding agent poke at the flow while you build it. Do not treat it as a delivery pipeline. When a customer message is on the line, a send that fails should land in your own retry queue with the Sume job id attached, and the generated clip should stay in your storage until delivery is confirmed, so a failed send never forces you to pay for the same video twice.