gemini mcp list reports Google first-party MCP servers as "Disconnected" due to unsupported ping() method

[kweinmeister]

What happened?

gemini mcp list reports Google first-party MCP servers (Cloud Run, GKE, Developer Knowledge) as ✗ Disconnected, even though they connect successfully and all tools are discoverable.

Reproduction:

mkdir -p /tmp/gemini-test/.gemini
cat > /tmp/gemini-test/.gemini/settings.json << 'EOF'
{
  "mcpServers": {
    "cloud-run": {
      "httpUrl": "https://run.googleapis.com/mcp",
      "authProviderType": "google_credentials",
      "oauth": { "scopes": ["https://www.googleapis.com/auth/cloud-platform"] }
    }
  }
}
EOF

HOME=/tmp/gemini-test gemini mcp list

Output:

Configured MCP servers:

✗ cloud-run: https://run.googleapis.com/mcp (http) - Disconnected

But the server is fully functional. Using the MCP SDK directly:

const transport = new StreamableHTTPClientTransport(
  new URL('https://run.googleapis.com/mcp'), { requestInit: { headers } }
);
const client = new Client({ name: 'test', version: '1.0' });

await client.connect(transport, { timeout: 5000 });  // ✅ succeeds (152ms)
await client.ping();                                   // ❌ McpError -32601: Method not supported
await client.listTools();                              // ✅ succeeds (5 tools returned)

Root cause: testMCPConnection() in list.ts calls client.ping() after client.connect(). Google's MCP servers return -32601: Method not supported for ping, and the catch block reports DISCONNECTED:

// list.ts lines 129-141
try {
  await client.connect(transport, { timeout: 5000 }); // ✅ succeeds
  await client.ping();                                  // ❌ -32601
  await client.close();
  return MCPServerStatus.CONNECTED;
} catch {
  await transport.close();
  return MCPServerStatus.DISCONNECTED;  // ← false negative
}

Notably, connectToMcpServer() in mcp-client.ts — the code path used when Gemini CLI actually connects to MCP servers for tool discovery — does not call ping(). It connects and proceeds directly to tool discovery, which works perfectly with these servers. This means the diagnostic command (gemini mcp list) reports servers as broken that the CLI itself has no trouble using.

What did you expect to happen?

gemini mcp list should report the server as ✓ Connected since the MCP initialize handshake succeeds and tools are discoverable. The ping method is optional per the MCP spec — a server shouldn't be marked Disconnected just because it doesn't implement ping.

Client information

Client Information

Gemini CLI version: 0.38.1
Platform: macOS (arm64)
Node.js: v25.9.0

Login information

Google ADC (gcloud auth application-default login). Using authProviderType: google_credentials in the server config, which uses GoogleCredentialProvider to obtain Bearer tokens via google-auth-library.

Anything else we need to know?

Affected servers

All Google first-party MCP servers using the ESF StatelessServer backend:

• https://run.googleapis.com/mcp (Cloud Run)
• https://container.googleapis.com/mcp (GKE)
• https://developerknowledge.googleapis.com/mcp (Developer Knowledge)

Suggested fix

Make ping() optional in testMCPConnection(). A successful connect() (which completes the MCP initialize handshake) is sufficient proof of connectivity:

 try {
   await client.connect(transport, { timeout: 5000 });
-  await client.ping();
+  try {
+    await client.ping();
+  } catch {
+    // ping is optional per MCP spec — some servers (e.g. Google first-party)
+    // don't implement it. A successful connect() is sufficient.
+  }
   await client.close();
   return MCPServerStatus.CONNECTED;
 } catch {

Secondary: timeout discrepancy

testMCPConnection() uses a hardcoded 5-second timeout ({ timeout: 5000 }), while connectToMcpServer() in mcp-client.ts uses MCP_DEFAULT_TIMEOUT_MSEC (10 minutes). This could cause additional false "Disconnected" reports for slower-starting servers that the CLI would connect to successfully during normal use.

[jasonmatthewsuhari]

Hi, I've opened a fix for this in #25619.

gemini mcp list no longer falsely reports Google first-party MCP servers as disconnected just because they don’t implement ping(). A successful MCP connection now counts as connected when ping() specifically fails with MethodNotFound, and the command also uses the shared MCP default timeout instead of a hardcoded 5-second timeout.

Reproduced:

Resolved: