Letting an AI agent edit your drawings: the guard rails in FloorGen's MCP server

An agent that can draw walls can also delete a floor. When we built FloorGen's MCP server we assumed the model would sometimes misread a request, retry a call that had already worked, or act on a version of the plan that someone has since changed. The answer is not to trust the model more; it is to make every change visible, scoped and reversible. This is what the server does, and how we suggest using it.

Start with the narrowest credential

Every agent connects with either an API key or an OAuth sign-in, and each has one of three access levels:

• Read only: can look at projects, run checks and read schedules. Write tools are not even listed to the agent.
• Read & edit: can change plans and see what you have open in the editor.
• Full: everything above, plus the seven destructive tools: deleting entities, rooms, designs, floors or whole projects, clearing a design, and restoring a checkpoint over the current state.

Keys can also be limited to chosen projects (up to 100) and set to expire after 30, 90 or 365 days. A key limited to projects cannot create new ones, and any project outside its list is refused. An OAuth sign-in always covers all your projects, so when you want an agent confined to one job, give it a key. Keys and connected apps are listed in Agents & MCP with when each was last used; a key can be revoked and an app disconnected there.

Our default advice: give a new agent a read-only key for a week. Let it describe projects, run validate_plan and pull schedules. Raise it to Read & edit when you know how it behaves. Few workflows need Full.

Dry runs

Every edit tool accepts dry_run: true. The server runs the edit in full against the current project, validates the result, and returns the summary, any warnings and the exact ids that would be created, updated and deleted, without saving anything. It is the cheapest way to check that "move the kitchen wall 30 cm east" means the wall you think it does.

Revision checks

Reads return the project's revision, rev. An agent can pass it back on an edit as expected_rev. If the project has moved on since, the server compares what this edit touches with what the later changes touched. If they overlap, the call fails with CONFLICT, lists the overlapping ids and tells the agent to read the project again. If they do not overlap, the edit goes ahead, so two agents working on different floors do not block each other.

Underneath, every save is compare-and-swap: if the stored project changed between loading and saving, the server retries once on the fresh copy and then gives up with a conflict rather than overwriting. Every result is also re-checked against the project schema before it is saved; an edit that would leave the plan inconsistent fails with INVARIANT_VIOLATION and nothing is written.

A confirmation step before anything is deleted

The destructive tools never act on the first call. The server does a dry run, and returns CONFIRMATION_REQUIRED with a plain description of the impact, such as "This deletes 3 walls and 2 doors and windows.", and a one-time token. The agent is told to ask you. Only a second call with that token goes through. The one exception is soft_delete, the everyday delete for walls, furniture and the like: it moves things into a per-design trash that restore_trash empties back out, so nothing is lost and it needs no confirmation. empty_trash (the permanent delete), clear_design and deleting rooms, floors, designs or projects still ask.

The token is bound to the same tool, the same arguments, the same project and the same key or sign-in, works once, and expires after five minutes. An agent cannot get a token for deleting one wall and spend it on deleting a floor.

Checkpoints

Before every confirmed destructive call, and before every macro (generate_layout, furnish_room, apply_template and the rest of the macros toolset), the server saves an automatic checkpoint: a full copy of the project as it was. Agents can also save named checkpoints with create_checkpoint before a risky series of edits, and list and restore them later.

Checkpoints are kept for 30 days, up to 20 per project, with older automatic ones removed first. Restoring one is itself destructive, so it asks for confirmation and checkpoints the current state first. Deleting a project keeps a copy too: restore_project brings it back within 30 days.

The transaction log

Every change an agent makes is logged as a transaction: who made it (the key's name or the connected app), which tool, a one-line summary, the ids it touched and the full diff. The log is kept for 90 days. Agents can read it with get_history, see field-by-field changes with diff, take back their own recent changes with undo and redo, and take back anyone's change with undo and its tx argument.

Undo and revert are careful about later work. Each refuses with CONFLICT, naming what changed, if a later change touched the same things, so taking back an old edit never silently destroys a newer one. Reverts are logged as changes of their own. One limit to know: edits you make by hand in the editor are not in this log.

Edit calls can also carry an idempotency_key. If a client times out and resends the same call within 24 hours, the server returns the stored result instead of applying the change twice.

What you see in the editor

If you have the project open while an agent works, its edits arrive in the editor as they are saved. Each one becomes a single step in your undo history, labelled with the agent's name and its summary, so Undo takes back the last agent edit exactly as it would your own.

The Activity panel lists every agent edit on the project, newest first, together with notes agents leave, and a badge counts the ones you have not looked at yet. Each row has Show, which selects and frames the things the edit touched, and Revert, which takes that edit back out of the open project as one undoable step. If something has since changed the same things, Revert tells you so instead of guessing.

Rate limits

Each key or OAuth grant is limited to 300 tool calls a minute, and 60 edits a minute within that. A call over the limit returns RATE_LIMITED with a hint to slow down or batch the changes with apply_ops. The limits are generous for real work and stop a looping agent from rewriting a project hundreds of times before anyone notices.

A working routine

1. Give the agent a key with the lowest access that does the job, limited to the projects in play, with an expiry.
2. Ask it to save a named checkpoint before any edit that touches more than one room.
3. For anything structural, ask for a dry run first and read the ids it would change.
4. Keep the project open while it works, and read the Activity panel afterwards. Revert anything you did not ask for.
5. Run validate_plan at the end, and look at the Issues list yourself before the drawing leaves the office.

For example prompts, see can ChatGPT or Claude draw a floor plan; for what to check in any AI-drawn plan, see AI floor plan generators. Setup for each client is in connecting Claude, ChatGPT and Cursor. More on how FloorGen handles accounts and data is on the security page; questions go to contact.