Braze's own MCP server can create a segment, which its REST API never could. It still cannot touch a Canvas
Braze now hosts an MCP server at mcp.braze.com/mcp, and it moves two jobs out of the dashboard that were only ever hand-clicked. Segment writes are the headline: create_segment and edit_segment have never existed in Braze's public REST API, which is why every segment you own was clicked into being rather than authored, versioned, or replicated into a second workspace. Campaign lifecycle is the other — create, edit, duplicate, launch, stop, archive, down to message variations and the traffic split. Three skills ship for it. The one doing the most work is the router, because a connected Braze MCP means three surfaces can now do Braze work — Braze's server, Orbit's own tools, the browser — and choosing wrong costs you an hour before the error tells you. Then the gap everyone is about to walk into. Braze's MCP exposes four Canvas tools and all four are reads. No create, no edit, no step or branch mutation. Every Canvas build is still browser-driven, exactly as it was last week, and that correction is written into braze-canvas-creator and braze-canvas-qa as well as the new skills — because "but Braze has an MCP now" is a reasonable thing to assume and it will arrive there first.
What shipped
•New skill — braze-mcp-operations picks the surface before anything executes. It carries the capability map: what the Braze MCP writes (segments, campaigns, catalogs, email templates and Content Blocks, media assets, CDI syncs, Operator jobs), what it only reads, and the four things it has no tools for at all — Canvas writes, user-level PII, preference centres, subscription-group status. It routes rather than executes, and it tells you to enumerate the connected server's tools before promising one. A capability map is a routing aid; a live server is the inventory.
•New skill — braze-segment-builder authors and edits segments programmatically. That is new capability rather than a new wrapper, and the protocol is built around the two ways it goes quietly wrong. It calls get_segment_filters first and composes the definition from what the workspace actually exposes, because a filter written from a remembered attribute name either errors or matches nobody, and the second failure looks like a working segment. Every write is read back with get_segment_details before a word is reported, and a fresh segment's size is treated as still resolving rather than as the audience count.
•New skill — braze-campaign-operations covers create, edit, duplicate, launch, stop and archive, plus message and variation CRUD and the distribution split. Launch, stop, archive and every delete sit behind a confirmation that quotes the campaign, workspace, audience and its live size, channel and schedule back to you — and that confirmation is per-action, never inherited from an "and ship it" earlier in the conversation. The duplication trap is named: a duplicate inherits the original's audience, and across workspaces the segments, templates and Content Blocks it references may not exist there at all.
•Behaviour change — braze-canvas-creator and braze-canvas-qa now record what the MCP did not change. get_canvas_list, get_canvas_details, get_canvas_data_series and get_canvas_data_summary are the whole Canvas surface and every one is a read, with the same blind spots the existing canvas read has: no filters, no segment names. So the MCP adds no Canvas visibility and no way to fix a QA finding without the dashboard. If a user says Braze has an MCP now, the answer is that it added segment and campaign writes, not Canvas ones.
•Setup fix — three prerequisites block the Braze MCP connection and none of them announce themselves. MCP OAuth access has to be enabled under Settings > Admin Settings > OAuth, which a non-admin account cannot do; the user needs the Use MCP Server permission; and the hosted server is incompatible with IP allowlisting, which is a dead end rather than a configuration to iterate on. There is no client ID, secret, API key or callback port — access mirrors the signed-in dashboard user's permissions and revokes the moment they are deactivated. One note if you are on the older locally-hosted braze-mcp-server from PyPI: it is deprecated and frozen, and it is also the only surface with preference-centre, subscription-group, scheduled-broadcast and SDK-auth-key reads, so the move is a trade rather than an upgrade.