Skip to main content
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

  • 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 las describe.

​
Los permisos controlan las herramientas

La conexión lleva los permisos que aprobaste, y cada herramienta verifica su permiso en cada llamada: 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 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 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.