Expose the experimental CDP PWA domain (install/launch/uninstall) as tools

[LuHuangMSFT]

Is your feature request related to a problem? Please describe.

There is currently no way for an MCP client/agent to drive Progressive Web App lifecycle actions through chrome-devtools-mcp. The available tools reach page content (DOM, console, network, input), but installing/launching/uninstalling a PWA happens in the browser chrome (the omnibox install button, the app window), which is out of reach for the existing tools.

This blocks an entire class of automation and debugging use cases:

• Agents/tests that need to install a web app and verify OS integration (manifest id, display mode, file/protocol handlers, badging).
• Reproducing and debugging install-state-dependent behavior (e.g. APIs that only change in a standalone app window vs. a tab: display-mode media queries, windowControlsOverlay, launch handlers).
• End-to-end PWA flows without a manual user gesture on the native install prompt.

Chromium already implements the PWA CDP domain (install, uninstall, launch, launchFilesInApp, openCurrentPageInApp, getOsAppState, changeAppUserSettings) in chrome/browser/devtools/protocol/pwa_handler.cc. The capability exists at the protocol layer — it just isn't surfaced as MCP tools.

Describe the solution you'd like

Add a new opt-in tool category (e.g. --category-pwa, off by default like extensions/webmcp) that wraps the PWA CDP domain. Proposed tools:

• install_pwa — PWA.install (manifestId, optional installUrlOrBundleUrl)
• uninstall_pwa — PWA.uninstall
• launch_pwa — PWA.launch (opens the app window)
• open_current_page_in_app — PWA.openCurrentPageInApp
• get_os_app_state — PWA.getOsAppState (badge count, file handlers)
• install_current_page_as_pwa — convenience: reads the page manifest, derives the manifest id, installs (no manifestId argument needed)

Because PWA.* is browser-scoped, the tools open a browser-level CDP session (browser.target().createCDPSession()) rather than a page session.

Note on display mode: CDP installs default user_display_mode to kBrowser (they don't simulate the install dialog), so launched apps open as tabs. The tools expose an optional displayMode: "standalone" | "browser" that chains PWA.changeAppUserSettings after install to produce a real standalone app window.

I have a working local implementation of all of the above (single src/tools/pwa.ts module + category registration) and have verified the full install → launch → uninstall lifecycle against a Chromium-based build, confirmed via chrome://web-app-internals (InstalledWebApps 0→1→0, command log all kSuccess, latest_install_source: "devtools"). Happy to open a PR.

Describe alternatives you've considered

• Raw "send CDP command" escape hatch — a generic passthrough tool. Rejected: it sidesteps the curated, documented, schema-validated tool model the project intentionally uses.
• A separate standalone MCP server for PWA — duplicates the browser-connection plumbing this project already manages; worse UX (two servers, two connections).
• Driving the native omnibox install button via screenshots/coordinates — out of scope for CDP-based tooling and brittle/non-deterministic.

Additional context

• Domain reference: PWA.pdl in the DevTools protocol (third_party/blink/public/devtools_protocol/domains/PWA.pdl).
• PWA is an experimental CDP domain — I'd document that and the Chrome version it's validated against, per the contribution checklist (works on Chrome stable or version restriction documented).
• Open question for maintainers: preferred category name/flag, and whether to land tools incrementally behind chore: first then a feat: enable, per the feature-release checklist.

Questions before I send a PR

1. Are you open to a PWA tool category in principle, or is this out of scope?
2. Preferred category/flag naming?
3. Any Chrome-version policy concerns with an experimental domain I should address up front (min version, capability checks)?

[OrKoN]

Hi @LuHuangMSFT thanks for raising this feature request. We think it would be a great addition behind --category-pwa flag, off by default. Regarding the implementation, we should add a high-level Puppeteer API first: would you be interesting in sending PRs for Puppeteer? I am thinking something like this would be great to have in Puppeteer:

• await browser.installPWA() / await browser.uninstallPWA()
• await browser.launchPWA() -> Page
• await page.openInPWA() / await page.installAsPWA()

WDYT? After that it would be trivial to integrate it in the MCP server without the need for extra browser level sessions.

[LuHuangMSFT]

That sounds reasonable. I'll do some research to understand how everything works together, then try to contribute to Puppeteer.

without the need for extra browser level sessions

What's the crux here?

Update: I see - have Puppeteer manage CDP sessions.

[LuHuangMSFT]

Filed the upstream Puppeteer feature request as requested: puppeteer/puppeteer#15202 — proposes native browser.installPWA() / uninstallPWA() / launchPWA() → Page plus page.installAsPWA() / openInPWA(), following the installExtension precedent. Once that lands, I'll send the small MCP PR wiring these behind an off-by-default --category-pwa.