Antigravity CLI failed to initiate connection to bugzilla-mcp

[simonlm]

Summary

When starting the Antigravity CLI (agy) or opening the plugins/MCP interface (/plugins), bugzilla-mcp-server configured Model Context Protocol (MCP) server failed to initialize:

bugzilla-mcp-server failed during tool discovery with:
failed to get tools: calling "tools/list": request _meta is missing or has malformed required fields: io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities

This failure was traced to a protocol-level version mismatch introduced by modern MCP specifications (SEP-2575 / revision 2026-07-28) implemented in Antigravity's Go MCP client.

Root Cause Analysis:
Background: MCP Protocol Evolution
In recent updates to the Model Context Protocol (MCP draft 2026-07-28 / SEP-2575), the protocol introduced a transition toward a stateless request model:

• Upfront Discovery (server/discover): Instead of relying exclusively on a stateful initialize → notifications/initialized sequence, clients can issue an upfront server/discover RPC to inspect supported protocol versions and capabilities.
• Mandatory Request Metadata (params._meta): In stateless mode, requests must carry self-describing protocol metadata inside _meta:
  • io.modelcontextprotocol/protocolVersion
  • io.modelcontextprotocol/clientCapabilities
• Fallback Standard: If a server does not support server/discover, the standard specification expects the server to respond with a standard JSON-RPC error code -32601 (Method not found). The client then falls back to the legacy stateful initialize handshake.

Client Behavior (agy)
Antigravity CLI is compiled against the official Go MCP SDK (github.com/modelcontextprotocol/go-sdk v1.7.0+). When establishing a stdio session, agy's client initiates connection by sending a server/discover probe with protocol version 2026-07-28:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "server/discover",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": { ... },
      "io.modelcontextprotocol/clientInfo": { "name": "antigravity-client", "version": "v1.0.0" }
    }
  }
}

Breakdown of Server Failures:
Why bugzilla-mcp-server Failed

• Binary: /usr/bin/bugwarden (v0.5.0), built with rmcp 3.1.3.
• Implementation: Contains partial, experimental support for server/discover.
• Failure Chain:
  1. agy sent server/discover (request id: 1).
  2. bugwarden answered with -32022 Unsupported protocol version, reporting supported versions ["2024-11-05", "2025-03-26", "2025-06-18", "2025-11-25"].
  3. Receiving server/discover flagged bugwarden's internal session state as using the new stateless protocol mode, which enforces mandatory _meta validation on all subsequent requests.
  4. agy, having negotiated down to 2025-11-25, proceeded with the standard stateful initialization (initialize -> notifications/initialized).
  5. agy then sent tools/list with standard empty parameters (params: {}).
  6. bugwarden evaluated the request under stateless rules and rejected it with code -32602 (Invalid params):
     request _meta is missing or has malformed required fields: io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities.

Architecture of the Fix:
Per the MCP specification:

• If a server responds to server/discover with JSON-RPC error code -32601 (Method not found), the client automatically falls back to the legacy stateful initialize handshake without enabling stateless metadata requirements.
• By intercepting server/discover before it reaches the underlying binaries:
  • bugwarden never enters stateless mode, remaining in standard stateful mode where tools/list with params: {} succeeds.

Steps to reproduce
Antigravity CLI MCP configuration file ~/.gemini/config/mcp_config.json:
{ "mcpServers": { "bugzilla-mcp-server": { "command": "/usr/bin/bugwarden", "args": [ "--bugzilla-server", "https://bugzilla.suse.com", "--transport", "stdio", "--policy", "/etc/bugwarden/policy.toml" ], "env": { "BUGZILLA_API_KEY": "xxxxxxx" } } } }

Start agy and run /mcp list

Expected behaviour
agy can correctly connect to bugzilla-mcp:

MCP Servers
Plugins (~/.gemini/config/plugins)
> ✓ bugzilla-mcp-server Tools: add_attachment, add_cc_to_bug, add_comment, assign_bug, bug_comments, +15 more

Actual behaviour
Error: bugzilla-mcp-server

✗ bugzilla-mcp-server  error: failed to get tools: calling "tools/list": request _meta is missing or has malformed required fields:
io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities

mtui version
mtui 26.2.1 (release, x86_64-unknown-linux-gnu)
Antigravity CLI 1.1.25

Environment
OS: openSUSE Leap 16.0
Kernel: 6.12.0-160000.37-default
Platform: x86_64

[plusky]

Thanks for the precise trace — it reproduces on main too, not only on 0.5.0, and the root cause is one step earlier than a version mismatch.

rmcp 3.1.4 (and 3.2.0, and upstream main today) decides a stdio session's lifecycle from the first non-ping frame: anything that is not initialize — your server/discover probe included — flips a sticky, pub(crate) "every request must carry _meta" flag on the session before the handler has even decided whether the declared version is supported, and nothing ever clears it, initialize included. That is why step 6 fails: the -32022 was correct, the initialize was served, but the session was already committed. Any client that probes and then opens an ordinary session hits it, served or refused probe alike; and a probe with no _meta at all ended the process.

Two things follow from that for you:

• main already serves 2026-07-28 (since 80dda84, unreleased), so against the next release agy's probe succeeds and it stays on the handshake-free lifecycle — your chain would not have fallen back to initialize at all. That only holds until the Go SDK adopts a revision bugwarden does not yet list.
• fix(stdio): a probe must not pick the lifecycle #268 fixes the actual defect: over stdio bugwarden now answers server/discover itself in the transport, exactly as rmcp would, and rmcp learns the lifecycle from the first frame that is a commitment (initialize, or a _meta-carrying request). Your exact sequence — probe refused, legacy initialize, tools/list with params: {} — is now a binary-level test, so the fallback works whatever revision the client asks for. No client-side interception needed once it lands; your proxy answering -32601 remains a valid workaround for 0.5.0.