Softr quietly shipped one of the more strategically interesting product launches in the no-code category last month. On June 16, 2026, the Yerevan-headquartered no-code app builder published its first Model Context Protocol server, making Softr the first major no-code app-builder platform to ship a first-party MCP integration. The product is straightforwardly useful: an MCP-aware AI agent (Claude, ChatGPT, Cursor, or any other client that implements the protocol) can now query and mutate data inside a Softr app, in real time, as part of the agent’s normal conversational workflow. The product is also strategically interesting: it reframes what a "no-code app" actually is. Until this launch, a Softr app was an app a non-developer could build and share with end users. After this launch, a Softr app is also an AI-addressable backend that any modern agent can read from and write to without custom integration work.
This piece walks through what Softr actually is for readers who do not already know the platform, the Softr Databases foundation that the MCP integration builds on, what the MCP server does in detail, the authentication and scope model, the agentic workflows it enables, the comparison to Retool’s MCP integration (which sits at a different layer), and the broader pattern this represents for the no-code category. The goal is that after reading this you can decide whether the integration matters for your team and, if so, what configuring it actually looks like.
The short version is that Softr’s MCP server is real, shipped, and substantive. The MCP endpoint lives at mcp.softr.io/mcp. It exposes 20 tools across Databases, Tables, and Records operations. It ships with pre-built OAuth 2.1 clients for the major AI platforms (Claude, ChatGPT, Cursor, Mistral) so end users do not need to manually register OAuth applications. The permission model uses three scopes (records read, records write, schema write) that let operators decide how much trust to extend to a connected agent. The integration is at the data layer (agents read and write app data) rather than the build layer (agents generate the app itself), which is the slot Retool’s MCP server fills. The two products are complementary rather than competitive.
What Softr is
Softr is a no-code app builder originally launched in 2019 by Mariam Hakobyan and Artur Mkrtchyan. The company is headquartered in Yerevan, Armenia, with team members distributed globally. The initial product was a frontend builder that connected to an Airtable database, letting non-developers turn Airtable bases into client-facing web applications without writing code. The original positioning was "Airtable to website in minutes."
Through 2022 and 2023, Softr expanded its supported data sources beyond Airtable to include Google Sheets, HubSpot, SmartSuite, and other backends. The customer base grew into the client-portal and internal-tools categories, with Softr-built apps powering member sites, partner portals, support systems, and operational dashboards for a wide range of companies. The company raised a $13.5 million Series A in 2022 led by FirstMark Capital, with Matt Turck taking the board seat.
The 2025 product evolution shifted Softr’s strategic positioning. The company launched Softr Databases, a native relational database product that lives inside the Softr platform itself. The addition of native databases changed Softr from "frontend for your other tools" to "full-stack no-code platform." External integrations remained supported, but the strategic emphasis shifted to the native database as the recommended foundation for new apps. Softr Workflows (native automation) followed in the same 2025 cycle, completing the full-stack picture.
By mid-2026, Softr reports approximately 1 million builders on the platform, 700,000 active teams, 7,000 paying organizations, and over 1 million apps published. Customer logos include Netflix, Google, and Stripe in addition to the long tail of small and mid-size businesses that make up the core of the no-code app-builder market.
The MCP server is the first major product launch of 2026 and is the most strategically interesting because it does not extend Softr’s existing product surface in a direct way. It does not make app-building easier. It does not add new data sources. It does not improve the runtime performance of Softr-built apps. What it does is make Softr-hosted data accessible to AI agents through the standardized Model Context Protocol that Anthropic published in November 2024, which means any AI client that speaks MCP can become a participant in workflows that previously required custom integration code.
The Softr Databases foundation
Understanding the MCP server requires understanding the Softr Databases foundation that it sits on. The MCP server exposes Softr Databases data; it does not directly expose Airtable, Google Sheets, or the other external integrations. The integration is a Softr-native surface that customers who have moved to Softr Databases can use, while customers still on external integrations see a more limited MCP surface or none at all depending on the specific integration.
Softr Databases provides a relational data model that resembles other modern application databases. Tables have typed columns. Tables can have relations to other tables. The data syncs in real time with Softr-built apps that use the database. The product is positioned as the right starting point for new Softr apps, with Softr’s own onboarding flow defaulting to native databases rather than the older external-integration path.
The strategic logic behind the Databases launch is now clearer in retrospect. By building a native database, Softr created a data layer that the company controls end-to-end, which made it possible to ship integrations (like the MCP server) that depend on operations the external data sources do not support uniformly. Airtable, Google Sheets, and HubSpot all have APIs and could in principle support an MCP integration, but the operations they each support are different enough that a unified MCP surface across them would be limited. With Softr Databases providing a single consistent backend, the MCP server can expose a rich operation set that works the same way for every customer.
What the MCP server does
The MCP endpoint at mcp.softr.io/mcp is an HTTP server that implements the MCP protocol. AI clients connect to the endpoint, authenticate, list the available tools, and invoke tools as the user’s conversation requires. The 20 tools the server exposes are organized into three groups.
The Databases group handles operations on entire databases: listing the databases the authenticated user has access to, retrieving database metadata, and similar operations that operate at the database level. These tools are the entry points for an agent that needs to discover what data is available before drilling into specific tables.
The Tables group handles operations on tables within databases: listing tables, retrieving table schemas, creating new tables, updating table structure, and similar operations. These tools let the agent understand the structural shape of the data and, with appropriate permissions, modify the schema.
The Records group handles operations on records within tables: querying records with filters, sorting, and pagination; retrieving individual records by ID; creating new records; updating existing records; and deleting records. These are the workhorses for the most common agentic workflows, since most useful agent tasks reduce to "find some records, do something with them, and possibly create or update records as a result."
The tool surface is curated rather than comprehensive. Each tool has a specific operation it performs, with explicit parameters and explicit return types. This is different from a "run any SQL" interface and is the appropriate design for an MCP server because it lets the agent reason about what each tool does without having to construct arbitrary queries that might or might not work. The cost of the curated surface is that some advanced operations (complex multi-table joins, window functions, custom aggregations) are harder or impossible to express; the benefit is that the agent’s behavior is more predictable and the security model is more constrained.
Authentication and scopes
The authentication model is the part of the design that determines how an end user actually connects an AI client to the Softr MCP server. Softr’s implementation supports two paths.
The OAuth 2.1 path is the recommended flow for interactive end users. Softr has registered pre-built OAuth client IDs for the major AI platforms (Claude, ChatGPT, Cursor, and Mistral) and published those client IDs in the MCP documentation. End users configure their AI client with the Softr MCP URL and select the appropriate pre-built client; the AI client redirects to a Softr browser flow for authorization; the user grants permission with the specific scopes the client is requesting; the OAuth tokens are issued and stored in the AI client’s secure storage. Subsequent sessions reuse the stored tokens until they expire.
The pre-built client IDs are a quality-of-life touch that meaningfully lowers the friction for end users. Without pre-built clients, each user would have to manually register an OAuth application in Softr before they could connect their AI client, which is an extra step that many non-technical users would not complete. With pre-built clients, the user experience is just clicking through a browser authorization, which is the standard pattern users are already familiar with from "Sign in with Google" or "Connect to GitHub" flows.
The Personal Access Token path is the alternative for use cases where OAuth does not fit. CI/CD pipelines, headless automation, custom AI clients that do not implement OAuth, and other non-interactive scenarios authenticate with a PAT or bearer token configured in the client. The PAT path is more flexible but requires the user to generate and securely store the token themselves.
The permission scope model offers three levels of access that the user grants at OAuth authorization time.
records:read grants the AI client the ability to query records, retrieve individual records, and list tables and databases. It does not grant any ability to modify data. This is the safe-by-default scope and is the right choice for read-only workflows like reporting, data analysis, and information retrieval.
records:write grants the ability to create, update, and delete records in addition to the read permissions. This is the scope needed for workflows where the agent will modify data, such as CRM updates, support workflows, and data cleanup tasks.
schema:write grants the ability to modify the database schema: create tables, add columns, change types. This is the most powerful scope and is appropriate only for workflows where the agent is performing app development work, like designing a new feature’s data model.
The scope model maps cleanly to the typical use cases. Most workflows want records:read or records:read + records:write. The schema:write scope is for the small fraction of workflows where the agent is genuinely doing schema design and most users will not grant it.
What this enables
The workflows the Softr MCP server enables for customers who use it:
Data exploration and reporting. An agent with read access can answer ad-hoc questions about the data in a Softr app. "How many tickets came in last week?" "What’s the most common product complaint?" "Who are our top ten customers by lifetime value?" The agent generates the appropriate queries, runs them, and synthesizes the results. This is the lowest-friction workflow because read access is the safest scope and the use cases are intuitively obvious.
CRM updates and contact management. With write access, an agent can update contact records based on conversational instructions. "Add John Smith as a new contact with this phone number." "Mark all the leads from yesterday’s event as warm." "Update the last contact date on these accounts." The pattern is most useful when the agent is operating in a context where the user is having a conversation about specific records (a CRM-focused chat surface).
Support workflow assistance. A support agent (the human kind) working in a Softr-built support tool can have an AI agent (the software kind) assist with research, drafting responses, and updating ticket status. The combination of the AI’s ability to read ticket history and the AI’s ability to update tickets based on conversational direction is what makes this workflow useful, where either capability alone would be more limited.
Data cleanup and enrichment. Periodic data-quality work that previously required custom scripts can now be done conversationally with an agent. "Find all the contacts with missing phone numbers and queue them for outreach." "Identify duplicate customer records and merge them." "Enrich every company record with its industry classification from the website domain." The agent does the bulk operation and reports back what it did.
Operational reporting and dashboards. A user can ask an agent for a custom report ("show me revenue by region by month for the last quarter") and the agent will query the data and synthesize the report. This is more flexible than the dashboards the user could build in Softr’s own UI because the report is generated on demand rather than pre-built.
Schema design and migration assistance. With schema:write access, an agent can help design new tables and migrate the schema. The use case is most appropriate for the app builder rather than for end users; it shifts some of the no-code work from clicking through Softr’s schema designer to having an agent propose and apply changes.
Softr-MCP vs Retool-MCP
The no-code category in 2026 has two notable first-party MCP integrations. Softr’s is at the data layer. Retool’s is at the build layer. The two are complementary and serve different purposes.
Softr’s MCP server lets agents read and write the data inside running Softr apps. The agent is operating on the app’s content. The app itself is unchanged by the agent’s actions; only the data the app exposes is changed.
Retool’s MCP server lets agents read and modify the Retool apps themselves. The agent is operating on the app’s structure. New components are added, data sources are connected, layouts are adjusted. The data that those Retool apps interact with is downstream of the agent’s work.
The two patterns serve different audiences. Softr’s data-layer MCP is useful for the end users of Softr apps and for app operators who need to interact with their apps’ data. Retool’s build-layer MCP is useful for the app builders themselves who are creating and maintaining Retool apps. Many organizations would benefit from both: an app builder uses Retool-MCP to build the app, and an end user uses Softr-MCP (or a Retool equivalent if Retool ships one in the future) to interact with the app’s data.
The fact that the two platforms have implemented MCP at different layers is part of why the no-code MCP story is interesting strategically. The protocol is general enough to support both patterns, and different platforms are reaching different conclusions about which layer of the no-code stack benefits most from AI agent access. The expectation is that the broader no-code category will eventually have MCP integrations at both layers across most platforms; Softr and Retool are early.
The broader no-code MCP landscape
Beyond Softr and Retool, the major no-code app-builder platforms have not yet shipped first-party MCP servers as of mid-2026. Bubble, Glide, Adalo, Stacker, Noloco, and the other established players in the category do not have official MCP integrations. Whether this changes through 2026 and 2027 is one of the open questions in the no-code-meets-AI story.
The likely trajectory, based on the pattern Softr and Retool have set, is that the platforms with the strongest engineering investment will ship MCP integrations first, with broader adoption following as the user demand becomes more visible. The Softr launch creates a competitive pressure: customers evaluating no-code platforms now have a concrete AI-integration feature to compare on, and platforms without MCP integrations are at a disadvantage for the subset of customers who care about this capability.
Community-built MCP servers exist for some of the other platforms, particularly through the open-source ecosystem. These typically expose a subset of the platform’s API as MCP tools, with varying levels of polish and maintenance. The community option is workable for technical users but lacks the pre-built OAuth client touch that makes Softr’s first-party implementation usable by non-technical users.
The GoodBarber platform is one to watch outside the traditional no-code app-builder lane. GoodBarber has shipped an open-source MCP server plus a set of Claude Skills for app management, which represents a different model than either Softr (data layer) or Retool (build layer). The diversity of approaches across the no-code MCP landscape is likely to continue through the next year.
When this matters
For organizations using Softr, the MCP server matters most if any of the following apply.
Your team uses Claude, ChatGPT, Cursor, or another MCP-aware AI client regularly and would benefit from giving those agents access to the data in your Softr apps. The integration is most valuable when the AI usage is already part of your team’s workflow; adding the integration to a team that does not yet use AI agents extensively will produce less benefit.
Your Softr apps are on Softr Databases rather than external data sources. The MCP server’s surface is built around Softr Databases; customers still on the older external-integration path will see a more limited surface or none at all.
The kinds of workflows you actually run match the agentic patterns the integration is designed for: data exploration, CRM updates, support assistance, data cleanup, operational reporting. Workflows that do not fit these patterns may benefit less from the integration.
For organizations not using Softr, the launch matters as a category signal. The no-code platforms are starting to ship first-party MCP integrations, which means the "your app data is accessible to AI" capability is becoming a baseline expectation rather than a differentiator. If you are choosing among no-code platforms, the MCP integration story is now a meaningful evaluation criterion alongside the more traditional ones (data sources supported, pricing, design flexibility, integration count).
Frequently asked questions
Do I need a paid Softr plan to use the MCP server? The MCP server is available across Softr plans, but the specific scope of what each plan supports has some variation. The Free plan supports limited MCP usage; the paid plans support the full surface. Check Softr’s pricing page for the current tier breakdown.
Will the MCP server work with my existing Airtable-backed Softr app? The MCP server’s full surface is built around Softr Databases. If your app uses external integrations as its data source, the MCP integration is more limited. The recommended path is to migrate your data into Softr Databases if you want the full MCP experience.
Does the MCP server respect Softr’s existing access controls? Yes. The MCP server authenticates as a Softr user (the user who authorized the connection through OAuth), and that user’s existing permissions inside Softr apply to MCP operations. An MCP-connected agent cannot access data the authorizing user does not have access to.
Can multiple AI clients connect to the same Softr workspace simultaneously? Yes. Each AI client maintains its own OAuth session. There is no conflict between concurrent connections.
What happens to the AI client’s tokens if I revoke its access in Softr? Revocation is immediate. The next MCP operation the client attempts will fail authentication and the user will need to re-authorize.
Is the MCP integration available in Softr’s enterprise tier with additional controls? Softr has indicated enterprise-specific MCP features (additional audit logging, IP restrictions, custom OAuth client registration) are in development but not yet generally available as of the June 16 launch.
Does the MCP server work with my custom Softr app domain? The MCP endpoint is the same mcp.softr.io/mcp regardless of which Softr workspace the connection is for. The OAuth flow identifies which workspace the user wants to authorize.
Can the agent build new Softr apps through the MCP server? Not directly. The MCP server is for interacting with existing Softr Databases content, not for building new apps. The "build new apps" use case is closer to what Retool’s MCP integration covers. Softr has indicated app-building MCP capabilities are being considered for future releases but are not part of the current scope.
Is there a rate limit on MCP operations? Softr applies usage limits at the workspace level that include MCP operations. The specific limits vary by plan. Heavy automated workloads should be evaluated against the workspace’s limits before going to production.
How does the Softr MCP server handle real-time updates? MCP is a request-response protocol; the server does not push updates to the agent. The agent queries data at the time the user asks; if the user wants up-to-date data, the agent re-queries. For workflows that need push-style updates, the Softr realtime APIs are accessed through the app’s native channels rather than through MCP.
