Herramientas MCP

MCP descripción general

Por qué Showly expone las capacidades como MCP herramientas en lugar de REST API sin formato.

Showly expone sus capacidades a agentes de codificación a través del Protocolo de contexto modelo. Esta página explica el _por qué_; para el _qué_, vaya a la referencia de herramienta.

Por qué MCP

Un REST API simple obligaría a cada agente a aprender un flujo de autenticación personalizado, formas de solicitud personalizadas y una semántica de error personalizada. MCP resuelve los tres:

  • Herramientas escritas. Cada capacidad es un tool con una entrada y salida de esquema JSON. El host del agente (Claude Code, Codex) genera automáticamente la lista de herramientas para el usuario.
  • Tokens con alcance. Un token Showly MCP está vinculado a un espacio de trabajo, opcionalmente un proyecto, el usuario autorizado cuando se crea a través del flujo OAuth/dispositivo y un conjunto de alcances de herramientas. El token nunca otorga más de lo que el agente necesita.
  • Auditoría de primera clase. Cada llamada a la herramienta registra la identificación del cliente, la acción, los parámetros (con redacción secreta) y el resultado.

Lo que ve el agente

Una vez que el usuario ha instalado el cliente Showly MCP, el agente ve las herramientas agrupadas por capacidad:

  • Leer — list_projects, list_sites, get_site_context, get_site_files, get_preview_status
  • Planificación — create_change_plan
  • Aplicar — apply_site_patch
  • Construir — create_preview, run_checks, retry_deployment
  • Enviar — request_publish (abre un flujo de aprobación humana en planos con flujos de trabajo de aprobación); publish_site y rollback_to_version actúan directamente mediante un token de confirmación de dos pasos en la conversación
  • Inspeccionar — get_deployment_logs, diagnose_deployment, list_deployments, list_site_versions, diff_site_versions
  • A bordo — list_templates, create_site_from_template, create_site_from_html, claim_trial_site
  • Transferir — request_upload_url, request_download_url (URL firmadas para archivos grandes que no deberían atravesar el contexto del modelo)
  • Limpiar — delete_preview, delete_site

El esquema de cada herramienta hace explícito su radio de explosión: request_publish requiere un deploymentId para una vista previa lista. El único verbo que se mantiene completamente fuera MCP es el legado rollback_deployment: vive en la interfaz de usuario web detrás de la MFA mejorada. Las herramientas MCP que afectan la producción (publish_site, rollback_to_version, delete_site) nunca actúan en la primera llamada: devuelven un token de confirmación de corta duración que debe repetirse en una segunda llamada.

Cómo se define el alcance de los tokens

Un administrador del espacio de trabajo emite un token MCP desde Configuración del espacio de trabajo → MCP clientes. Cada token tiene:

  • un nombre de cliente (para que los registros de auditoría se lean como "Claude Code (alice@acme)")
  • un alcance del proyecto opcional (qué proyecto puede tocar este cliente)
  • un conjunto de alcance: cadenas de alcance planas (sin niveles, sin escala de implicaciones), por defecto project:read, site:read, preview:read; consulte la lista completa en Alcances y tokens
  • un TTL (predeterminado 90 días, máximo 365 días)

Los tokens se pueden revocar instantáneamente desde el mismo panel.

Límites

La superficie MCP intencionalmente no expone:

  • Acceso directo a la base de datos.
  • Valores de variables del entorno de producción.
  • Lecturas entre inquilinos de cualquier tipo.
  • Mutaciones de facturación o gestión de usuarios del espacio de trabajo.

Si el flujo de trabajo de su agente necesita algo que no está en esta lista, presente un problema; la respuesta casi siempre es "agregar una herramienta con un alcance más limitado", no "abrir el API".

Próximo