Add HTTP/SSE transport support to eliminate per-session process overhead

[ElliotDrel]

Problem

Every Claude Code session (or any MCP client) spawns its own dedicated process chain for this server:

claude session 1 → cmd → node(npx) → node(google-tools-mcp)
claude session 2 → cmd → node(npx) → node(google-tools-mcp)
claude session N → cmd → node(npx) → node(google-tools-mcp)

This means 3 Node.js processes per client session. With multiple CC windows open (which is common), this adds up fast — memory and CPU multiply linearly with session count.

Root Cause

dist/index.js hardcodes transportType: 'stdio' with no CLI flag to override it:

await server.start({ transportType: 'stdio' });

Solution

FastMCP already supports httpStream transport out of the box. Adding two CLI flags (--transport and --port) is all that's needed to expose it.

When running in HTTP mode, a single persistent server process handles all client sessions — zero per-session spawning:

[google-tools-mcp --transport http --port 3000]  ← claude session 1
                                                  ← claude session 2
                                                  ← claude session N

Claude Code supports type: "http" MCP servers natively, so no client changes are needed — just update the config to point at http://localhost:3000/mcp.

Auth / State

Auth is already disk-based (~/.config/google-tools-mcp/token.json), so sharing one server across multiple clients works fine. Using stateless: false (FastMCP default) keeps the cached auth clients alive across requests.

Proposed Change

Minimal diff to dist/index.js:

+// --- Parse CLI flags ---
+let transport = 'stdio';
+let port = 3000;
+for (let i = 2; i < process.argv.length; i++) {
+    if (process.argv[i] === '--transport' && process.argv[i + 1]) {
+        transport = process.argv[++i];
+    } else if (process.argv[i] === '--port' && process.argv[i + 1]) {
+        port = parseInt(process.argv[++i], 10);
+    }
+}

 // --- Setup subcommand ---
 if (process.argv[2] === 'setup') {

-    await server.start({ transportType: 'stdio' });
-    logger.info('MCP Server running using stdio. Awaiting client connection...');
+    if (transport === 'http') {
+        await server.start({ transportType: 'httpStream', httpStream: { port, stateless: false } });
+        logger.info(`MCP Server running on http://localhost:${port}/mcp (HTTP/SSE). Awaiting connections...`);
+    } else {
+        await server.start({ transportType: 'stdio' });
+        logger.info('MCP Server running using stdio. Awaiting client connection...');
+    }

Backwards compatible — stdio remains the default.

Usage After Fix

# Start persistent HTTP server (add to login startup)
npx google-tools-mcp --transport http --port 3000

// Claude Code config (~/.claude.json)
"google": {
  "type": "http",
  "url": "http://localhost:3000/mcp"
}

Happy to open a PR with this change.

[ElliotDrel]

Root Cause Analysis

After investigation, we've identified that the zombie process problem is not about needing HTTP/SSE transport. The real root cause is in the MCP SDK itself.

The Issue

The 's method only registers and listeners on stdin — it never registers or listeners. When Claude Code (or any client) drops the stdin pipe, the server has no way to detect the disconnection and continues running forever, becoming a zombie process.

FastMCP delegates entirely to this transport and adds no close/end listeners of its own, so the problem propagates up to google-tools-mcp.

The Fix

The upstream fix is already in flight:

• PR #2003 on modelcontextprotocol/typescript-sdk addresses the missing listeners in

The correct fix chain is:

1. SDK PR #2003 merges
2. FastMCP upgrades its dependency
3. google-tools-mcp upgrades its FastMCP dependency
4. Problem solved automatically — no changes needed in this repository

Additional Work

A separate issue and PR are being filed on FastMCP directly to add a belt-and-suspenders fix at the framework level so they can handle server cleanup more robustly.

Conclusion

HTTP transport support (the original request) is not needed to solve the zombie process problem. The upstream MCP SDK fix will resolve this issue automatically. Closing this line of inquiry in favor of the upstream fixes.