Herramientas MCP

MCP ámbitos y tokens

Emitir tokens MCP con alcance y revocarlos de forma segura.

Showly MCP los tokens son la forma en que los agentes se autentican. Esta página cubre cómo emitirlos, cómo definir su alcance y cómo rotarlos o revocarlos cuando algo parece estar mal.

Emitir un token

Configuración del espacio de trabajo → MCP clientes → Nuevo cliente.

Establecerás cinco campos:

Nombre del cliente: aparece en los registros de auditoría. Hágalo descriptivo: Claude Code (alice@acme) se lee mejor que token-3.
Alcance del proyecto — Opcional. Cuando se establece, el token solo puede ver y modificar sitios/implementaciones en ese proyecto.
Alcances: elija el mínimo necesario. El valor predeterminado es project:read, site:read, preview:read.
TTL: durante cuánto tiempo es válido el token. Por defecto 90 días, máximo 365.
Notas — Free-texto. Úselo para registrar para qué sirve el token.

El token se muestra una vez en el momento de la creación. Cópialo; No almacenamos el texto sin formato.

Referencia de alcance

Los ámbitos son cadenas planas, no niveles anidados. Un token lleva una lista explícita y la API solo acepta los nombres exactos que aparecen a continuación.

Alcance	Nivel	Permite
`project:read`	leer	`list_projects`: enumera e inspecciona los proyectos a los que puede acceder este token
`site:read`	leer	`list_sites`, `get_site_context`, `create_change_plan`, `list_site_versions`, `get_site_files` - leer el estado del sitio
`site:write`	escribir	`apply_site_patch`, `create_site_from_template`: ediciones de etapa (nunca se implementa directamente)
`site:delete`	escribir	`delete_site` — eliminación temporal en cascada de dos pasos de un sitio (nivel de administrador)
`preview:read`	leer	`get_preview_status` — leer el estado de implementación
`preview:create`	escribir	`create_preview`, `create_github_preview`, `delete_preview` — materializar/eliminar temporalmente una vista previa privada
`checks:run`	escribir	`run_checks` — leer pelusa/verificación de tipo/compilación/estado de auditoría
`publish:request`	escribir	`request_publish` — abrir una fila de aprobación para una publicación de producción
`publish:confirm`	escribir	`publish_site` — confirmación y publicación en producción en dos pasos (confirmación humana en conversación; planes individuales/sin aprobación)
`rollback:confirm`	escribir	`rollback_to_version` — revertir la producción en dos pasos a una versión anterior (nivel de administrador, directo a producción)
`logs:read`	leer	`get_deployment_logs` — registros de compilación capturados en la cola; `diagnose_deployment` también expone diagnósticos limitados de cliente/agente
`template:read`	leer	`list_templates` — lista de plantillas de sitios disponibles
`template:create`	escribir	`create_site_from_template` — materializar un nuevo sitio a partir de una plantilla

No hay ninguna escalera de implicaciones. Otorgar publish:request no otorga preview:create; Elija exactamente los alcances que necesita un cliente. El panel "MCP token" de la interfaz de usuario web muestra esta lista como casillas de verificación; la misma constante impulsa el creador de roles para roles RBAC personalizados.

El verbo heredado rollback_deployment no MCP-expuesto independientemente de los alcances; publish_site se puede llamar a MCP solo con publish:confirm y una confirmación en conversación de dos pasos. Consulte la referencia de la herramienta para conocer el fundamento.

Cómo se ve un token de alcance limitado

Para un agente _solo contenido_ que nunca debe tocar la infraestructura:

Lista de permitidos: solo el sitio marketing-site.
Ámbitos: site:read, site:write. El agente puede preparar parches, pero no puede crear vistas previas ni publicarlos.
TTL: 30 días.

Para un _deploy-bot_ en CI:

Lista de permisos: solo el sitio de producción que se está implementando.
Ámbitos: preview:read, preview:create, checks:run, publish:request. No site:write: los parches provienen del flujo de trabajo registrado de CI, no del bot.
TTL: 14 días, rotado por CI.

Para un _bot de incorporación basado en plantilla_:

Lista de permitidos: cualquier proyecto al que esté invitado el bot.
Ámbitos: project:read, template:read, template:create, site:write, preview:read, preview:create. Permite que el bot elija una plantilla, cree el sitio y observe la primera vista previa de la compilación.
TTL: 7 días.

Rotación

Dos caminos:

Manual: haga clic en Rotar en un cliente. El token antiguo se revoca instantáneamente; copie el nuevo y actualice su configuración de shell.
Programado: establezca una cadencia de rotación en Configuración del espacio de trabajo → Política de token. Showly envía un correo electrónico al propietario del cliente antes de que expire.

Revocación

Haga clic en Revocar para eliminar un token inmediatamente. Cualquier llamada a la herramienta en curso que utilice el token revocado obtiene un 401. El nombre del cliente permanece en los registros de auditoría (con un indicador revoked), por lo que las entradas históricas aún se resuelven.

Si cree que un token está comprometido, revoque primero, investigue después. Un token comprometido con alcance publish:request puede abrir una aprobación de publicación, pero aún así no puede omitir al aprobador humano ni la confirmación de publicación vinculada a la implementación.

Visibilidad de la auditoría

Cada llamada a la herramienta escribe una fila de auditoría que contiene la identificación del cliente (no el token). Puede:

Consultar todas las llamadas de un cliente: client_id eq <id>.
Consultar todas las llamadas escribiendo un verbo: action eq mcp.request_publish.
Revisar y exportar registros únicamente a través de superficies de auditoría habilitadas para el

espacio de trabajo.

Qué no pueden hacer los tokens

Lecturas entre inquilinos. El token está vinculado a un espacio de trabajo.
Omitir aprobaciones. Un alcance publish:request otorga la _capacidad de abrir_ una aprobación; las reglas de aprobación aún se aplican.
Escribir a facturación o RBAC. Estos requieren un rol humano + administrador + sesión de navegador.
Invoca el verbo rollback_deployment heredado: no está registrado en absoluto en el servidor MCP. (publish_site requiere el alcance publish:confirm más una confirmación explícita de dos pasos).

La publicación directa Free/Pro también utiliza publish:confirm, que se incluye en la autorización recomendada del agente editorial y aún requiere la confirmación de segunda llamada de corta duración. Ámbitos de eliminación y reversión destructivos permanecer opt-in.