This looks promising - thanks for open-sourcing this. This addresses the gap that most work happens in browsers while MCP assumes that work happens with AI clients.
I have a fundamental question though: how is it different from directly connecting my web app's JS APIs with tool calling functions and talking directly with a LLM server with tool-call support?
Is it the same thing, but with a protocol? or am I missing the bigger picture?
Could all of this be replaced simply by publishing OpenAPI (Swagger) spec and using universal swagger mcp client ??? This basically leaves up to the user to establish authenticated session manually. Assuming claude is smart enough to pick up API key from prompt/config, and can use swagger based api client, wouldnt that be the same?
This MCP stuff is leading dev down the wrong path. We should be focusing on llms using self discovery to figure out information.
We should be focusing on llms using self discovery to figure out information. Can you expand? What does that mean, and why is the right (or better) path
Manually coding things is not how we get better AI. For AI to be truly useful in the area of figuring things out (i.e actually reasoning), one of the core components of a model would be building its own knowledge trees across multi modal information. So when you ask a model to do something, it should figure out how to do it on its own.
The contributions for the Github project is quite intriguing: https://github.com/MiguelsPizza/WebMCP/graphs/contributors MiguelsPizza | 3 commits | 89++ | 410-- claude | 2 commits | 31,799++ | 0--
I did some git history re-visioning when I closed sourced the extension for a bit. So these are not super accurate. Claude code did write about 85% of the code though.
How can you figure out that percentage? The commit logs?
This gave me an idea. Instead of writing/maintaining servers and whatnot, why not just open the browser and give [$LLM] access to the development port and let it rip using the puppeteer protocol?
This looks promising - thanks for open-sourcing this. This addresses the gap that most work happens in browsers while MCP assumes that work happens with AI clients. I have a fundamental question though: how is it different from directly connecting my web app's JS APIs with tool calling functions and talking directly with a LLM server with tool-call support? Is it the same thing, but with a protocol? or am I missing t…
Np thanks for reading! The difference is with MCP-B you don't have to integrate or maintain any AI chat functionality yourself.
It's a protocol which allows the user to bring their own model to interact with the tools on your website
So if I'm using claude code and developing a web app, its running on localhost:3000, can I use claude code to basically get ui information, browser console logs and other web dev feedback and useful information? Cause I installed it and added that file but all I see is the 55 tools and 6 apis when i open the browser extension. not the stuff i need. and i also installed the extension tools i think it was called.
Ah maybe I should make that more clear. The web app is an example of a MCP-B server and the extension is a client. When you visit MCP-b.ai with the extension, it's tools will register
I still don't understand MCP. If according to all the AI companies soon AI will replace devs than why bother with MCP?
Lock-in. LLMs are today's hammer: everything looks like a nail now.
LLMs are super useful for certain tasks (generating boilerplate code, generating tests, providing examples for API usage, summarising etc.), but the demo to me just illustrates a solution in desperate search for a problem. "Create A TODO" using a chatbot? That's an example gone wrong in so many ways and goes to show what happens if you start with a solution and work your way backwards to a use case without actually thinking about it yourself...
From the blog post: "The Auth problem At this point, the auth issues with MCP are well known. OAuth2.1 is great, but we are basically trying to re-invent auth for agents that act on behalf of the user. This is a good long term goal, but we are quickly realizing that LLM sessions with no distinguishable credentials of their own are difficult to authorize and will require a complete re-imagining of our authorization sy…
Not sure I understand. The model has no more access than the user does. proper security implementation still lies with the website owner
I did some git history re-visioning when I closed sourced the extension for a bit. So these are not super accurate. Claude code did write about 85% of the code though.
How can you figure out that percentage? The commit logs?
More likely a wild guess. The number is also probably higher...