Let a coding agent ship your app update

The problem: agents can write the fix, but shouldn't ship it unsupervised

A coding agent can often produce the screen change you need faster than a human can type it. Getting it into production safely is the harder part: someone still has to validate, sign, publish, and watch the rollout, and a mistake at that stage reaches real users.

The workflow in four steps

1. Build the MCP server and add it to your agent's client. This step happens once per machine; after it's registered, the agent can list and call the delivery tools like any other MCP server.

cd /absolute/path/to/pororoca-ota/mcp
npm ci
npm run check
npm run build

codex mcp add pororoca \
  --env POROROCA_API_URL=https://pororoca-ota.fly.dev \
  --env POROROCA_API_TOKEN=pororoca_live_... \
  -- node /absolute/path/to/pororoca-ota/mcp/dist/index.js

2. Have the agent read channel status first — a read-only tool that reports health and adoption before anything changes, so both you and the agent are reasoning from the same baseline before a mutation is even proposed.

3. Validate and sign the bundle yourself, outside the agent's reach — the MCP server never receives your private signing key, only already-signed bundles — then have the agent publish the signed bundle and set the rollout percentage, with your explicit approval for the app, channel, update ID, and percentage before it runs. Publishing at 10% first keeps the agent's blast radius small if it gets a parameter wrong.

4. If a regression shows up, have the agent roll the channel back to the previous known-good update, then re-inspect status to confirm the rollback landed and the channel now points at the prior update ID rather than the one that regressed.

Rollout is deterministic by install ID, and `applied` telemetry in the dashboard tells you and the agent whether the update actually reached and rendered on devices, not just whether the publish call succeeded — a useful distinction for an agent, since a 200 from the publish endpoint only confirms the manifest was accepted, not that any device has adopted it yet.

Limits and the trial

The MCP server runs locally today — a hosted MCP transport is not yet available, so the agent's client needs to be able to spawn a local stdio process. Also not yet available: team members and RBAC, usage-based limits, automated alerts, and cross-platform expression parity between iOS and Android.

On Android, storage is host-managed and the renderer surface is smaller than SwiftUI's, without full modifier parity yet, which is worth telling an agent explicitly if it's asked to produce a screen meant to work identically on both platforms. There's one Pro plan, card-required 21-day trial, billed in BRL or USD.