MCP tunnels

An MCP tunnel connects Syntic to an MCP server that lives inside your private network. You run a small connector process next to the server. The connector opens an outbound TLS connection to Syntic on port 443 and keeps it open. When a request or an agent session calls a tool on that server, Syntic sends the call down the tunnel and the connector forwards it to the server. Nothing in your network has to accept inbound traffic, and the server never needs a public address.

Preview flag: syntic-beta: mcp-tunnels-2026-12-01. Tunnels belong to a workspace and are managed with that workspace’s inference keys.

How a call travels

1. Your request lists an MCP server with a tunnel_id (see MCP connector).
2. Syntic checks the organization’s MCP policy, then picks one of the tunnel’s online connectors.
3. The connector checks the target URL against the tunnel’s allowed_targets. It refuses anything else, even if Syntic asked for it.
4. The connector forwards the MCP request, streams the reply back, and Syntic hands the tool result to the model.

Using a tunnel in a request

{
  "model": "Amara S1.2",
  "messages": [{ "role": "user", "content": "What is the stock level of part 7731-B?" }],
  "mcp_servers": [
    {
      "name": "erp",
      "url": "http://erp-mcp.internal:8080/mcp",
      "tunnel_id": "tnl_01JCE4G6J8L0N2Q4S6U8",
      "allowed_tools": ["get_stock_level"]
    }
  ]
}

The url is the address as the connector sees it inside your network. It must exactly match one of the tunnel’s allowed_targets.

Running the connector

docker run -d --name syntic-tunnel --restart unless-stopped \
  -e SYNTIC_TUNNEL_TOKEN="$SYNTIC_TUNNEL_TOKEN" \
  syntic/tunnel-connector:0.9

Run two connectors on different hosts for redundancy. Calls are spread across all online connectors, and a connector that drops has its in-flight calls retried once on another one.

Limits

Errors seen by requests

Endpoints