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

181–190 of 200 posts

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

#181

Post by michaelmior »

ricardobeat wrote: post #151
miguelspizza wrote: post #148

Earlier quoted context omitted.

Again, that's up to the website owner. They can give the model anywhere from no access to full access to the client side api. > The agent should be treated as an untrusted user in your client, given restricted privileges scoped to only the exact access they need to perform a given task I agree, this is exactly what MCP-B does

The data you give it can be shared with any other website, at the agent's discretion . Some of it might be safe to share with the user, but not with third parties; at a minimum this should request permission when trying to share data between different websites/servers.

> 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 suppose you could have an agent that tracks data flow in some way, but that's beyond the scope of MCP.

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

#182

Post by michaelmior »

tehryanx wrote: post #171
miguelspizza wrote: post #166

Earlier quoted context omitted.

Ah I see. Yes this is a concern, but this issue is actually not unique to MCP-B and is just a generally issue with agentic workflows that rely on a dynamic toolset from 3p vendors. (which any MCP server local or remote has the ability to be) > With MCP-B, isn't it just automatically provided with whatever credentials are already stored in cookies/etc for a given MCP-B enabled app? Not exactly, MCP-B just allows your…

I do think the threat model here is a bit unique though. If I'm running two MCP servers on my machine, I'm the one that installed them, I'm the one that assigned what permissions they have in my environment, and I'm the one that explicitly decided what level of access to give them within whatever resource they're accessing. That gives me reasonably strong control over, or at least full knowledge of, what data can be…

> 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.

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

#183

Post by mupuff1234 »

tracerbulletx wrote: post #173
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?

It's pretty much standardizing on a couple endpoints for providing a list of resources/actions/prompt templates and calling to fetch those resources/actions/templates and feed them to the model context. It's really kind of trivial, but it's nice there's a standard I guess so you can write a service that anyone can use in their favorite client.

I think that also known by another word - "documentation".

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

#185

Post by ActorNightly »

johschmitz wrote: post #141
ActorNightly wrote: post #89

Earlier quoted context omitted.

The whole point is that you shouldn't have to worry about implementation. AI should do it for you.

At the end of the day you often need to consider the energy efficiency of a system which is also reflected in the cost of operating it. For use cases where this is relevant the suggested MCP approach potentially offers large benefits compared to what's probably meant here by "AI". However, the disadvantages of public access discussed in other threads need to be considered as well, therefore, I expected this only to b…

Once we have the thing working, optimization can come later.

Also MCP is not really optimal. Every prompt in a sequence of chat gets an injection of MCP capabilities. Its just simply not scalable with lots and lots of MCP servers. Not to mention the protocol changes every month and breaks things.

Furthermore, you can already do MCP like behavior, in a better way, on pretty much any model by basically writing a wrapper around the chatbot and using a system prompt which guides it to print specific text (like "action:load file"), and the wrapper can detect that text and inject the prompt. I have an agent that runs at home using this, which I also use to self improve and define actions on the fly - I ask it to write code, it writes code, then the wrapper takes that code and makes it part of the library and appends it to the system prompt on every new chat.

The point is that we should be able to take the latter, and build something that can do this automatically. Once we have the full loop complete, then we can optimize it down to minimum compute.

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

#186

Post by ActorNightly »

JambalayaJimbo wrote: post #172
ActorNightly wrote: post #89

Earlier quoted context omitted.

The whole point is that you shouldn't have to worry about implementation. AI should do it for you.

AI is a very leaky abstraction. You will always be worried

LLMS are leaky abstractions. LLMs configured in wrappers can be made to be mostly correct.

For example, define range of input, appropriate output, ask LLM to write code, automatically run that code against the range of input, evaluate the output, ask llm to fix any issues where the input doesn't match the output.

That whole process can be made faster without the need for huge models. The model doesn't need to get trained on everything CS, because it doesn't need to get the code correct on the first try, it just needs to be trained on enough code to understand how something affects the output and iterate on that. I.e basically making the model do smart guided search. It was done with Mu Zero with great success, not sure why nobody is focusing on this now.

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

#187

Post by xnx »

SquareWheel wrote: post #116
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.

Isn't RSS a smashing success? I changed readers after Google Reader died, but otherwise, my feeds have been working seamlessly for nearly 20 years. I rarely meet a site with updates that doesn't support RSS.

Twitter, Instagram, TikTok, craigslist, eBay, Amazon, etc.

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

#189

Post by tehryanx »

michaelmior wrote: post #182
tehryanx wrote: post #171

Earlier quoted context omitted.

I do think the threat model here is a bit unique though. If I'm running two MCP servers on my machine, I'm the one that installed them, I'm the one that assigned what permissions they have in my environment, and I'm the one that explicitly decided what level of access to give them within whatever resource they're accessing. That gives me reasonably strong control over, or at least full knowledge of, what data can be…

> 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.

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

#190

Post by tehryanx »

michaelmior wrote: post #181
ricardobeat wrote: post #151

Earlier quoted context omitted.

The data you give it can be shared with any other website, at the agent's discretion . Some of it might be safe to share with the user, but not with third parties; at a minimum this should request permission when trying to share data between different websites/servers.

> 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 a way to solve for that.

Especially in this context, where decades have been spent building and improving same origin policy controls. The entire web has been built around the expectation that those controls prevent cross origin data access.

I also don't even think it's that difficult to solve. For one, data in the context window doesn't have to be a string, it can be an array of objects that contain the origin they were pulled from as metadata. Then you can provide selective content to different MCP-B interfaces depending on their origins. That would live in the protocol layer that would help significantly.

Post reply on HN