Create (or revive) a relay tunnel for a named project server
Changed onRegisters a server record named name if missing, mints a relay tunnel grant for it, and persists the tunnel bearer URL (including the plaintext ?k= secret) onto the server record's url so evals and studies can target the tunnel like any remote server. The plaintext persistence is a deliberate trade-off of the current tunnel MVP — the backend otherwise stores only a hash of the secret — mitigated by rotation: every call rotates the secret, revokes the previous grant at the edge (disconnecting any live tunnel session for the server), and updates the stored URL, so re-calling this route is also the rotation/recovery path.
The caller hosts the tunnel itself: connect a WebSocket to relayWsUrl (subprotocol mcpjam-tunnel.v1, Authorization: Bearer <connectToken>) and serve the relayed requests — this is what mcpjam cloud tunnel does. When the host disconnects, the server record stays and calls to the public URL fail fast at the edge.
Request
- Base URLhttps://app.mcpjam.com/api/v1
- URLhttps://app.mcpjam.com/api/v1/projects/{projectId}/tunnels
- AuthHTTP bearer
Path parameters
ID of the hosted project that contains the server.
Request body
Response
Tunnel grant minted and the server record updated.
Changes
- warning
added the new
CONFLICTenum value to theresponse property for the response status - warning
added the new
CONFLICTenum value to theresponse property for the response status - warning
added the new
CONFLICTenum value to theresponse property for the response status - warning
added the new
CONFLICTenum value to theresponse property for the response status - warning
added the new
CONFLICTenum value to theresponse property for the response status - warning
added the new
CONFLICTenum value to theresponse property for the response status - warning
added the new
CONFLICTenum value to theresponse property for the response status
- warning
- info
endpoint added
- info