We really need a conversion tool to move from the legacy integration to the new one. I spent a year building a template-based solution that I planned to duplicate and resell to my clients, and now Iām missing out on the latest features simply because I started too early. This feels quite frustrating and, honestly, a bit unfair.
As mentioned in the thread, many users are still on the legacy integration. In my opinion, this should be a top priority to ensure that your long-standing users donāt feel left behind.
No offence but this is the most weweb thing to do I could imagine.
I came on here to clarify what I found missing from the MCP, but honestly not going to waste my time explaining how it can be improved if this is the kind of treatment we get using ālegacyā version of weweb. I canāt even use the MCP for the work I do cause its probably ālegacy featuresā that are missing for me.
Thank you for taking the time to summarise this. Just saved me half a day of thinking I could finally continue my build using claude only to find out it wonāt help me even one bitā¦
Thank you, @ekneba, for the feedback! Iāll share these details with the tech team right away to ensure those bugs and points of friction are addressed.
Regarding support for external databases, this is absolutely top of mind for us. We initially focused on the WeWeb stack because it was the most efficient way to build a solid foundation.
As you noticed, our goal was to unify the data management experience. Collections were confusing to many users in the decoupled setup, so the Data & API tab was designed to keep the benefits of a decoupled stack while offering a seamless interface. We are almost finished updating tables and views to match the functionality of collections. Thanks to this, @Hugo-OC, we can indeed start thinking about a migration button, or adding dedicated tools in the MCP for managing collections if not possible. Iāll discuss these options with the team.
We are currently finalizing the remaining server-side architecture so that all integrations can be added quickly using the same pattern. This means we will support Supabase, Xano, and Custom DBs, as well as the WeWeb Backend.
I hope this helps clarify where weāre headed! And please donāt hesitate to push back if something still feels unanswered or unfair. We definitely donāt want long-standing users to feel left behind.
This is brilliant! Your timing on getting this implemented coulldnāt have been better.
Have been working on Bubble for the best part of tweo years, and now having a (much more) reliable LLM to help me with building is a godsendā¦ Howeverā¦ Hereās Claudeās feedback on the last couple of days of issues.
Issue: MCP server not persisting session state between calls
When connecting to the WeWeb MCP endpoint (https://ai-api.weweb.io/v1/mcp), the workspace selection does not persist from one tool call to the next.
Steps to reproduce:
Call switchWorkspace with a valid workspace ID ā returns success (āSwitched to workspace ā¦ā)
Immediately call any workspace-scoped tool (listProjects, switchProject, etc.)
That second call fails with: No workspace selected. Call listWorkspaces then switchWorkspace first.
So the switchWorkspace call reports success, but the very next call behaves as though no workspace was ever selected. The session state set by one call isnāt carried into the next.
Impact: This makes the MCP integration unusable for any real work ā you canāt select a project, read a page, or make edits, because every operation after the initial workspace switch is rejected. It effectively breaks the entire MCP tool chain.
Notes:
This is intermittent ā it works fine for stretches, then enters this broken state for extended periods (30+ minutes at a time), sometimes recovering on its own.
Itās not client-specific: the same behaviour occurs across different MCP clients/LLMs connecting to the endpoint, and persists after fully rebuilding the connection and re-authorising ā which points to server-side session handling rather than anything client-side.
When healthy, the exact same call sequence (switchWorkspace ā switchProject ā reads/edits) works perfectly.
Likely area: session/state persistence on the MCP server ā the authenticated session or selected-workspace context appears to be dropped or not shared between sequential requests when in this state.
Sounds great, if it works with the frontend only setting?
P.S. Are you aware of the banner size? Itās 6074x859 in PNG (3.17 Mb) where vector is possible (bg-repeat + icons + shadows). Cāmon, yesterday you were a frontend-oriented company.
