From 66dcc84d51bed88cbfb608b9dc6800a8edd32b3c Mon Sep 17 00:00:00 2001 From: Igor Soarez Date: Fri, 25 Sep 2026 16:42:26 +0300 Subject: ship the pi side we actually run, not a different arrangement The README told pi users to install pi-chrome directly and run /chrome authorize every session. That is not how this is used: pi reaches the same MCP server through pi-mcp-adapter, with pi's own pi-chrome switched off, which is why nobody types /chrome authorize. pi/browser-gate.ts is that setup's missing piece, generalised from the one in use: it answers pi-mcp-adapter's approval broker for one server, asking once per session instead of once per call (the adapter's own grant only covers identical arguments, so for a browser it asks nearly every time). /browser authorize, /browser revoke, and PI_BROWSER_AUTHORIZE for headless runs. approveTools stays on in mcp.json as the backstop if the gate does not load. The README now leads with that: install the adapter, register the server in mcp.json, copy the gate. Installing pi-chrome in pi is kept as the alternative, with what it costs - two definitions of the browser, /chrome authorize per session, and the trap of loading the extension twice. Tested on an isolated pi config against a stand-in browser: with PI_BROWSER_AUTHORIZE the call reaches the browser, without it the gate denies it. --- mcp/package.json | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 mcp/package.json (limited to 'mcp/package.json') diff --git a/mcp/package.json b/mcp/package.json new file mode 100644 index 0000000..8fddfa3 --- /dev/null +++ b/mcp/package.json @@ -0,0 +1,13 @@ +{ + "name": "pi-chrome-mcp", + "version": "0.1.0", + "description": "An MCP server for the Chrome you are already signed into, built on pi-chrome's tools.", + "license": "MIT", + "type": "module", + "dependencies": { + "@modelcontextprotocol/sdk": "1.30.0", + "jiti": "2.7.0", + "pi-chrome": "0.15.51", + "typebox": "1.3.7" + } +} -- cgit v1.2.3