---
title: "Tunnel Get Or Create Token"
method: POST
path: "/tunnel/token"
---

# Tunnel Get Or Create Token

`POST /tunnel/token`

## Request

- Base URL: `https://api.local-mcp.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.local-mcp.com/tunnel/token`
- Auth: none declared

Emite un tunnel token NUEVO para esta máquina. El email es dato de contacto, nunca la cuenta.

lmcp-api#229: el endpoint no tiene autenticación y el email nadie lo verificó. Escribirlo en
`tunnel_tokens.email` —la columna que leía la resolución por email (el claim del pre-token
y el conector `lmcp-pre-`, retirada en #358)— dejaba que cualquiera que supiera una
dirección la pre-registrara: la resolución del dueño caía en el token del atacante, o daba
409 (ambigua) si el dueño ya tenía una máquina, y un dueño nuevo recibía `recovery` sin token.
Ahora el token sale con email NULL y la dirección va a `contact_email` (#226: la ve sólo
quien tiene el token; ninguna resolución la lee; nada la promueve).

La respuesta es SIEMPRE `{token, email}` con un token recién emitido, tenga o no relay esa
dirección: el endpoint ya no lee filas existentes, así que no hay oráculo de enumeración ni
forma de devolver un token ajeno (F-17, #3352). El cliente Mac clasifica por `token` antes
que por `recovery` (CloudTunnel.classify), así que lo guarda como en un primer registro.

## Request body

- TunnelTokenRequest
  - `email` string, required
  - `license_key` string
  - `machine_id` string

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/local-mcp/apis/lmcp-api.md) · [All operations](https://skmtc.dev/local-mcp/apis/lmcp-api/llms.txt) · [OpenAPI document](https://skmtc.dev/local-mcp/apis/lmcp-api/revisions/f1f1c502623a?raw)
