Live data from Hacker News

MCP-B: A Protocol for AI Browser Automation

mcp-b.ai

161–170 of 200 posts

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

#161
post #160

Earlier quoted context omitted.

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…

> and people thought it'll empower people by letting programs navigate services for them programmatically? I don’t think that concept died because of nefarious business-related reasons but rather that building true HATEOAS APIs is hard and the utility of “automatically navigable APIs” is quite limited. It’s a neat trick to point a generic API client at an API and crawl it automatically, but hardly anyone consumes API…

Right. But there are hardly any useful APIs you can just use, with only an account on a service and willingness to read the docs. Everyone is exposing as little functionality as possible, and even that only under special conditions that make them useless for regular people. APIs are primarily a way for businesses to partner these days.

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

#162

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.

ah this is a great point, I will add it to the road map

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

#166

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

I'm not following. Say I have your browser extension running, and it's interfacing with an MCP-B enabled banking application using my session to access my data in that app. I also have it connected to MCP-B enabled rogue web app that I mistakenly trust. My browser has an entire architecture built around preventing data from crossing between those two origins, but what's stopping a malicious instruction from the rogue…

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 extension agent to call functions that the website owner explicitly exposes. The client itself is not given an credentials like traditional MCP.

> If I load an MCP-B enabled app, does the agent automatically have access or do I have to configure it somewhere?

Theres more in the blog post but how much access the agent has and how much human approval is needed to grant this access is completely up to the website creator.

FWIW your points are valid and MCP-B should enforce some guardrails when any domain shift happens via elicitation: https://modelcontextprotocol.io/specification/draft/client/e...

I'll add it to the road map. Thanks for bringing it up!

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

#167

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

Maybe, but the market structure has inverted and the big guys now want to be in the intelligence layer, not content. (Content is being commoditized.)

Google can still sell ads as long as they own the eyeballs and the intelligence that’s engaging them.

Google did not want you using RSS because it cut out Google Search.

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

#168

Earlier quoted context omitted.

> The agent should be treated as an untrusted user in your client, An untrusted user in a client is a hacker/invasor, not an agent.

an untrusted, but permitted, user is why sandboxes exist. There are plenty of times you want to allow an untrusted user to have capabilities in a system, that's why you restrict those capabilities.

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.

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

#169
post #119

Earlier quoted context omitted.

Oh no it's not done through that account. Seems to be some sort of ephemeral account scoped to the repo.

What's in authour/commit meta is orthogonal to which github.com account you are actually using. Anyone can commit as anyone as long as you have any way to push and if you want better than that you need signed commits. There are no "ephemeral accounts" in play here.

Right, that was my intended meaning of ephemeral accounts.

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

#170
post #135

Earlier quoted context omitted.

If you ask it to commit it'll sign itself as the author.

I don’t understand why we are personifying AI. They’re inanimate tools. My commits don’t credit my keyboard.

Might be less personification and more a figure of speech.
Post reply on HN