§ Building With MCP

MCP is the interface. The runtime is why it works.

In Frames Studio an application is rows in Azure SQL, compiled at call time. Page code is a row. Python is a row. There is no compile, no repository checkout, no pipeline, and no deploy, so a write is live on the next request. The MCP server is a layer on top of that: any MCP-capable assistant connects and receives 13 tools scoped to one tenant. Plenty of platforms now expose an MCP server. What is unusual here is what sits underneath it — an assistant is not generating a candidate for a build, because there is no build.

The audience for this page is the team that wants internal web applications without staffing a frontend team. The relevant question is not whether an assistant can write code. Every assistant can write code. It is whether the code it writes can run without a pipeline standing between the write and the run.

I

What the MCP Server Is Standing On

An assistant connected to a conventional stack does not finish when it writes correct code. It then has to reproduce a human workflow: place text in the right files, commit, push a branch, wait for a pipeline, read the pipeline’s output, and hope that what ran is what it wrote. Every one of those steps is a separate interface with its own auth, its own latency, and its own failure modes.

In Frames Studio an application is rows in Azure SQL, compiled at call time. There is no build step, no repository checkout, and no deploy. An edit is a row write. Nothing sits between writing a change and running it. The user relaunches the application and the change is live.

That single property is what makes conversational authorship usable rather than a demo. The loop between ‘change this’ and ‘look at it’ is short enough to have an actual conversation inside, so the assistant can be corrected while the work is still in view instead of after a pipeline reports back.

Four properties of the runtime do the work on this page. None of them are properties of MCP. They were in place before the MCP server existed, and they are the whole reason the tools below are short.

No compilation

Nothing is transpiled, bundled, or built. There is no artifact to produce, so there is no state in which the assistant’s work is written but not yet running.

Code is rows

Page code, Python, schema, and desktop shortcuts are all records. One interface reads and writes all of them, and every save is an insert rather than an overwrite, so history is a property of the store.

Execution is dynamic

A request resolves the code it needs at call time and dispatches it. The change an assistant just wrote is what the next call runs. Relaunch the application and it is there.

Deployless

Nothing in the path between writing a change and running it is a repository operation, a pipeline run, or a deploy. The assistant does not have to drive five more interfaces correctly after it has already written correct code. How the runtime works.

-- an edit is a row write, not a pipeline run
INSERT INTO dev_db.frames -- new version row
SELECT ... -- the edited source
-- relaunch the app; the change is live

The second property matters as much as the first. Every write, from any path, goes through a single validated entry point. AI-authored code is not admitted through a side door with lighter checks. It is subject to the same validation as code a developer typed, which is what allows an organization to let an assistant write at all.

“The reason conversational authorship works here is not that the model is better. It is that there is no pipeline between the write and the run, and no second entry point with weaker checks.”

One realistic build, start to finish.

Four stages. An assistant is connected to one tenant, and someone on the team wants a small internal application that does not exist yet.

Stage 01

Describe the application.

What happens

The request is made in plain language, in the assistant’s own interface. Before authoring anything, the assistant uses the discovery tools: it lists the frames already in the tenant, checks whether the name it intends to use is taken, and confirms the service is healthy. If something similar already exists, it reads that frame’s source instead of writing a second copy.

What the reader should notice

The assistant is not guessing at the state of the tenant from a stale description pasted into a prompt. It reads the current state through the same connection it will write through.

Stage 02

It exists.

What happens

The authoring tools generate a working application from the description. If the team wants to read the output before anything is committed, the assistant can preview the generated code without saving it. If a developer would rather write the code themselves, the same path saves hand-written code. Where the application needs storage, the schema tools resolve and apply the table DDL.

What the reader should notice

There is no scaffolding step, no repository to initialize, and no first deploy to configure. Saving is the row write, and the row write is what the runtime reads on the next call.

Stage 03

Refine it by conversation.

What happens

The first version is close but wrong in the ways first versions are wrong. The editing tools apply a targeted find and replace to one function rather than resending the whole file. Every edit runs as a dry run first and returns the exact byte delta before anything is written, so the change can be inspected and approved before it lands. Once written, the user relaunches the application and the change is live.

What the reader should notice

Function-scoped edits keep the assistant from rewriting working code it was not asked to touch, and the dry run makes the size of a change visible before the change exists. Review happens on the delta, not on a diff of a file the assistant regenerated from memory.

Stage 04

Put it on the desktop.

What happens

The desktop tools list what is currently on the user’s browser desktop and place a shortcut to the new application there. They also remove shortcuts, so the desktop can be cleaned up in the same conversation that filled it.

What the reader should notice

This is the step that usually falls outside the assistant’s reach. Delivery is part of the same tool surface as authoring, so the work ends where the user actually looks for it rather than in a link someone has to pass along.

II

The Four Tool Groups

The 13 tools cover four jobs. An assistant that has all four can go from reading a tenant to delivering an application to a user without leaving the conversation.

Discovery

List the frames in a tenant. Read a frame’s source. List what is on the desktop. Check whether a name is taken. Health check. This is how an assistant establishes the current state before proposing a change to it.

Authoring

Generate a working application from a plain-language description. Preview generated code without saving it. Save hand-written code. The same entry point serves generated and hand-written work, so a team can move between the two without changing tools.

Editing

Apply a targeted find and replace to one function instead of resending the whole file. Every edit runs as a dry run first and returns the exact byte delta before anything is written. Nothing is written that was not shown first.

Schema and desktop

Resolve and apply table DDL. Place and remove shortcuts on the user’s browser desktop. Storage and delivery are part of the same conversation as the code, not two follow-up tickets.

III

The Safety and Isolation Model

Letting an assistant write into a running system is a governance question before it is a productivity question. Three boundaries answer it, and none of them depend on the assistant behaving well.

(1) One Key, One Tenant

An API key binds the assistant to exactly one tenant and cannot be redirected to another. Isolation is a property of the credential rather than a rule the assistant is asked to follow, so a confused or misled assistant still cannot reach a tenant its key does not name.

(2) One Validated Entry Point

Every write, from any path, goes through a single validated entry point. AI-authored code is subject to the same checks as hand-authored code. There is no separate, more permissive route for automated writes, which means the checks do not have to be duplicated or kept in sync.

(3) Production Is Not Reachable From MCP

Production is deliberately unreachable from the MCP server. Promoting work to production runs through one gated path that moves code, schema, shortcuts, and users together. An assistant can build and refine freely, and the decision to make that work production reality stays a human, gated step on a path that does not leave the pieces half-promoted.

Thirteen tools, one tenant.
No pipeline in between.

If your team wants internal web applications built by conversation with an assistant it already uses, the connection is the whole setup. Request access, connect an MCP-capable assistant to your tenant, and build the first one.

Ready to connect an assistant?

Get a tenant and an API key.

Tell us what you want to build internally. We will get you a tenant, a key scoped to it, and the connection details for your assistant.

Request Access