Supergateway for bridging MCP transports

How it works

The gateway sits between endpoints, translating the connection mechanism while leaving the tool implementation on the upstream server. This can connect a local command to an HTTP-facing client.

What you need

Choose the supported direction of translation and identify which end owns authentication. Bind the listener to the smallest network scope needed for the test.

What to try first

Bridge a fixture server and compare its capabilities with a direct connection. Disconnect the client during a call and observe how the gateway and child process respond.

Try malformed input and an upstream process that exits early. Record how the client sees these two errors and whether the proxy releases the connection.

Where to look for failures

The bridge adds a network and credential boundary. Restrict who can reach it, and check how headers and upstream secrets are configured.

Related Franklin pages

Verify capabilities before and after adding a bridge. Then test a client disconnect so you know which process and connection remain alive.

• Bridge supported local and remote MCP transports from a lightweight proxy. mcp-proxy for adapting MCP server connections
• Inspect MCP connections and exercise tools, resources and prompts during development. MCP Inspector for testing server behavior

Browse Franklin for concrete examples of tools and services exposed through MCP. Franklin’s MCP directory

Project documentation

• Current project README
• README at the reviewed revision