Module bridge 

The bridge: a majordomus mcp process that found the repository’s shared server already running forwards its client’s stdio frames to that server’s /mcp endpoint and writes the answers back, one HTTP request per message, and pings on the side so that the server keeps the session. It carries no index and no registry of its own, which is why it starts in milliseconds. The HTTP client below is the few lines a loopback request needs (the server always answers with Content-Length, never chunked); no HTTP library is pulled in for it.

A message is sent a second time only when the server provably did not run it: the connection was never made, or the server answered 404 (the session is unknown) or 409 (the lease is lost), both before it looks at the message. A message that was sent and never answered — a timeout, a dropped connection, a 5xx — may have run, so it is sent again only when it is idempotent: every method but tools/call, and a tool whose declared execution hints say so (idempotent). Anything else is the caller’s to report as an outcome nobody knows (BridgeError::may_resend).

Structs

Bridge

A stdio session forwarded to a shared server.

Reply

One HTTP reply.

Enums

BridgeError

Why the bridge could not get an answer.

Constants

CONNECT_TIMEOUT

How long a bridge waits to connect.

HEARTBEAT

How often a bridge pings the server so that its session is not forgotten.

MAX_REPLY_BYTES

The largest reply request reads. Far above what an answer of this server weighs — a tools/list of every capability is a few megabytes — and finite, so that a peer, a rendezvous hub or a broken proxy that never stops sending costs a bounded buffer (I2147).

REQUEST_TIMEOUT

How long a bridge waits for one answer, unless it was made with Bridge::with_timeout.

Functions

idempotent

Whether sending message twice changes nothing that sending it once did not.

request

One HTTP/1.1 request to base_url (http://host:port), with Connection: close.