Skip to content

Conversation

@viktormarinho
Copy link

No description provided.

@google-cla
Copy link

google-cla bot commented Oct 23, 2025

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@OrKoN
Copy link
Collaborator

OrKoN commented Oct 23, 2025

Thanks for the PR we do not plan to support HTTP right now because we do not have multi-session support that in my understanding would be required for the HTTP transport (and it looks like this PR does not add it). Could you please elaborate on your use case? Is it not solvable with an MCP proxy? Are you looking to manage multiple Chrome instances with a single MCP server? If you share your use case, it would help us prioritize supporting the HTTP transport. cc @natorion

@viktormarinho
Copy link
Author

Thanks for the PR we do not plan to support HTTP right now because we do not have multi-session support that in my understanding would be required for the HTTP transport (and it looks like this PR does not add it). Could you please elaborate on your use case? Is it not solvable with an MCP proxy? Are you looking to manage multiple Chrome instances with a single MCP server? If you share your use case, it would help us prioritize supporting the HTTP transport. cc @natorion

Yeah, exposing this MCP via http could be solved with a proxy that will adapt http to stdio.

I'm looking to run this on a container somewhere then access it via http. Managing multiple chrome instances would also be nice, since i would also probably want to make this multi tenant separating the sessions through some auth header, which i believe is also what you mean with the multi session support.

But i'm not sure what would be the ideal approach here. i've read on the --help that there is an option for me to connect to specify a remote chrome socket uri for connecting, so maybe i could also do something like running the multiple chrome instances somewhere else then having this single MCP server route people for the different sockets? idk.

With this setup that i've just sent you via pull request, i was able to run it locally with a http proxy tunnel on top of it and plug it on agents that i use on the web, that would not have access to my computer usually (since it's an arbitrary web server connecting to my chrome mcp). I also can just run two proxies i guess.

A use case of mine would be to provide people with an MCP server they can connect to an agent to look for improvement opportunities on a ecommerce page load, looking at the network tab, image/javascript loading priorities etc. This agent would be running remotely, being accessed via browser and require no local setup, being able to also edit code in some remote environment running a dev server. Just like something like https://replit.com/ works.

I got interested on running multiple chrome instances, though, if you think it makes sense i would like to implement it, seems that it would be useful for me.

@OrKoN
Copy link
Collaborator

OrKoN commented Oct 24, 2025

Yes, currently, one MCP server instance is tied to a single Chrome instance. With --browserUrl, --wsEndpoint options you can connect the MCP server instance to a browser running elsewhere (e.g., a cloud browser). If we were to add the HTTP transport support, we would need to:

  1. support MCP sessions https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#session-management
  2. have adequate security for the MCP server itself (https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning).
  3. have tests for the multi-session environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants