Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP-B: A Protocol for AI Browser Automation

mcp-b.ai

Post reply on HN
Print view View original

191–200 of 200 posts

Re: MCP-B: A Protocol for AI Browser Automation

#191

Post by miguelspizza »

tehryanx wrote: post #174
owebmaster wrote: post #168

Earlier quoted context omitted.

a sandboxed user is not an untrusted user of the client but an unstrusted user of the host, that is why the client is sandboxed.

sandboxing is a general term for actor isolation, and its context agnostic. For example, when you use the sandbox attribute on an iframe in a web application, it's not the user that's untrusted, it's some other user that's attempting to trigger actions in your client.

I've thought more about this and I think the only way to make completely sure that sensitive data does not get leaked is by making sure it never makes it into the models context in the first place.

The issue is even if the MCP-B extension makes it so the user has to give confirmation when the agent want's to call a tool on a new domain after interacting with another domain, there is no clear way to determine if a website is malicious or not.

A solution to this might be to give server owners the ability to write the restricted data to extension storage on tool response instead of returning it to the models context. Instead, a reference to this location in extension storage get's passed to the model. The model then has the ability to "paste" this value into other website via tool call without ever actually seeing the value itself.

That way, MCP-B can put lots of warnings and popups when this value is requested to be shared.

Any thoughts?

Re: MCP-B: A Protocol for AI Browser Automation

#193

Post by miguelspizza »

mhio wrote: post #43
miguelspizza wrote: post #7

Earlier quoted context omitted.

Similar but also very different. Playwright and Selenium are browser automation frameworks. There is a Playwright-MCP server which let's your agent use Playwright for browser automation. MCP-B is a different approach. Website owners create MCP servers `inside` their websites, and MCP-B clients are either injected by browser extensions or included in the websites JS. Instead of visual parsing like Playwright, you get…

A playright-mcp server, or any bidi browser automation, should be equally capable of discovering/injecting and calling the same client JS exposed MCP-B site API? It's like an OpenAPI definition but for JS/MCP? (outside of the extension to interact with that definition)

Sure they can inject clients, but that's really only beneficials for developers. doing it via browser extension means regular people can use it.

> It's like an OpenAPI definition but for JS/MCP?

Sortof. It's a true MCP server which you can use to expose existing (or new functionality on your webapp to the client)

Re: MCP-B: A Protocol for AI Browser Automation

#194

Post by volkandkaya »

ActorNightly wrote: post #93
ashwinsundar wrote: post #70

Earlier quoted context omitted.

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.

Doesn't sound like it conflicts with MCP-B, in theory they go well together.

- AI checks if a MCP tool exists - If it does not exist, AI can handle it, then send feature request to add new MCP tool

By doing the above it will be more likely to do the correct action and save a lot of tokens

Re: MCP-B: A Protocol for AI Browser Automation

#195

Post by volkandkaya »

mupuff1234 wrote: post #75

I still don't understand MCP. If according to all the AI companies soon AI will replace devs than why bother with MCP?

Either AI will replace everyone and it doesn't matter what we did up until that point or it won't and building these systems will be useful.

What is your recommendation for companies? To take it to the extreme are you saying fire everyone and wait for AI?

Re: MCP-B: A Protocol for AI Browser Automation

#197

Post by volkandkaya »

cryptozeus wrote: post #79

can someone explain like I am five?

Example:

You have google docs and CMS open in 2 tabs

1. Ask to take your google doc and add it to the CMS

2. MCP tool takes the data from Google docs

3. MCP tool to convert text to CMS item

4. MCP tool to insert that CMS item

With the above you can view unique UIs for each stage as well, such as generating a table with CMS fields before accepting.

Re: MCP-B: A Protocol for AI Browser Automation

#198

Post by pyuser583 »

TeMPOraL wrote: post #120
jacquesm wrote: post #113

Prediction: this will go the same way as RSS. Companies don't like you to be in control of how you use their data.

Indeed. Though I guess a better example would be: it'll go the same way as REST APIs (which happen to be fundamentally the same thing as MCP anyway). Remember the time when REST was the new hot thing, everyone started doing API-first design, and people thought it'll empower people by letting programs navigate services for them programmatically? Remember when "mashups" were the future? It all died before it could come…

How is MCP doing the same as REST?

I’m a REST developer learning MCP, and most of my effort is spent finding anything new to learn.

So I’m not suprised by this statement, but I’m a bit startled.

How are they the same thing?

Re: MCP-B: A Protocol for AI Browser Automation

#199

Post by michaelmior »

tehryanx wrote: post #189
michaelmior wrote: post #182

Earlier quoted context omitted.

> with the only restrictions being up to the app owner rather than it being up to me. I don't see any reason sites using MCP-B couldn't have settings to restrict access to certain data based on user configuration.

Sure, but the leak risk is happening in a place outside the site's control. If the purpose of the MCP-B tool on mail.com is to summarize your email, then the site needs to allow the agent to pull your email into the context window. Once it's in the context window it's available to any other MCP-B enabled site that can convince the agent to send it along.

Sure. My point was that you can limit what the agent is allowed to access at the very least. The fact that you need to trust the agent not to share the info is a n important, but separate concern.

Re: MCP-B: A Protocol for AI Browser Automation

#200

Post by michaelmior »

tehryanx wrote: post #190
michaelmior wrote: post #181

Earlier quoted context omitted.

> at a minimum this should request permission when trying to share data between different websites/servers. I don't see how you could possibly implement such a thing reliably. Do you scan all the parameters to other tool calls from different servers looking for something in a previous response? Even if you do that, the LLM could derive something private from a previous response that couldn't easily be detected. I sup…

I don't think it is beyond the scope of MCP. Browsers have controls to prevent cross-origin data exposures, and this protocol is designed to bridge origins across a context that they all have access to. It's breaking the existing isolation mechanism. If you're building a system that breaks the existing security controls of the environment it's running in I think you have an architectural responsibility to figure out…

The agent is probably not operating in the browser though. And current LLMs work with (tokenized) strings, not objects.
Post reply on HN