Provisioning MCP: The platform launch layer

Provisioning MCP is the layer that helps platforms launch brands across channels and markets.

Our previous article showed how MCP reduces integration overhead. This one shows what that looks like in practice for provisioning.

We started with sender registration, number setup, and RCS sender registration because those are the most common requests platforms deal with. That made it a useful test: does this actually reduce the complexity around registration, or just move it somewhere else?

Next, we are adding more countries for the resource types we already support, more resource types like short codes and WhatsApp senders, and multi-tenant setup (CPaaS X) for platforms. The order will keep shifting as we learn more from platforms using it today.

For platform teams, setup friction is a real problem. And it gets worse with fragmentation. A platform onboarding a handful of customers a month can absorb some friction. A platform onboarding hundreds feels every delay multiplied across channel, country, use case, and number of customers.

One missing input, one rejected request, one manual fix repeated across every launch and growth step. That is the same fragmentation pattern we described in the compliance tax article. Once brands start expanding into new markets and channels, that complexity multiplies again.

The real problem is not filling out a form. It is making launch setup repeatable when country, channel, and use case keep changing the rules.

Why launch setup slows platforms down

The earlier MCP article covered the broad pattern: operational work drains engineering capacity when teams have to build the glue around integrations themselves.

A platform team usually knows the end goal.

They want to launch a customer brand in a specific market. What slows them down is the setup path between intent and live traffic.

That path changes depending on the combination of country, channel, and use case. A request that is straightforward in one market might need a different approval path, a different resource type, or a different sequence in another.

That is where manual provisioning starts to hurt. But the comparison is not just manual versus API.

Platforms often already have an API. The real gap is what sits in front of it: knowing what to send before you send it and knowing how to adjust when requirements change.

There are two separate problems here.

1. You need to know what a given launch or expansion actually requires: which resource type, which fields, which approval path, for this country and this channel.
2. Once you know that, you need to execute it: submit the request, track it, handle what comes back, and adapt when the process changes.

A raw API flow assumes the platform already solved the first problem. Most have not. That is where manual runbooks, rigid hardcoded API flows, and tribal knowledge creep back in even when an API exists.

If the volume is low, that is fine. If the platform is serving more customers, or helping existing customers expand into more markets, those one-off steps turn into a queue. People start chasing missing inputs. Support gets pulled in. Launches slip. Growth slows.

And when launches slip, customers notice.

What Provisioning MCP changes

The earlier article argued for MCP as a way to consume operational capabilities instead of rebuilding them. Provisioning MCP is one of those capabilities.

It gives platform teams a structured way to discover what a launch needs and then act on it: submit the request, track its status, and handle what comes back.

That matters because the platform has to know what applies where, by country, channel, and use case, before it can do the work. A sender registration flow in one market might be a number purchase in another. A flow that is valid for one channel may need a different approval path or a different set of inputs somewhere else. The product turns that lookup into a repeatable step instead of a manual one.

This is not just a form. It is not just an API endpoint. It is a launch layer that can hold the rules for a given country, channel, and use case so the platform team does not have to rebuild that logic every time.

That matters because the hard part is not entering data. It is knowing what to ask for, in what order, and what to do when the request comes back incomplete or rejected.

A bad request creates drag in more than one place. Someone has to explain what is missing, the request has to be corrected, and the team has to keep track of what has changed. If that happens often, the launch process stops feeling like a product capability and starts feeling like a support queue.

Where does that logic actually live?

In the dynamic workflow layer behind Provisioning MCP, where country, channel, and use-case rules can change as markets change. The important point is that platform teams should not have to encode that complexity in their own product code.

Provisioning MCP gives them a single interface on top. The platform sends one request, and the workflow resolves the current path, validates the inputs, and returns the result. When regulations, carrier rules, or market requirements change, that logic updates centrally instead of forcing every platform to ship a code update.

Today, the product covers:

• 10DLC brand registration and campaign registration in the U.S.
• SMS alphanumeric sender registration in supported markets
• RCS sender registration in supported markets
• Buying a number resource from stock in supported markets

For us, the real choice was simple: keep asking platforms to either enter requests manually or build their own resource request flow on top of our API or give them a launch layer that sits on top of both the resource request model and the portal, and handles the country, channel, and use-case logic once.

Where it fits in the platform stack

Provisioning MCP fits in different places depending on how the platform works. That flexibility matters because not every platform wants to expose the same level of setup to the customer. Some want full self-service. Some want an internal ops flow. Some want a mix of both.

As a customer launch layer

Some platforms want their customers to self-serve setup as part of onboarding.

In that case, Provisioning MCP gives the platform a structured way to guide the launch without making the user figure out every rule themselves. The platform still owns the experience. The product handles the provisioning logic.

That is useful when onboarding has to move quickly but the underlying requirements still depend on country, channel, or use case. Instead of hardcoding that logic into every new flow, the platform can centralize it in one place and keep the customer experience simpler.

As a back-office provisioning layer

Other teams want to keep launch setup internal. Ops or support can use the same layer to make the process more consistent. The team still handles the request, but the steps are standardied and easier to repeat.

This is the version that matters when the work is still too irregular or too sensitive to expose directly to customers. It is also the version that tends to save the most time first, because the team is already doing the work manually and just needs a more reliable way to run it.

As a requirements discovery layer

Sometimes the first value is clarity.

Before anything is submitted, the platform needs to know what the market requires. That may mean a different sender type, a number purchase, or a different registration path depending on the channel and geography.

Provisioning MCP surfaces that early, which is better than discovering the missing piece halfway through a launch.

It also helps when the platform is launching across multiple countries at once. The team can see the differences before they submit the request, instead of learning them one market at a time and reworking the flow after each rejection.

Three examples show how much the path can change:

• A campaign registration in the U.S. needs a brand registered and a campaign registered against it before any message can send, plus ongoing carrier compliance checks.
• An RCS sender registration in Germany or Brazil follows a different approval flow, with its own set of required inputs and a different carrier review process.
• An SMS sender registration in the UK can start as a simple sender registration today, then shift to a different requirement tomorrow where documents are needed.

Provisioning MCP checks which of these paths applies, collects only the inputs that path needs, submits the request, and tracks what happens next.

If a request is rejected, the platform can surface the correction and continue without rebuilding the whole flow.

The platform does not need someone to remember the sequence by hand. The launch path stays repeatable, even when the country or channel changes.

One more difference from a raw API: requirements change. Carriers update rules, new countries get added, approval paths shift. With direct API integration, the platform has to track those changes itself and update its own logic. Provisioning MCP keeps that logic on our side, so when something changes, it is available to every platform using the layer without them shipping a code change.

Current scope

Provisioning MCP is in early access.

Here is the product vision, what is live today, and what comes next.

The vision is a single launch layer that covers every resource a platform needs to go live: sender types, numbers, brands, and campaigns, across every channel and market we support, plus multi-tenant launch flows for platforms with more complex customer structures.

Today, the product covers:

• SMS alphanumeric sender registration in the EMEA and Australia
• 10DLC brand registration and campaign registration in the U.S.
• RCS sender registration in all available markets
• Buying a number resource from stock in all supported markets

What does not show up in a static list like this is coverage change. New countries and resource types get added as carrier requirements evolve, and those changes are available to every platform on the layer as soon as we ship them. No code change required on the platform side. That is different from a direct API integration, where the platform has to track carrier and country changes itself and update its own logic each time.

Next steps are broader CPaaS resource provisioning (like WhatsApp senders) and multi-tenant launch flows. Sender registration and number setup are the wedge. Platform launch orchestration is the direction.

When this fits, and when it doesn’t

The same decision logic from the previous article applies here. If operational work is occasional and simple, a manual runbook can be enough. If it becomes part of the product, the workflow belongs in MCP.

Provisioning MCP makes sense when provisioning is part of the product, not just a support task.

It fits when:

• a platform launches many brands
• those brands keep growing into more use cases, channels, and geographies, and each expansion multiplies provisioning complexity
• setup needs to repeat across countries or channels
• self-service matters
• the team wants to stop rebuilding the same launch logic in every product flow
• launch delays are starting to hurt conversion or customer activation

If you only handle a few requests a month, a manual runbook is usually faster. In that case, the right move is to keep the process simple and document it well.

That is the tradeoff. Not every launch path needs to be productized.

The bottom line

Provisioning MCP helps platforms turn launch setup into a repeatable capability.

Today, that starts with sender registration and number setup. Tomorrow, the same layer can expand into broader CPaaS resources and multi-tenant launch flows for platforms, agencies, and SaaS products.

If provisioning is slowing down your launches, this is the layer that removes a lot of the friction.

It gives platform teams a way to handle the country, channel, and use case logic once, then reuse it across launches.

That is the real value.