Orbit's Braze MCP guidance had never been checked against a live connection, and it was wrong about the thing that decides most segment work
Orbit's three Braze MCP skills shipped on 7 September written from Braze's documentation alone. Connected to the live server for the first time, the documentation was right about four things and silent about the one that stops most builds. get_segment_filters returns a fixed vocabulary of 32 filters and not one of them filters on a custom attribute. Custom events are filterable three ways; custom attributes are not filterable at all — while the same server reads every one of them back through get_custom_attributes. Readable is not filterable, and most real B2B and product-led audiences are defined by exactly the attributes you cannot segment on: plan tier, lifecycle state, feature flags, billing status. Orbit would have started building one and discovered it at step five. The catalog also came back byte-identical across two different workspaces, so it is platform-fixed rather than a reflection of what your data holds — which the skill had described the other way round. A new skill covers BrazeAI Operator, the one surface that reaches what no Braze API exposes, and campaign writes gained the concurrency protocol they need to work at all.
What shipped
•New skill — braze-operator, for the autonomous agent that drives the Braze dashboard in a live browser session. It is the only programmatic path to Canvas construction, because there are no Canvas write tools on any Braze surface and there never have been. The protocol is mostly about the parts an agent gets wrong unprompted: poll get_operator_result at a fixed 15 seconds and never back off, because jobs run 2 to 15 minutes and a widening interval is how a finished job goes unnoticed; job ids are reaped rather than replayed, so a stale one answers "not found" instead of the original result; a cancelled job can never produce a response, so a successful cancel is where you stop; and of the five things cancel_operator_job can tell you, only an expired session is worth retrying. Operator can also launch, edit and delete live objects, so every prompt that could change state is quoted back for a yes first.
•Correction — braze-segment-builder now leads with the ceiling instead of discovering it. Its old first rule warned that custom attributes drift and a stale one might silently match nobody, which reads as though attributes are filterable. They are not. The skill now tests the intent against the ceiling before authoring anything, lists what the 32 filters actually cover — custom events, ecommerce calculated attributes on a 730-day window, identity and device, subscription state, app usage, profile, and composition — and carries the workaround: segment_membership_filter references an existing segment, so an attribute-based segment built by hand once can have MCP-authored segments layered on top of it. That keeps the hand-maintained work to one object per attribute condition rather than one per audience. It also names the trap in edit_segment, which replaces the filter tree outright rather than merging into it.
•Correction — braze-campaign-operations carries the optimistic-concurrency protocol it shipped without. Every draft mutation requires the current etag as if_match, echoed verbatim with its quotes; a 412 STATE_STALE_VERSION means the draft changed underneath you and needs a re-read and a fresh etag, never the same one; a 428 means the parameter was omitted. A 412 usually means a human is editing the same campaign in the dashboard, so the skill reconciles before re-applying rather than overwriting someone's work. create_campaign and launch_campaign both need an idempotency key, and reordering any part of a retry changes its signature — which either fails as reuse or, with a fresh key, creates a second campaign. Alongside those: campaign_type cannot be changed after creation, edit_campaign's schedule is a full replacement rather than a merge, and webhook request_headers inverts the null rule every other field follows.
•Correction — the router's capability map went from four gaps to seven, and gained the two rules that were missing. Scheduled broadcasts, SDK authentication keys and transactional send join Canvas writes, user-level PII, preference centres and subscription groups on the list of what the Braze MCP cannot do. Every workspace-scoped tool requires app_group_id from get_workspaces, and multi-workspace is the normal case rather than the exception. trigger_integration_sync now carries a hard stop: a CDI integration whose data type is Delete Users permanently erases every Braze profile it matches, the tool cannot tell you which kind it is pointed at, and it returns no run identifier — so the integration is confirmed by name before every call. The map also states plainly that a connected-but-unauthenticated server exposes no tools at all, which looks like an empty surface rather than an error.
•Fix — the new skill wins its own doors without taking its neighbours'. Typed into orbit_route_task, "use Braze Operator to build the canvas" resolves to braze-operator at 37 and "cancel the operator job" at 30, while "which Braze tool should I use" stays with the router and "QA my Braze canvas before launch" stays with canvas QA. One pre-existing mis-route surfaced on the way: "launch this Braze campaign via API" had been landing on the routing skill at 20 over campaign operations at 19, because the router advertised a phrase belonging to the skill it routes to. It routes to campaign operations now. Four door sentences are held at rank one in the test suite.