The control surface
Approximately 100 named operations, grouped by what they touch. Every one is authenticated. Every solution edit is staged, previewed, then committed as one save — or rolled back before it lands. Data writes, group changes and publishes land immediately, authorized as you. None of them hand your agent raw solution JSON — with one carve-out, named below.
The agent reads maps and writes by name.
Reads return compact structural maps: labels, ids and relationships for a solution, a form, an object or a screenflow. Writes are named for the change they express — add-field-to-form, update-drawer, set-object-permissions — and the platform validates each one.
The single carve-out is get-field-detail / update-field, which return and accept a stripped view of one field. That is the whole exception. Everything else keeps raw solution, form, workflow, grid and screenflow JSON out of the agent's context.
The upshot for you: an agent cannot paste a raw solution document into your backend, because no operation accepts one.
What the agent can call, grouped by what it touches.
Every family below is authenticated on every request and authorized by the platform with your permissions. Names are the real tool names as shipped. The table lists every family and the operations builders meet most often — not a complete manifest: utility operations are left out and the set moves as features land, which is why we say approximately 100 rather than a number that is wrong a month from now.
| Family | Operations | What it governs |
|---|---|---|
| Solutions | list-solutionsget-solutioncreate-solutionupdate-solutiondelete-solution | The app container. List, read, create, update and delete solutions. |
| Solution maps (reads) | get-solution-mapget-form-summaryget-object-mapget-object-detailget-screenflow-map | Compact structural maps of a solution, form, object or screenflow: labels, ids, relationships. Never the raw JSON. |
| Solution edits (writes) | add-field-to-formconfigure-fieldadd-sectionmove-fieldwire-field-to-dimensionadd-lookup-fieldreplace-fieldremap-fieldattach-form-to-workflowupdate-form-settingsupdate-drawerupdate-screenupdate-screen-componentrename-screendelete-screen | Named changes to forms, fields and screens. Each write says what it does, and each runs inside a transaction. |
| Transactions | begin-solution-editbulk-apply-editspreview-solution-editcommit-solution-editrollback-solution-editdiff-against-stored | Begin, stage in bulk, preview the entity-level diff, check drift against what is stored, then commit as one save or roll back. |
| Objects | create-objectadd-dimensionremove-dimensiondelete-objectcreate-object-viewupdate-object-viewgenerate-object-view-sqlsetup-object-crud | Real Postgres tables and columns. add-dimension runs a real ALTER TABLE; setup-object-crud creates the form, its relations and its actions in one call. |
| Object instances | dispatch-actioncreate-object-instanceupdate-object-instancebulk-insert-instancesbulk-upsert-instancessearch-objectsget-object-instanceget-instance-changelog | Rows. Create, update, bulk insert or upsert, search, read one, and read its change log. |
| Actions & permissions | update-action-permissionscreate-workflowwire-workflow-to-actionset-object-permissions | Workflows wired to actions, and who may trigger what. |
| Grids | create-grid-viewcreate-data-gridupdate-grid-viewdelete-grid-viewquery-gridtest-queryattach-grid-to-viewupdate-grid-view-settingsupdate-grid-permissions | Grid views and data grids: create, update, query, test a query, attach to a view, and set grid permissions. |
| Screens & UI | generate-screenflowupdate-screenupdate-screen-componentupdate-drawerrename-screendelete-screen | Screenflows, screens, screen components and the left drawer. |
| Tenants & auth | list-tenantscreate-tenantuse-tenantwhoamiping | Who the agent is (whoami), which tenant it is acting in (list-tenants, then use-tenant), how a new tenant is created (create-tenant), and whether the server is awake (ping). |
| Groups | list-groupscreate-groupupdate-groupadd-users-to-groupremove-users-from-grouplist-users | Groups and membership: the platform-side permission model. |
| Environment variables | list-environment-variablescreate-environment-variableupdate-environment-variabledelete-environment-variable | Per-environment variables, listed and managed by name; values are applied at build time. We make no encryption-at-rest claim for these bundles — read data and tenancy before you put a secret in one. |
| Deploy environments | list-deploy-environmentspublish-solutionunpublish-solution | List environments and publish or unpublish a solution. Platform publish copies Current to Testing to Production in one shot. |
| Domain knowledge | get-domain-knowledge | The in-band manual: conventions, defaults and result hints an agent reads before it builds. |
| Feedback | report-feedbacklist-feedbackget-feedback-detaillist-qa-queuerecord-qa-review | Agent-filed issues and praise, with recent tool calls attached, reviewed in a human QA queue. A quality and audit loop. |
Some operations appear in two families because they belong to both. Op-log visuals across this site use only these names.
Every solution edit is staged, previewed, then committed or rolled back.
A solution edit is a transaction. Nothing lands until commit; nothing that is not committed survives. Data writes, group changes and publishes are not transactional — they land immediately, authorized as you, and object rows keep a change log (get-instance-changelog).
How a write lands
begin-solution-editopens a working copy for one solution. A second begin on the same solution is refused: one open transaction per solution.- Staged writes —
add-field-to-form,wire-field-to-dimension,update-drawer, or a batch throughbulk-apply-edits— change the working copy only. preview-solution-editreturns a human-readable, entity-level diff. This is the moment to read before you commit.diff-against-storedchecks the working copy against what is stored, so a change made elsewhere since you began does not get silently overwritten.commit-solution-editlands every staged edit as a single save;rollback-solution-editdiscards them all.
Every error, and what it means
These behave the same on every client, so the client guides point here rather than repeat them.
- 401. The token is missing, expired or revoked. The reply carries nothing else: no tool list, no schema, no server info. The token belongs to your signed-in desktop-app session rather than to the machine, so sign in again there and reconnect the client; lifetime, rotation and admin-side revocation controls are being finalized for launch.
- Tenant context required. Data writes fail fast when no tenant is set for the session;
list-tenants, thenuse-tenant, then retry the write. - concurrent_mutation_blocked. While a transaction is open, out-of-band writes to that solution are refused, so two writers cannot clobber each other. Close it with
commit-solution-editorrollback-solution-edit. - 60-second inactivity auto-rollback. An agent that stalls or loses its connection does not leave a half-finished edit hanging; the transaction is rolled back and the stored solution is untouched.
- Not durable until committed. Staged edits live in the transaction, not in storage. Preview, then commit; do not leave work staged.
- 403 on every write to one solution. A per-solution
allowMcpEditsflag turns off every AI write for a human-only freeze window; the flag does not travel between environments. Humans keep editing while it is off.
Limits the prompt cannot change.
Raw solution JSON
Reads return maps. The one carve-out is a stripped single-field view through get-field-detail / update-field. No operation accepts a raw solution, form, workflow, grid or screenflow document.
Anything before authentication
A request without a valid bearer token gets a 401 and nothing else: no tool list, no schema, no server info. The only public endpoint is /health, and it returns {ok:true}.
Permissions it does not have
Your token is forwarded on every platform call and the platform performs authorization. The MCP server never decides who can do what; the agent acts with your permissions, never its own.
Other tenants' rows
Tenant context is explicit per session, and every object query carries a tenant filter injected server-side. There is no auto-select, and a data write without tenant context fails rather than widening its scope.
A frozen solution
When a solution's allowMcpEdits flag is off, every AI write returns 403. Humans keep editing; the agent waits.
Edits that idled out
After 60 seconds of inactivity a transaction is rolled back. The agent starts again from what is stored, and nothing half-done reaches your users.
What this surface does not cover
Custom Vite/React frontends deploy through the portal and the deploy API, not through MCP operations. Custom backend functions are on the roadmap; there are no function operations today. This surface governs platform apps.
For the person who has to say yes: the IT and security brief · The architecture detail
Every operation, its parameters and its result hints are being published on codemonster.dev. Until that reference is live, get-domain-knowledge is the reference: call it from your agent and it returns the platform's conventions, tool defaults and post-call hints in-band. Track the docs status · Set up Claude Code · Any MCP client
Bring us something you want built.
CodeMonster is invite only while we work directly with early adopters. Request an invite and we will meet, scope what you want to build, and get you productive. You bring the AI subscription you already pay for.