Pular para o conteúdo
← Back to Skalablog

Published article

How Softr MCP Builds a Full App in One Claude Session

Software EngineeringClaudeAirtableSupabase

The interesting part of Softr MCP is not that an AI writes pages. It is that the connector exposes the boring layers, database schema, user groups, permissions and workflows, and lets Claude test the result by logging in as different users. Builders who skip planning will get a fast app with the wrong data model.

What Softr MCP Actually Connects

Softr MCP is a Model Context Protocol connector that exposes a Softr workspace to an AI assistant, letting Claude create and edit the database, pages, workflows and user groups behind a Softr app. The connector is configured from Claude connectors menu, where each available action can be set to always allow, require approval, or be blocked outright.

Model Context Protocol is an open standard for connecting AI assistants to external tools and data. Softr is a no-code platform for building web apps and client portals on top of structured data, and its MCP server is documented at Softr's official documentation. The pairing means the assistant works on the app itself, not on a text description of it.

Gareth Pronovost, who runs the no-code channel Build Without Code, demonstrated the flow in a video published on 16 September 2026. His build never opened the Softr builder until it was time to verify the result, and every page in it came from a chat prompt.

The connector also covers user sign-in. Claude log into a finished app as a test user, which turns the assistant into a quality-control tool rather than only a generator.

The Three Layers Softr MCP Covers

Softr MCP covers the three layers any application needs: storage, movement of data, and presentation. The demo created a database, built pages against it, and defined the workflows and permissions that sit between them, all from the same chat session.

The data layer came first. Claude created tables for clients, people, projects, tasks and updates, with the fields requested in the scope and sample rows seeded for testing. Pronovost reported the build took a little over five minutes.

The presentation layer came next. The dashboard page was built entirely from a vibe-coded block, meaning Claude generated the component rather than assembling one from Softr's built-in library. That matters because a genuinely custom layout is the part a template-driven builder normally cannot produce without manual work.

The third layer is access. User groups for admins, team members and clients were created from rules written in the scope, and pages such as the client portal, my tasks and project detail were assigned the matching visibility.

LayerWhat Softr MCP createdWhere the rules came from
DatabaseFive tables with fields and seed rowsScope of work, data model section
PagesDashboard plus admin, team and client pagesScope of work, page section
AccessUser groups and page visibilityScope of work, permissions section
WorkflowsBlocked-project alert, task completion updateScope of work, automations section

Does Softr MCP Avoid the Double AI Credit Tax?

Softr MCP does not charge Softr AI credits for prompts sent through Claude, according to the demonstration. Builders pay only their Claude or OpenAI subscription for the model work, which Pronovost calls the absence of a double credit tax and proposes as a benchmark for other AI-building connectors.

That claim is first-hand experience from one user's session, not a published pricing guarantee. Credit accounting changes with plan terms, so verify the current arrangement on Softr's pricing page before budgeting a project around it.

The cost comparison he draws is with tools such as Supabase and Airtable, where the same workflow can consume AI credits on both the model side and the platform side. Those two products are different categories: Supabase is an open-source Postgres backend with authentication and edge functions, while Airtable is a hosted database with its own automation and AI features.

For a small build the difference is minor. For a shop running many client projects through AI prompts, the credit model is the difference between a predictable bill and two metered services watching the same work.

Why the Scope of Work Determines the Result

A written scope of work is the reason the demo was fast, and Pronovost is direct that the thinking, not the prompting, is where the value sits. Claude received the scope document with an instruction to read it and take no action, then built against named tables, fields, automations and acceptance criteria.

Without that context, the assistant tends to build things nobody asked for. The scope in this build contained a background section, system goals, user groups, a data model naming the five tables and their relationships, a field list, automations, out-of-scope items, assumptions and acceptance criteria.

Seed data was part of the specification, which is easy to overlook. Sample rows let you test whether a page pulls the right records before real data exists, and they make the difference between a demo that looks correct and one that can be verified.

The practical sequence for a new build is worth stating plainly:

  1. Write the scope, including data model, user groups, automations and out-of-scope items.

2. Paste the scope into the assistant with an instruction to read it before acting.

3. Ask for the database layer only, then verify the schema before building anything on top of it.

4. Build pages and permissions from the scope sections, then run quality-control checks against seeded data.

Claude Builds the Database Before Any Pages

Claude builds the database first, and signing it to the spec matters more than speed. In the demo, the prompt asked for the data layer only, based on the scope, with a link returned so the schema could be checked before anything was built on top of it.

The verification step is short. Open the returned link, confirm the tables exist with the expected fields, confirm the relationships, and confirm the seed rows landed. A wrong column name found here costs a minute. Found after six pages and three workflows exist, it costs a rebuild.

Only after the schema checked out did the second prompt build the dashboard page with the vibe-coded block, and the third prompt add the remaining pages and user groups. That order is what keeps an AI build reviewable.

The connector returns two artifacts per page: the live page and the editable page in Softr Studio. The editable version is the one to fall back on when a generated layout needs adjusting by hand.

Testing Is a Second Use for Softr MCP

Softr MCP can also act as a quality-control tool, because Claude sign in as a test user and take actions on their behalf. Pronovost calls testing the most important element of any build and recommends running it before an app goes live, with a manual pass afterward.

The mechanism is impersonation. Claude logs in as a client or a team member, which is how you check that a client cannot open the admin page and that a project owner can see their own tasks. Permission bugs like those are invisible in the builder, because builders see everything.

Workflows get the same treatment. A blocked-project alert or a task completion update can be triggered in a test environment and watched, instead of being trusted because it was generated correctly.

The limit is scope. An assistant checking its own output is not an independent test, and Pronovost notes that a human should still run the final end-to-end pass. Treat the MCP checks as a fast first gate that catches broken data bindings and permission leaks.

What Softr MCP Does Not Remove

Softr MCP removes mechanical build work, and leaves the parts of a project that decide whether it is any good. Planning, data modeling and testing stay with the builder. The demo was quick because the specification was already complete when the first prompt ran.

The cost of skipping that work is a fast app with a data model you will need to migrate later. A schema decision made in a chat prompt is as consequential as one made in the builder, and much easier to reverse by accident.

There is a governing distinction here. Speed of construction is not the same as quality of construction, and the transcript makes the point in the builder's own words: the planning is the meat of the project, and it is the part that rarely gets rewarded.

For anyone following this workflow, the advice is unglamorous. Spend more time on the scope document, spend more time on quality control, and let the assistant do the assembly. Also keep the manual path in reach, because the app remains editable in Softr after the prompts finish.

FAQ

  • What is Softr MCP? It is a Model Context Protocol connector that lets an AI assistant such as Claude work inside a Softr workspace, creating databases, pages, workflows and user groups from prompts. Setup happens in Claude connectors menu, where each action can be allowed, approved per use, or blocked.
  • Does building through Softr MCP cost Softr AI credits? In the September 2026 demonstration, prompts sent through the connector consumed only Claude AI credits, not Softr's. Because that reflects one user's session rather than a published policy, check the current plan terms before committing a budget.
  • Can Claude test the app it built? Yes. Claude sign in as a test user and take actions on their behalf, which reveals permission problems that are invisible inside the builder. A human end-to-end pass is still recommended before launch.
  • What has to be done before prompting? Write a scope of work covering the data model, field names, user groups, automations, out-of-scope items and acceptance criteria. Then ask for the database layer alone, verify the schema, and build pages and permissions afterward.
  • Is the app still editable in Softr? Yes. Every generated page also appears in Softr Studio, so visibility rules, layouts and data bindings can be adjusted by hand after the assistant finishes.

Source video