"ILLEGAL EXPRESSIONS" that AI Agents are managing to write in Bubble

Well guys… a few days ago, before the launch of MCP, I was already using agents to work with my apps just like some of you here.

And then I ran into an unexpected situation… in some cases, the agents were writing expressions that are not natively allowed in Bubble, yet the issue checker doesn’t flag them as issues if you/or the agent manage to write them in a certain way… like writing it in a place and then copying it to another place where it was not natively accepted, or bypassing the editor limits using another ways.

I think this could even include some hidden fields that were available sometime in the past but the features were deprecated at some point or never released to users (some of you already flagged something like this, right?! Some hidden checkbox and things like that). And while typing this I was even thinking about some future features… what agents could do if they have access to them, even when it is hidden from end users while the feat is in alpha/beta or something like that?

Anyways… now that MCP is available, I believe many of these things might be happening silently, or will happen at some point, without users even noticing. And who knows? In the future, your app might break because something that should not work actually work right now, but could stop at any moment.

Here is an example I found sometime ago, not related to the recent ones, but just to give some context.

I’ll try to list some of these cases later, that also involve plugins, but for now I’d like to hear from you.

What are the expressions that aren’t natively supported in Bubble, but you found some way to write them bypassing the editor so it would not flag them as issues?

And… if you found some…

Did it work, and does it still work today?
Did it work for a while and then stop?
Did it work when you wrote it, but you never actually tested it?

I think if we try to collaborate with something like this, it could be used to map some of these “unsupported” cases, and maybe Bubble team could improve its MCP to prevent these expressions… or, if there are things that can be achieved in some way using workarounds and actually work, maybe they could be natively enabled or supported at some point, right?!

You know, in both cases this would be good for all of us, not just by helping us to build apps in a proper way, but also because once this kind of knowledge is integrated “into the MCP core”, it benefits everyone and spares you from having to add instructions like that to your .md files so all your agents know what to do and what not to do. Especially for those who are always counting tokens.

Interesting, seems the MCP generations still have some rough edges, I’ve not experienced what you mentioned yet but the MCP generation is creating some broken parameters for me where I had to recreate the WF itself to fix.

I guess the MCP may trigger some weird edge cases in places we don’t expect.

I have purposely written “illegal” expressions before AI. For example copying a “hover” condition from an element into a workflow conditional. That one has been working for years.

Do you have an example of an expression like this? For the one you linked you admitted to having manually written it.

I haven’t seen anything like this myself yet. From what I’ve seen Claude does a good job of writing down “illegal” things and making a note of it for future sessions.

But yeah Bubble definitely needs to keep improving the MCP and exposing more tools (e.g., WU measurer, Plugin MCP, login as user, edit/rename conditional, etc etc.).

That’s the future. With AI (generaly speaking) our role is now reviewing an output. We don’t code or “no-code” anymore.

Idealy we would need to train out agent in order to review our app against bubble’s manual in order to validate if each and every single expression is allowed to be.

just as a general disclaimer, they aren’t “illegal” in the sense that I’ll call the cops on you if I see your app using these…

Jokes aside, using stuff that isn’t fully documented/supported might break under weird edge cases. So use at your own risk and keep an eye out.

Yeah, that one I linked above was forced in that time.

I tried that with MCP and it was refused.

I created an app just to test this behavior. So here we can see an expression, not flagged as issue, using an Option set that in fact does not even exist in the app.

I am going to report few others to the team. Just preparing a “showcase” with some notes.