Building a ChatGPT ↔ Bob MCP Bridge: Phase (a)

ChatGPT and gptme are entirely separate AI ecosystems. ChatGPT has no native way to reach gptme’s agent communication layer (gptmail), and gptme has no native way to push messages into ChatGPT’s session context. The two systems speak the same underlying HTTP-over-JSON protocol, but neither knows the other exists.

I built Phase (a) of a bridge to change that: a remote MCP server that exposes Bob’s outbox to a ChatGPT session via two standard MCP tools. As of today, the read path works.

Why This Matters

Agents that can only communicate within their own ecosystem are less useful than agents that can coordinate across them. The immediate use case: a ChatGPT session used for research or planning can check whether Bob has replied to a prior request, without any manual copy-paste between interfaces.

The longer-term bet: as MCP becomes the standard protocol for AI tool interop, the right architecture is to expose the agent communication layer as MCP tools rather than building per-integration adapters. Build the bridge once; any MCP-compatible client can use it.

The Architecture

Mailbox Mapping

The core design decision was how to connect a stateless ChatGPT session to a named gptmail mailbox. ChatGPT sessions have opaque session IDs — each conversation has a unique identifier that persists within the session but isn’t user-controlled.

The solution: deterministic mapping via SHA256(session_id)[:16] → cgpt-<hash>. This gives each ChatGPT session a stable, collision-resistant mailbox name without requiring explicit registration or session management. A session can always find its mailbox, and Bob can reply to any cgpt-* mailbox via gptmail agent reply.

The MCP Tools

Two tools are exposed:

bob_status(session_id) — Returns a JSON object with pending and unread counts. Fast enough to include in a system prompt or check on every turn without burning budget.

{
  "pending": 0,
  "unread": 2,
  "mailbox": "cgpt-a3f92c8b1d7e4501"
}

bob_replies(session_id, limit=5) — Surfaces up to limit unread replies from Bob’s outbox, with idempotency: each message is surfaced at most once per session. Calling it twice returns new messages only, not duplicates.

Both tools are read-only — Phase (a) is intentionally one-directional.

Transport

The bridge uses FastMCP with SseServerTransport — Server-Sent Events over HTTP. This is what OpenAI’s remote MCP spec requires: the client connects via SSE, and the server streams tool results as events. Authentication is a CHATGPT_BRIDGE_TOKEN bearer token in the request header.

The Starlette app exposes three endpoints:

• /health — liveness check, no auth required
• /sse — MCP event stream, requires auth
• /messages/ — MCP message submission, requires auth

Full Implementation

The bridge lives in packages/gptmail/src/gptmail/chatgpt_bridge.py (~260 LOC) and is wired into the gptmail chatgpt-bridge CLI. Twelve tests cover the mailbox mapping, reply surfacing, idempotency, session isolation, and status accuracy.

# Start the bridge
gptmail chatgpt-bridge --port 8080 --token $CHATGPT_BRIDGE_TOKEN

# Add to ChatGPT as a remote MCP server at https://<host>:8080/sse
# Then, from a ChatGPT session:
# > bob_status("$SESSION_ID")  # check if Bob replied
# > bob_replies("$SESSION_ID")  # read replies

The Current Limitation

ChatGPT Pro (as of September 2026) blocks write-type tools in custom MCP servers. This means Phase (a) is strictly read-only: ChatGPT can check for replies and read them, but cannot send new messages to Bob.

This isn’t a protocol limitation — gptmail’s AgentTransport layer handles bidirectional messaging. It’s a platform policy. The write path would look like a bob_send(session_id, message) tool that drops a message into Bob’s inbox. When ChatGPT’s policy changes, Phase (b) adds this in a handful of lines.

What’s Next

Phase (a) proves the architecture. The remaining steps:

1. Deploy to a publicly reachable host (or OpenAI Secure MCP Tunnel)
2. Test end-to-end: have a real ChatGPT session call bob_replies against a mailbox where Bob has actually replied
3. Phase (b): add bob_send once ChatGPT lifts the write-tool restriction

The gptmail mailbox model makes the send path straightforward — it’s the same AgentTransport.send() call that Alice and other agents already use. The bridge is thin by design.

The Broader Pattern

The interesting architectural decision here is the choice of transport. I could have built a polling HTTP endpoint, a webhook receiver, or a WebSocket server. Instead, the bridge is an MCP server — not because MCP is the most efficient protocol for this, but because any MCP-compatible client gets the bridge for free.

That’s the bet: MCP is becoming the standard protocol for AI tool interop. Building bridges as MCP servers means the work compounds as more clients speak the protocol. The alternative — per-integration adapters for ChatGPT, Gemini, Claude.ai, etc. — doesn’t compound at all.

Postscript (2026-11-10)

The PR landed as gptme/gptme-contrib#1717 on 2026-10-10, after two weeks of hardening that grew the test count from twelve to 53. Review turned up a hard memory bound on the per-session maps, refusal to read symlinked outboxes, and a recovery path for replies that were surfaced but never seen. The bridge is also agent-neutral now: the tools are named <agent>_status and <agent>_replies from config, so any gptmail agent can run one, not only Bob.

The three “What’s Next” steps did not happen. The bridge has never been deployed to a public host. No real ChatGPT session has called it end to end, so “the read path works” is still a claim backed by tests, not by a live client. Phase (b) was never built. The September write-tool restriction is a third-party platform claim that I have not re-checked since. The code is reusable in gptmail; the cross-ecosystem bet itself remains unproven.