> ## Documentation Index > Fetch the complete documentation index at: https://wondeya.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Servidor MCP > Qué es el servidor MCP de wondeya, cómo se autentica y qué tiene permitido tocar wondeya expone un servidor Model Context Protocol (MCP) para que un agente de IA pueda construir y operar una página sin un navegador: crearla, enseñarle, reestilizarla, publicarla y comprobar qué respondería. Es el mismo motor que impulsa la consola: cada herramienta ejecuta exactamente el mismo comando o consulta que ejecuta la propia API de la consola, así que las dos superficies no pueden desarrollar dos comportamientos distintos. **La autenticación es OAuth 2.1.** Te conectas iniciando sesión en wondeya desde tu navegador y aprobando una pantalla de consentimiento; no hay clave que crear ni pegar. Eso es lo que permite que los asistentes de navegador (Claude, ChatGPT) se conecten, no solo los agentes de código. `tools/list` sobre una conexión en vivo es siempre la respuesta autoritativa sobre lo que ofrece el servidor. ## El endpoint ``` POST https://api.wondeya.com/mcp ``` * **Transporte:** Streamable HTTP. * **Nombre del servidor:** `wondeya`. * **Sin estado por diseño.** `GET` y `DELETE` responden `405`: no hay flujo iniciado por el servidor ni sesión que terminar, y anunciar cualquiera de los dos sería anunciar una capacidad que no existe. ## Autenticación **Inicias sesión; nunca pegas una credencial.** La primera vez que un cliente llega al endpoint se lo rechaza con un `401` cuyo encabezado `WWW-Authenticate` apunta a los metadatos de descubrimiento de wondeya. A partir de ahí el cliente ejecuta por su cuenta el handshake estándar de OAuth 2.1: se registra a sí mismo, abre wondeya en tu navegador y, una vez que iniciaste sesión y aprobaste, recibe un token de acceso de vida corta que envía como token bearer en cada llamada. Lo que ves es una sola pantalla: una **pantalla de consentimiento** que nombra al cliente que pide conectarse, el **espacio de trabajo** al que se ligará la conexión, a ti y los permisos que solicita. Apruébala y el cliente queda conectado; el token nunca toca tu disco a la vista y expira por sí solo. Por debajo, la cadena es la estándar que todo cliente de MCP espera: * **Metadatos de recurso** (RFC 9728) en `/.well-known/oauth-protected-resource`, servidos tanto en la ruta base como en la variante con sufijo `/mcp`, porque distintos clientes sondean distintas rutas. * **Metadatos del servidor de autorización** (RFC 8414) que anuncian los endpoints de autorización, token y registro, y `code_challenge_methods_supported: ["S256"]`. * **Registro dinámico de cliente** (RFC 7591), para que un cliente que nadie preconfiguró pueda registrarse a sí mismo. * **PKCE (S256)** en cada autorización, y **vinculación de audiencia** (RFC 8707): el token se emite para este endpoint MCP y ningún otro, y el servidor rechaza un token generado para cualquier otra cosa. wondeya es el servidor de recursos; el servidor de autorización, el inicio de sesión y el consentimiento los aloja el proveedor de identidad de wondeya en un dominio de wondeya. No hay acceso anónimo, y todo fallo de autenticación responde el mismo `401` genérico con el código `wondeya.oauth.unauthorized`, así que un escáner no puede distinguir una causa de otra. ## Una conexión, un espacio de trabajo **Aprobar el consentimiento liga la conexión a un espacio de trabajo (el que está activo en tu sesión cuando apruebas), y nada puede moverla.** No hay un parámetro para elegir un espacio de trabajo ni una herramienta que pueda alcanzar otro: cada id que pasas se resuelve dentro del espacio de trabajo ligado, y un id de página copiado de otro lado simplemente no existe en lo que respecta a tu conexión. Para conectar un agente a un espacio de trabajo *distinto*, primero cambia de espacio de trabajo en la consola y luego inicia la conexión: la pantalla de consentimiento siempre muestra qué espacio de trabajo estás a punto de otorgar, así que no hay una concesión silenciosa al espacio de trabajo equivocado. Es el mismo aislamiento sobre el que corre el resto del producto: las mismas cuatro capas, no una segunda implementación para agentes. [Seguridad y privacidad](/docs/es/security) las describe. ## Los permisos controlan las herramientas La conexión lleva los permisos que aprobaste, y cada herramienta verifica su permiso en **cada llamada**: | Permiso | Desbloquea | | - | - | | `landings:read` | Listar y leer agentes, páginas y site keys de widget, y leer el tema. | | `landings:write` | Crear, editar, publicar, despublicar y borrar agentes y páginas, generar y rotar site keys de widget, y escribir el tema. | | `projects:read` | Listar sitios y sus direcciones. | | `projects:write` | Crear, editar y borrar sitios, cambiar su dirección, escribir su configuración de SEO y regenerar `llms.txt`. | | `knowledge:read` | Listar fuentes de conocimiento y temas, y sondear la recuperación. | | `knowledge:write` | Agregar documentos, URLs y afirmaciones, borrar fuentes y gestionar temas. | | `assets:read` | Listar imágenes. | | `assets:write` | Subir imágenes. | | `brand:read` | Leer la marca. | | `brand:write` | Subir recursos de marca y definir la barra de navegación y el pie de página. | | `analytics:read` | Cifras de uso del espacio de trabajo. | | `domains:write` | Liberar la dirección de un sitio. | La pantalla de consentimiento también puede ofrecer `chat:write`: controla el endpoint de chat generativo de la API REST para desarrolladores y no desbloquea ninguna herramienta de MCP, así que déjalo sin otorgar para una conexión MCP. Llamar a una herramienta para la que tu conexión no tiene el permiso responde con el código `wondeya.oauth.insufficient_scope`; la herramienta no se ejecuta. Otorga el conjunto más acotado que resuelva la tarea: una conexión con solo `landings:read` y `knowledge:read` puede auditar un espacio de trabajo y no puede cambiar nada. **Tu rol limita lo que puedes otorgar.** Un propietario o administrador puede otorgar lectura y escritura; un miembro puede otorgar solo lectura, y la pantalla de consentimiento atenúa los permisos que tu rol no puede dar. La autorización sigue siendo asunto de wondeya: la puerta de consentimiento decide solo lo que una conexión *puede pedir*, y cada herramienta se sigue verificando contra los permisos realmente otorgados. ## Gestionar y revocar conexiones Una conexión aparece listada en la consola en **Configuración → Aplicaciones conectadas**, con los permisos que tiene, y la revocas ahí. La revocación surte efecto en la siguiente solicitud: el token del cliente deja de funcionar y debe iniciar sesión de nuevo para reconectarse. ## Cómo se ven los resultados de las herramientas Una llamada exitosa devuelve el mismo JSON que devuelve la API, como texto formateado. Un **fallo no es un error de protocolo**: es un resultado MCP normal marcado con `isError`, que lleva el mismo documento de problema RFC 9457 que devuelve la API HTTP: `code`, `title`, `detail`, `status`, `requestId` e `instance` nombrando la herramienta que falló. Es deliberado por dos motivos: un error a nivel de transporte nunca llega al modelo, y `wondeya.project.slug_taken` tiene que significar una sola cosa en el producto, no una cosa por superficie. Un agente debe decidir en función de `code`, nunca de `detail`. [La referencia de errores](/docs/es/api-reference/errors) los lista. ## Qué cubren las herramientas hoy Agentes y sus site keys de widget, sitios y páginas (incluida la publicación), conocimiento, imágenes, la marca y el tema, y el uso del espacio de trabajo. [La referencia de herramientas](/docs/es/mcp/tools) documenta cada una. Todavía no cubierto, y conviene saberlo antes de planificar en torno a ello: * **Miembros e invitaciones.** La gestión del equipo se queda en la consola. * **Claves de API y conexiones.** Una conexión no puede generar ni gestionar credenciales, incluida la suya propia; crear claves de API y revocar conexiones se quedan en la consola, donde una persona las aprueba. Las **site keys** de widget son la excepción: una site key identifica a un agente y no autoriza nada, así que crearlas, listarlas y rotarlas sí está cubierto. * **Dominios personalizados.** Conectar y verificar uno es tarea de la consola (y de HTTP); no hay herramienta de MCP para ello. ## Dos reglas que un agente equivoca si no se le dicen El servidor las declara en sus propias instrucciones, y vale la pena repetirlas aquí porque son las dos cosas que sorprenden a la gente: 1. **Crear una página no la publica.** Una página nace como borrador y no responde a nadie. `publish_page` es el único acto que la abre al mundo. 2. **La ingesta es asíncrona.** Agregar un documento o una URL responde de inmediato con la fuente en `pending`. Sondea `list_knowledge_sources` hasta que esté en `ready` antes de asumir que la página puede responder a partir de ella. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.