[FEAT] Official MCP HTTP endpoint (Playwright MCP / Chrome DevTools MCP) on linuxserver/chrome

Open
#19 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, docker-compose, playwright

Research direction

Start with issue #11 and the existing CHROME_CLI remote-debugging behavior, including the non-default user-data directory requirement. Then review the proposed docker-compose services and decide whether the supported result should be a docker-mod or README example. Done means an official, documented MCP HTTP endpoint is available alongside the existing Selkies UI without adding classic VNC.

Written by the indexing model from the issue text.

Description

no-issue-activity
Is this a new feature request?
  • I have searched the existing issues
Wanted change

Document or ship an official way to expose MCP (Model Context Protocol) next to the existing Selkies GUI on linuxserver/chrome.

Specifically:

  1. Keep Google Chrome in the desktop container (this image is already the right shape).
  2. Expose an HTTP MCP endpoint agents can call, e.g. Playwright MCP or Chrome DevTools MCP, something like http://host:8931/mcp.
  3. Either:
    • an official docker-mod that starts MCP against this Chrome via CDP, or
    • README + compose example: CHROME_CLI CDP + sidecar (socat because Chrome still binds DevTools to 127.0.0.1) + npx @playwright/mcp --host 0.0.0.0 --port 8931 --cdp-endpoint http://127.0.0.1:9224.

This is not a request to add classic VNC 5900. The Selkies UI on :3001 is fine for humans. MCP is for agents.

Reason for change

I searched this repo (all 8 issues) and linuxserver/docker-chromium. Nobody used the word MCP.

Closest threads are CDP only:

  • This repo: #11 (CHROME_CLI remote debugging; Chrome 136+ needs non-default --user-data-dir; --remote-debugging-address ignored, binds 127.0.0.1)
  • Chromium: #71, #75 (CDP), #16 (Puppeteer wsEndpoint), #30 (remote-debugging-port)

Agents cannot use CDP as MCP. Outbound MCP clients need Streamable HTTP. Community one-shots exist (Playwright Chromium + noVNC + MCP) but they are not this Google Chrome image.

Benefit: same linuxserver Chrome desktop we already run, plus a supported agent attach path, without a third-party fork.

Proposed code change

Document this (or ship it as a docker-mod):

services:
  chrome:
    image: lscr.io/linuxserver/chrome:latest
    environment:
      - CUSTOM_USER=abc
      - PASSWORD=abc
      - CHROME_CLI=--user-data-dir=/config/chrome-cdp --remote-debugging-port=9223
    ports:
      - "3001:3001"
      - "8931:8931"
    shm_size: "1gb"
    volumes:
      - ./config:/config
  chrome-proxy:
    image: alpine/socat:latest
    network_mode: "service:chrome"
    command: tcp-listen:9224,fork,reuseaddr,bind=0.0.0.0 tcp:127.0.0.1:9223
  playwright-mcp:
    image: mcr.microsoft.com/playwright/mcp
    network_mode: "service:chrome"
    init: true
    stdin_open: true
    command: --host 0.0.0.0 --port 8931 --cdp-endpoint http://127.0.0.1:9224

Human view: https://host:3001. Agent: http://host:8931/mcp.

Is MCP on the roadmap, or is CDP-only the intended attach surface?

Dominant language
Dockerfile
Stars
69
Forks
19
PR merge metrics
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Similar issues

More Backend & API Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.