Thanks for the updates! Just wanted to drop some quick feedback regarding the recent WeWeb AI changes. Right now, tokens are burning like nowhere before. Guess it is because of extended Planning and Reasoning of the agent (which did not lead to better results at all). I have the feeling that it is trying and thinking “too much” now.
To give you some context, here is what I just ran through:
Adding skeleton loaders to a dashboard: 3 Million tokens
Adding some process steps: 2 Million tokens
Trying to add a simple submenu to a sidebar item (2 items): 3 Million tokens.
That last one was especially rough—after a few fixes, the last iteration broke everything. I had to roll back to a backup because the option to revert/circle back wasn’t available.
That is 8 Million tokens in total, and I wasn’t even asking it to create whole sections, complex workflows, or entire pages. We are talking about relatively simple UI tweaks.
At this rate, my plan (€25 for 10M tokens) is going to evaporate instantly. I honestly feel like pulling in Claude Fable 5 would even be cheaper at this point. In my opinion, the previous version felt much better and more efficient.
I think I’m going to have to look into trying MCP for now. Anyone else noticing a massive spike in token consumption for minor edits?
Hey Michael, thanks for taking the time to provide detailed feedback. It’s super helpful! I’ll pass it on to the team. Would you mind creating a feedback ticket here if you haven’t already with a link to your projects so the team can take a look and investigate further? I’m not sure if it’s a new release thing or something else going on but definitely worth a look on our side.
We indeed had an issue post release where we weren’t counting tokens properly. This has been fixed and miscounted tokens were added back to the workspace
In the email sent out 12hrs ago titled “WeWeb’s MCP server got even more powerful” it lists “better handling for multi-page apps”, and "improved support of native elements and CSS states".
Is this the correct post with this details?
I see “MCP now leverages reusable sections when building multi-page apps”.
What I was hoping to see was the MCP being able to access Assets and reusable Popups. Both of these things have been inaccessible by the MCP and it’s very frustrating. I’m building a b2b multi-tenant SaaS and having multiple version of elements and not being able to utilise project wide popups with their native advantages.
I would ask for:
That the MCP could access and access and utilise both Assets and reusable Popups
A simple prompt update to give to AI when MCP changes are made. Even if I notice the announcement, vague headline language means I will have to prompt Claude to poke and prod at the MCP to see if anything has changed, costing tokens. I have a list of MCP function restrictions built into my claude.md file that gets added to every time we discover something can’t be done by the MCP, to save it tokens in the future. But now those notes are there, it will never discover changes and improvements that you make unless I, as a user, are made aware of them and prompt it to reinvestigate.
But I am thankful for the work and changes you are making. The MCP as a whole has opened up efficancies and complexities that would have been outside my my bounds beforehand. Allowing me to create a much more beneficial product to my users.
Now works.searchProjectImages returns all 25 project images (app icon, wordmark, landing snips…) with bindable URLs I can drop straight into ww-image. No more mock-only images.
Reuse across multiple pages
Now works — via reusable sections. Live-tested: reuseSection linked one section onto a second page, keeping the same UIDs, edits propagate to all pages, and deleting from one page removes only that instance.
Native popups specifically
Still invisible to MCP. There is no popup/modal element type MCP can see or build. Modals still have to be in-page ww-div overlays.
Coded components (bonus)
Now visible + placeable + editable — xxxxxxx-phone-input and xxxxxx-scroll-lock both list as ready/editable. This was previously “unknown element type.”
Unchanged / still stand: No Supabase CRUD via MCP · native popups invisible · element reparenting impossible · per-call projectId still required.
a modal built once as a reusable section carries its element workflow + conditional-render binding to every page — provided it uses an element-scoped workflow + a global variable (not page-scoped ones). That’s the answer we needed.
Plus a bonus discovery: there are open-popup / close-all-popup workflow actions. So even for real native popups (which MCP still can’t build), MCP can wire any page’s trigger to open one by its library-component id. That’s the cleanest long-term answer to “reuse a popup across pages” — you build the popup once, I wire every trigger to it.
The other big ask would be for MCP to create Supabase CRUD/select actions. It can currently only read them so it creates stubbed workflows that I have to finish.
EDIT: realised I’d already mentioned it. But important to say again i guess
Just thought I’d chip in a workaround for this btw - you can have it create functions that it can use, and have it ask you to populate the function with the supabase/xano action. Works for me for xano.
One thing that’s a little confusing though is that right now it can’t author error branch actions unless I have a placeholder note or similar there for it to replace - not sure if it’s just something I’m doing wrong?
This may be off base though, as it’s for the cli using claude code rather than the inbuilt weweb chatbot
@Joyce where is the best place to put feedback like this? in the feedback form? when the MCP hits a block it creates a note in the claude.md file, it would be good to also have a place for user-found blockages. This what it gave me for weweb feedback in this instance:
Feature request: expose design-system class/token usage through the MCP.
There’s currently no way to answer “what uses this class?” — searchDesignSystemClasses
returns definitions but no consumers, and style-class uids aren’t emitted into rendered DOM
class names, so an external computed-style probe can’t recover the link either (I confirmed
this against a class I knew was in use). That makes “verify unused before deleting”
unperformable: the only workable fallback is probing signature values on the published site,
which is blind to layout-only classes (flex: 1, width: 100%), to unpublished edits, and to
popups/sections — and the alternative, getPageSemantic across every page, costs ~20k tokens
per page.
The fix I’d want most is a usage field on searchDesignSystemClasses /
searchDesignSystemTokens — a count plus [{pageId, pageName, elementUid}] — and for
deleteDesignSystemClass to refuse with that list when references exist, behind a force flag.
Worth noting the asymmetry: deleting a token is already safe because var(–uid, #literal)
falls back to the literal, but deleting a class silently strips styling with no error.
Usage data would also stop agents defaulting to “create a new class” because they can’t tell
what’s already in use — which is the exact drift your own tool descriptions warn against.
(If this exists somewhere I’ve missed, I’d rather be pointed at it.)
I always relay your thoughts when you post in the community forum of course (creating a feedback ticket of my own with a link to our conversation) but it’s more efficient if you create a feedback ticket on your side because:
you can track the progress of the feedback ticket directly
the team can more easily reach out to you and ask for more context if needed
Note: it helps if you add a couple of tags at the beginning of the ticket title. For example [MCP] or [WEWEB AI] or [DATAGRID] or [INTEGRATION] [SUPABASE], etc.
Clearer planning and task tracking in WeWeb AI
MCP improvements
Now works. 
Still invisible to MCP. There is no popup/modal element type MCP can see or build. Modals still have to be in-page 