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.

1 files changed, 13 insertions, 0 deletions

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"
+	}
+}