Appearance

MCP servers can speak to Frona over different transports. Most servers default to stdio, but HTTP-based transports are useful when a server is heavyweight or needs to be reused across processes.

Available transports ​

TransportWhen to use
stdioThe default. Frona spawns the server as a child process and communicates over stdin/stdout. Best for CLI-style servers, lowest setup cost.
streamable-httpThe server listens on an HTTP port and Frona connects to it. Best for servers that are slow to start, share state across calls, or are easier to debug standalone.
sseServer-Sent Events transport for compatibility with older HTTP servers. Picked automatically when a server only advertises SSE.

The default for new installs is set by mcp.default_transport (default: stdio).

Picking a transport at install time ​

The install dialog shows a transport selector populated from the server's registry entry. Each transport entry can declare its own:

  • args: extra command-line arguments for that transport
  • env: environment variables specific to that transport
  • port_env_var: for HTTP, the env var Frona injects with the allocated port
  • endpoint_path: for HTTP, the URL path the server serves on
  • url: for HTTP, an absolute URL when the server is hosted externally

You can change the active transport later from the server detail page. Switching transports restarts the server.

How HTTP transports work ​

When you pick a streamable-HTTP server, Frona allocates a port from mcp.port_range_start..port_range_end (default 4100..4200), exports it via the configured port_env_var, and starts the process. After the process is up, Frona polls http://localhost:<port><endpoint_path> until it responds, then begins the MCP handshake.

If the server is already running externally and exposes its own URL (e.g., a corporate MCP gateway), set url in the transport config and Frona will skip spawning a process altogether.

Sandboxing HTTP transports ​

Frona handles the local port binding automatically: HTTP transports bind to a port from mcp.port_range_start..port_range_end without any policy on your part.

Outbound connect rules apply the same way as for stdio servers. Pin the server to the destinations it actually needs:

cedar
forbid(
  principal == Policy::Mcp::"github-mcp",
  action == Policy::Action::"connect",
  resource
) unless { resource == Policy::NetworkDestination::"api.github.com:443" };

See Policies.

Tips ​

  • Default to stdio unless the server explicitly recommends HTTP. It's simpler and survives restarts cleanly.
  • Use HTTP for servers with long warm-up. A heavyweight server can stay up across multiple agent invocations.
  • External URLs are first-class. Point Frona at a remote MCP gateway and it acts like any local install with the same policies and agent surface.
  • Check the registry entry before switching. Some servers expose tools only on a specific transport.

Next steps ​

Frona AI