Hi,
lot of actors in AI are “in the way of MCP” ,
As I understood in last night Xano webinar, they are in too 
Is something doable / planned to add it in weweb ?
I mean add a kind of “Agent MCP action” , from context it got , it while choose himself which tool to use (instead of an explicite endpoint request in our workflow) ?
Patrick @Joyce
I’ve asked about this and apparently the main heads at WeWeb aren’t interested in a MCP for some reason.
AI doesn’t even work properly, a MCP won’t fix it.
hey @mikecoulbourn, who said that?
hey @patrick_colean thanks for asking, @flo (our CPO) has this in mind and is looking for concrete use cases to build the case internally. Would you mind sharing yours with us here or with me in DM? thank you!
Hey Raphael,
My thoughts about MCP use cases:
the Figma2Weweb workflow would be a perfect use case. Also the Supabase integration could be updated/improved using their MCP server..
Besides that, for the actual generation of components/pages, exposing the whole design system, weweb ui elements etc. within a weweb mcp server to optimize the generation of those would definitly benefit it. I imagine you already do something like this for the current AI but by using an LLM Agent directly. By using MCP this could be cleaner and more efficient as it probably has more context of all the elements (depends heavily on the implementation of course..).
Last but not least, a MCP client element in weweb, which makes it possible to easily create chat like applications, which then can connect to added servers using MCP. This would make it easy to build AI apps within weweb.
Hello !
I have a bunch on my mind, but morever in fact, if we take for eg, the MCP Server (not client*) from many other external tools like Auth0 MCP, NeonDB MCP+ Azure AI Agent(or w/o), and so on..
I personnaly make on my side a MCP client with some function calling I think in order to properly communicate and get those treat (with some backend etc but is ok)
imo not “urgent” for WeWeb to have its own MCP Server SSE, but won’t hurt to think about the client side for your next AI Chat components/templates you are currently cooking (my eyes are everywhere yes ahah)
tldr : MCP client = less workload on your side, less potential security, or bug outage, and giving a “cloud”/local webapp "nocode way to build our own MCP client rather than those Claude Deskstop Cursor etc..
Just a small feedback !
edit : oh didn’t saw the message of jayjay, but I aggree !
Well … actually … MCP could, in theory, be a path to accelerate better AI in the WeWeb copilot - (really depends on how they are approaching it.)
Theoretical approach:
WeWeb builds a custom HOSTED MCP server - this can be done on Cloudflare and also now on Vercel - MCP server support on Vercel - Vercel
Within that hosted MCP server - WeWeb could create granular AI TOOLS for building types of custom components and also granular AI tools for wrapping code into WeWeb formatted components. This allows WeWeb to break up the approaches to specific types of components, etc - and the choice of which tool to use would be triggered by the LLM requests to the server - essentially - you could create very granular tools with NL descriptions for use - so, instead of a hard coded logic - you let the LLM choose the tool. So … if you are clever and very granular with your custom tools you define the actual custom MCP server … you can achieve “AI” that is much more effective than just throwing larger context windows and monster prompts to a model.
So .. I’m suggesting that a hosted, custom MPC server - is where the prompts to the WeWeb pilot go - then the returned code from the MCP server goes back to WeWeb.
Just my 2 cents - I know nothing - just thinking out loud.
This is basically what the current, not very great AI does anyway, right? How would an MCP be different?
Totally depends on how they have built their orchestrator. If it’s custom / condition based tool calling vs using a framework like Akka or leveraging MCP protocol - you will 100% get different results / quality. Building an orchestrator with MCP gives you a ton of control to quickly iterate. The reason one co-pilot is more effective that another almost always about how the orchestrator is architected.
Now I’m using successfully MCP with weweb through Xano (with external API request, you can build MCP server for everything ! )
Very existed attending → https://www.youtube.com/watch?v=pIbFhLfzcW0