Safety and undo

Writes happen as you

A write from an MCP client is applied at once, with your permissions, exactly as if you had made the call yourself. It is not held for approval: asking first is your client’s job, and most clients ask before running a tool marked destructive. An agent can never do more than you can, because it has no identity of its own to borrow.

Everything lands in the history

Every write, from any surface, is recorded with who made it, when, and how it arrived: the grid, a key, or an agent. A create, edit or delete of records can be undone from the change history, in the app or through the API (changesets.mine, then changesets.undo). One request is one entry, so an agent’s import of five hundred rows is one thing to take back. See Undo and history.

Deleting a table, a field, an app or a suite asks for its current name as confirm, from an agent as from a person, so a loop over the wrong list is refused rather than obeyed.

gtable’s own assistant proposes

The assistant built into gtable works differently: it proposes a change, shows you what it would do, and you apply it. Its proposals are recorded the same way, and an applied one is undone the same way.

Give an agent no more than it needs

• Connect it to the suite, and tick only the apps it should reach.
• For a production integration, prefer a single app’s address (/{app}/mcp) or a key with only the scopes it uses.
• Revoke a connection from the same Connections screen; it stops at once.

Setting up changes nothing

The setup guide tells an agent to verify its connection by reading only (apps_list, then me_get), and never to create, update or delete anything to test it.