The Chameleon Edition - gemini-faf-mcp v2.4.0

TL;DR: gemini-faf-mcp now auto-selects its transport — stdio locally, Streamable HTTP on Cloud Run. Same binary, 12 tools, zero config. One binary that's a local MCP server and a hosted one, decided by its environment.

One Command, Both Modes

gemini-faf-mcp reads its environment and adapts. Run it locally and it speaks stdio — the transport uvx and MCP clients expect. Set a PORT (as Google Cloud Run does) and the same binary serves modern Streamable HTTP: stateless, JSON, no SSE. No flags. No second package. No config. The server decides.

uvx gemini-faf-mcp        →  stdio   (local / MCP client)
PORT=8080  →  python app  →  Streamable HTTP  (Cloud Run)

Twelve tools either way. Identical behavior. The only thing that changes is the door it answers.

Why a Chameleon

A chameleon doesn't change what it is — it changes how it meets its surroundings. Same here: one codebase, 12 tools, one main() shared by the console script and the container. What shifts is the transport, chosen by where it runs.

Under the hood, the entry point passes the transport explicitly (transport="stdio" when local) instead of leaning on a framework default. The payoff is real: a strict MCP client that used to stall mid-handshake now connects cleanly — initialize, tools/list, tools/call, every time.

Drop It Into Google Antigravity

Google's agentic IDE, Antigravity, reads one MCP config file — and it accepts both modes.

Local (stdio) — in ~/.gemini/config/mcp_config.json:

{
  "mcpServers": {
    "gemini-faf": { "command": "uvx", "args": ["gemini-faf-mcp"] }
  }
}

Hosted (Streamable HTTP) — same file, the running endpoint:

{
  "mcpServers": {
    "gemini-faf": { "serverUrl": "https://mcpaas.live/gemini/mcp/v1" }
  }
}

One gotcha: Antigravity expects serverUrl — not url, not httpUrl. The same config works in the Gemini CLI, which converges into the Antigravity CLI.