pi: native MCP instead of pi-mcp-adapter

pi 0.99+ ships MCP as a built-in, and the adapter suppresses it. The gate moves
from the adapter's approval event, which the built-in never emits, to pi's own
tool_call hook on mcp__<server>__*, which every call passes through, codemode
included. approveTools went with the adapter, so nothing backs the gate up: a
decision it cannot reach now denies rather than throws. server.mjs also treats
a client named plain "pi" as pi, which is how the built-in introduces itself.

From change request 562974, filed from the work laptop.

1 files changed, 3 insertions, 3 deletions

diff --git a/mcp/server.mjs b/mcp/server.mjs
index 3554767..9c3bea4 100755
--- a/mcp/server.mjs
+++ b/mcp/server.mjs
@@ -255,8 +255,8 @@ async function instructionsWith(otherTools) {
 }
 const OTHER_BROWSER_TOOLS = process.env.PI_CHROME_OTHER_BROWSER_TOOLS?.trim();
 const instructions = await instructionsWith(OTHER_BROWSER_TOOLS);
-// pi-mcp-adapter introduces itself as pi-mcp-<server name>; in pi, the other browser's tools are
-// pi's own, not another MCP server's.
+// pi's built-in MCP support introduces itself as pi, and pi-mcp-adapter as pi-mcp-<server name>;
+// in pi, the other browser's tools are pi's own, not another MCP server's.
 const piInstructions = OTHER_BROWSER_TOOLS ? await instructionsWith("browser_*") : instructions;
 
 // --- MCP --------------------------------------------------------------------------------------
@@ -533,7 +533,7 @@ async function serveHttp() {
 			enableDnsRebindingProtection: true,
 			allowedHosts: [`${HTTP.host}:${HTTP.port}`],
 		});
-		conn.server = makeServer(conn, clientName.startsWith("pi-mcp") ? piInstructions : instructions);
+		conn.server = makeServer(conn, (clientName === "pi" || clientName.startsWith("pi-mcp")) ? piInstructions : instructions);
 		await conn.server.connect(conn.transport);
 		if (id) {
 			conn.transport._webStandardTransport._initialized = true;