Changing data safely

This is the part users most need to understand, and the part that prevents support tickets.

Every write is a preview first#

create, update, and delete return a dry run by default. Nothing is written. The response shows what would change. The assistant then has to call again with confirm: true to commit it.

In practice the conversation looks like this:

User: Close ticket 4821 and set the resolution to “replaced SFP”.

Assistant: (shows the exact before and after diff) Confirm?

User: Yes.

Assistant: (commits, returns the updated record)

Fields that cannot be set#

Some columns are refused by design, with an explanatory message rather than a silent failure.

Unknown field names are rejected outright rather than ignored, so a typo fails loudly instead of quietly dropping a value.

Retries are safe#

Writes carry an idempotency key. If a request is retried after a network blip or a client restart, the original result is returned rather than the change happening twice.

Idempotency is best-effort rather than absolute: two genuinely simultaneous retries of the same request could both execute. In practice that needs a pathological client.

Deletes#

Where the record type supports it, delete is a soft delete. The row is hidden, not destroyed, and can be restored. Nothing is deleted without an explicit confirmation after a preview.

Bandwidth change orders#

Circuit bandwidth is controlled by the carrier, so it gets its own tool rather than a field edit.

1. Preview. “What would it cost to take the Dallas circuit to 1 Gbps?” returns the price delta, computed from that circuit’s cached rate card. Nothing is ordered.
2. Confirm. The order goes through exactly the same pipeline as the app’s own bandwidth change: the same capability checks, port-capacity limits, pricing floor, concurrency lock, and 24-hour carrier rate limit all apply.
3. A change ID comes back, tracking order acceptance.

If a guardrail rejects the change, nothing is recorded and the reason is returned. A rejected change is not a partial change.

Pricing can optionally be run against a specific contract term, for example 36mo. Otherwise the circuit’s current term is used.

The audit trail#

Every confirmed change is written to an append-only MCP write log, alongside the normal application audit trail. “Who changed this?” is always answerable, and an MCP-originated change is distinguishable from one made in the web app. See Your audit feed.

Common questions#

Can an assistant delete a client’s data permanently? Where a record type supports soft delete, no. The row is hidden and recoverable. And nothing is deleted at all without an explicit confirmation after a preview.

Can it act while nobody is watching? Only if a client is left connected and something drives it. Revoking under Connected Applications ends that immediately. See Governing connected assistants.