I’ve been building a Bubble MCP connector and wanted to share it here
since I’ve seen a lot of interest in this topic across the forum. A few
things make this different from the other approaches discussed in these
threads.
One-click install via Claude Desktop Extension (.mcpb)
No Node.js, no JSON config files, no terminal. The connector is packaged
as an .mcpb Claude local extension - you install it directly from Claude
Desktop’s Extensions panel, enter your Bubble app URL and API token when
prompted, and it’s ready. Your credentials are stored in your OS keychain
(macOS Keychain / Windows Credential Manager), never in a plain text file.
Multiple Bubble apps in a single Claude session
This one is specifically for agencies. You can configure multiple Bubble
apps in the connector and switch between them in the same Claude
conversation. Managing five client apps? Claude can query App A, create a
record in App B, and analyse the schema of App C - all without reinstalling
or reconfiguring anything, and without switching tools.
What it supports
Data operations (Pro)
List records with filters, sorting, and pagination
Get a single record by ID
Create records with full field type support
Update records including list fields, linked records, and booleans
Delete records
Trigger backend API workflows with custom parameters
Schema awareness (free)
bubble://schema resource - Claude reads your full schema before every
operation so it knows your exact data types and field names upfront,
no guessing
analyze_app_schema prompt - surfaces structural issues, missing
relationships, fields that look like they should be linked records but
aren’t, and API access status per type
Developer tools (Pro)
generate_test_data - creates realistic or explicit test records for any
data type, correctly typed based on your schema
find_orphaned_records - finds records where a linked field points to a
deleted record, useful after bulk deletions
explain_record - fetches a record and all its linked records one level
deep, returns a plain English summary instead of raw JSON
Free plan
Full read access (list, get, schema analysis)
Single Bubble app
Privacy first
The connector runs locally on your machine. Your Bubble API token never
touches any external server - not ours, not anyone else’s. This is a
deliberate architectural decision, not a limitation.
Early access - 20 free Pro spots
Currently going through Anthropic’s Desktop Extension directory review.
In the meantime the .mcpb file is available directly.
The first 20 agencies get 3 months free Pro access - no commitment,
cancel before it ends if it’s not for you. There’s a live counter on the
page so you can see how many spots are left.
Curious what data operations people most want from an AI working on their
Bubble apps and what you’re going to come up with connecting Bubble with other MCPs!
Thanks @JohnMark and sorry for the trouble! it should be fixed now but let me know if you find any other issues. The pro plan costs $29/month after the first 3 free months (for those who get the first 20 spots).
In terms of security, if you’re sending your credentials in Claude chat, you’re exposing them as it goes through Claude’s servers. Our MCP connector keeps everything in the local OS keychain and that never leaves your computer (we don’t have servers so we don’t get to process your API key either). Claude gets to query the result of those API calls but never touches the API key.
More generally, the MCP is a packaged product that is developed and maintained by us, you don’t need to have the technical knowledge to manage a full API integration, and the fact that it’s available from Claude means you can ask in plain English. If something is off or a new feature needs to be built (or a new version of the API is released), you don’t need to make any changes yourself. We are also available for support and queries if you hit any technical issues.
We have also built logic around operations on top of the API like finding orphaned records or creating a set of test records. The API itself doesn’t support that natively, and we are open to releasing more workflow based features that benefit our customers.
The MCP also supports multiple Bubble apps by just using the app name, all in the same Claude session without switching credentials.
Happy to answer more here or you can try it free and let me know of any feedback you may have.
To give you some context on where we’re coming from - we have been
building data connectors professionally since 2019, starting with
Google Data Studio connectors (we have one for Bubble currently
under review). In that world we have hit the large dataset wall
repeatedly - Data Studio caps at roughly 10-30k records due to a
3-minute load limit (data is fetched live from the API without any caching), and there is no clean way around it without sharing your data with a third party that stores it so it can be fetched by Data Studio without making live API calls.
Developing Local Claude extensions change that entirely. Because the
extension runs on your machine, we can do something a hosted connector
never could - sync your Bubble data to a local SQLite database in the
background, and have Claude query that directly for reporting and
analytics. Joins work properly, we can store large data sets, we can store historical data, and nothing leaves your machine.
We are a team of 2 building from Spain, currently developing several
Claude tools alongside this one for our clients and as our own products. Between our products and our
consulting business we have integrated over 50 APIs in the past 7 years (yes we’ve done it before the AI era, although of course we make use of the tools available to us now) so the
architecture of what we are building is solid and informed by real
production experience.
As someone in this recent thread
put it well - deep messy integrations with ongoing maintenance are one of the categories that holds value long term. That is where we want to bring value. And the fact that it is a paid product means we are
genuinely there when support is needed or something breaks - this is
not a side project someone abandons in six months.
The local SQLite sync could be the Agency tier feature we are building
next. Before we scope it properly we would love to understand your
setup better:
How many data types are you working with and roughly how many rows
in the largest ones?
Is the reporting use case internal or client-facing? Would you require multiple separate databases, one per Bubble app?
Would you want to use the data retrieved for anything else other than reporting (e.g. syncs to other tools, writing to Google Sheets, industry specific reports like Amazon fulfilment manifest template generation etc)?
What does your current sync or reporting setup look like?
Happy to take this to a direct conversation if easier - you can book a call with us on our website.
You said: Sending your credentials in a standard Claude chat exposes them to Claude’s servers. But, aren’t you also doing the same thing, just in a different order?
Added: And also, why wouldn’t this explode work units? From what I can see from the way you built this, this would be a work unit nightmare. Which goes back to my question, ‘Have you ever built a site in Bubble?’
I’ll just repeat what I always say when I see posts about setting up a Bubble database as an MCP server: Don’t do it - even on an enterprise plan it will be better to build bespoke databases for AI interfacing.
It’s like the gold rush thing in the U.S. back in the 1800s.
Gold was discovered, and tons of people moved out west to look for it. Virtually nobody really got rich…
except the people who were selling shovels and other stuff to look for it.
Kind of like a lot of plugins I see lately. They’ve never built on Bubble, but they’ll sell you something to build better… problem is, some of the plugins I see lately will cost you a fortune to use them.
You don’t need all the shovels and buckets to make money on Bubble. Just build an app and get users. Nothing fancy until you get to the point where you can afford to be fancy and waste some money
thanks @senecadatabase I’ve only used Bubble to build test sites for our connector. But I have also not used Pipedrive, Xero or any of the other services for which I have integrated APIs for real businesses myself; I got context from my clients who were the real experts there and showed me what they needed that I could fix with my expertise on the API side. That’s what I’m expecting to hear from this conversation, but I thought I couldn’t come with my hands empty for credibility. So truly open to feedback and ideas here
Thanks! We are storing the API key in the OS keychain locally (so our connector never touches that credential) and then the connector code, which lives and is executed locally, is using that credential to call the API. The connector then outputs the data and sends it to Claude, at which point the data you query(not the API key) does get exposed to Claude’s servers.
On work units: That is a fair and accurate point. Every API call the connector makes does consume WUs on your Bubble app - there is no way around that. I believe direct Data API reads are on the cheaper end of WU consumption compared to workflow triggers or writes (0.01 Data API vs 0.1+ for others), but if Claude makes multiple calls to answer one question it adds up.
That said, this is true of any API-based tool. People on higher Bubble plans have higher WU limits, and they do not stop using Zapier, or Make because those tools make API calls - they use them because the benefit outweighs the cost. The expectation is that the tools connecting to those APIs are designed to minimise unnecessary calls, and that is exactly what we do.
For heavier analytical use cases this is also one of the reasons we are thinking of building a local SQLsync for the Agency tier - once your data is cached locally, read queries hit SQL and make zero calls to Bubble entirely, which eliminates the WU impact for reporting and analytics. Writes still go to Bubble directly since they need to.
For day-to-day operational use like fetching or creating a record, triggering a workflow - the WU cost per Claude interaction is comparable to a user doing the same thing manually in your app. Worth factoring in, but not a reason to avoid a tool that saves you time if it is designed responsibly I believe.
Out of curiosity - how are you currently extracting data from your Bubble app for reporting or analysis (Zapier, manual, SQL)? Understanding your current setup would help us figure out where the local sync would have the most impact and whether it could actually reduce your overall WU consumption compared to what you are doing today.
Yeah but if it’s a heavier use case then that’s because there’s more data… and therefore the cost of ‘syncing’ a Bubble database will be disproportionately higher…
If the user’s queries are so expensive that local sync makes sense, then local sync would be so much more expensive that that also doesn’t make sense.
Just to reset - the current tool is designed for targeted operational use: light reads, writes, schema analysis, and workflow triggers. That is what it does well and what it is already built for.
The SQL sync came up because @Eugene_West mentioned large-scale reporting as a use case - but if that is not a fit for Bubble apps generally, that is actually good news for us, as it means one less feature to build. Maybe @Eugene_West can contribute in how they are handling the WUs issue since it’s something they are already building.
I can still see useful targeted operational queries within normal usage patterns:
create new records for daily signups or onboarding steps
trigger a Bubble workflow for a specific user from Claude routines with parameters (for example we could send the analysed sentiment of an email received from a customer)
retrieve a customer record and all its linked data to answer a support query
generate a set of realistic test records before a demo
I would love to hear what other use cases people have for the existing version of the MCP.
If your use case is bulk analytics on hundreds of thousands of rows, this is probably not the right tool and we will say so clearly in the docs.
We are still in the planning/brainstorming stage with small demos. But WU usage was raised as a concern, and we thought about either caching/ or writing to a file once the whole table/request ( e.g specific user requested report ) and maintaining that file.
@Eugene_West on a theoretical standpoint, I fully agree with you that caching is the way to go to make sure API calls are minimised. However, it seems there is limited interest in the community to pull data outside of Bubble for reporting since the usage of WUs will always be too much (please anyone correct me if I am wrong), so we are not embarking on that direction for now.
[Claim your spot → thedatastudents.com/bubble-mcp]