TL;DR — The agent working on your CodeMonster app never sees raw solution, form, workflow, grid or screenflow JSON. Reads return compact structural maps: labels, ids, relationships. Writes are named for the change they express — add-field-to-form, wire-field-to-dimension, set-object-permissions — and each one runs inside a transaction whose preview is a list of entities, not a patch. There is exactly one carve-out, get-field-detail / update-field, and it is a stripped view of one field. This is not a constraint we apologize for. It is the shape of the only door the agent can use.
Two ways to let an agent touch a backend
The first way is to hand the agent the document. Give it the app definition as JSON, let it edit the JSON, save the JSON. It is the fastest thing to build and the hardest thing to govern, because the agent can now express any change the format allows — including the ones nobody has a name for.
The second way is to hand the agent operations. It reads what it needs through a small number of read tools, and it changes things through write tools that each do one nameable thing. The platform validates every write against what a solution is allowed to be.
CodeMonster does the second. The MCP server exposes approximately 100 named operations, and none of them accept a raw solution document. That single fact does more governance work than any review step bolted on afterwards.
What a read returns
Ask for a solution and you get get-solution-map: the objects, forms, workflows and screens in it, with labels, ids and how they relate. Ask about a form and get-form-summary returns its fields and their types. get-object-map and get-screenflow-map do the same for data and navigation.
What you do not get is the underlying document. The renderer’s JSON, the workflow definition, the grid configuration — none of it enters the agent’s context. Two consequences follow. The agent’s context stays small enough to reason in, and the agent cannot learn the storage format well enough to freelance in it.
What a write looks like
Every write is a verb with a noun. create-object makes a real table. add-dimension runs a real ALTER TABLE. add-field-to-form puts a field on a form; wire-field-to-dimension connects that field to a column. update-drawer edits the left navigation. set-object-permissions decides which groups may see and change what. setup-object-crud creates a form, three relations and three screenflow actions in one call.
The names are the contract. When the agent says what it wants to do, the platform knows what that change is allowed to touch, and it validates the request against that — not against whatever the agent managed to write into a document.
The carve-out, stated plainly
There is one place where something closer to a field’s raw definition crosses the line: get-field-detail returns a stripped view of a single field, and update-field accepts one. That is the whole exception, and it exists because some field configuration is genuinely per-field and needs to be edited as such.
So the accurate claim is not “the agent never sees any JSON.” It is: the agent never sees raw solution, form, workflow, grid or screenflow JSON, and the single-field carve-out is bounded to one field at a time. We would rather say the precise thing than the impressive one; the precise thing is what survives a security review.
Transactions: the preview is a diff of entities, not a patch
Writes do not land one at a time. begin-solution-edit opens a working copy of a solution. Staged operations accumulate against it, and nothing touches the stored solution yet. preview-solution-edit returns a human-readable, entity-level diff — “field added to form X, wired to column Y” — that a reviewer can read without knowing the storage format. diff-against-stored is a three-way drift check before commit, so an edit that started an hour ago cannot silently overwrite what a colleague saved since. Then commit-solution-edit lands everything as one save, or rollback-solution-edit discards it all.
The guardrails around that loop are deliberately unglamorous. One transaction can be open per solution. While one is open, out-of-band writes are blocked. Sixty seconds of inactivity rolls an abandoned transaction back, so nothing half-done waits around to be committed by accident. Staged edits are held by the server for the length of the transaction; they are not a durable draft, and we do not describe them as one.
The platform teaches the agent
A named-operation surface only works if the agent knows the conventions. get-domain-knowledge is the in-band manual: server instructions, tool defaults, richer descriptions and post-call hints that teach a brand-new agent the build order, the schema prefix, groups-first permissions, tenant selection and publish-to-land. Your agent reads it before it builds, and it reads it again after a call returns. Every hint is a place the platform speaks up rather than waiting to be asked.
Why this is governance, not a limitation
Put the pieces together and the contract stops looking like a set of restrictions and starts looking like a control surface.
Every request is authenticated: a bearer token is validated against the platform on every call, and a rejected request gets a 401 with no tool list, no schema and no server information. The token is forwarded on every platform call, and the platform performs authorization — the MCP server never decides who can do what, so the agent acts with your permissions, never its own. A per-solution allowMcpEdits flag turns every AI write into a 403 during a human-only freeze window. Every tool invocation is recorded, and agents can file feedback with their recent calls attached, into a queue a human reviews.
None of that would matter much if the agent could also hand the backend an arbitrary document. It cannot. The named operations are what make the authentication, the permissions and the freeze flag mean something.
An edit, logged
Here is what a small change looks like on the wire, using the operation names as they exist:
Nine calls, three entities changed, one save. Nothing in that log is a document; every line is a decision with a name, and every line was authenticated and recorded.
The full list of operations, grouped by what they touch, is on the control surface page. What stops a bad edit and what records it — permissions, roles, logs — is in governance and audit.