Un visor BIM dentro del chat: APS Viewer y MCP Apps, sin magia
Tres capturas, dos círculos y una flecha que señala aproximadamente al conflicto. La conversación promete inteligencia, pero todavía estamos negociando qué objeto se quiere decir. Incrustar un visor en el chat puede resolver una parte de esa torpeza: seleccionar y consultar el elemento sin abandonar el contexto. Una mejora concreta y útil. La dificultad empieza cuando alguien interpreta que, por verlo dentro de una conversación, el modelo ya entiende las herramientas y los permisos por ósmosis.
El ejemplo de Autodesk del 13 de febrero de 2026 conecta APS Viewer con MCP Apps para mostrar un diseño en un cliente compatible. El interés está en relacionar la conversación con una selección concreta del modelo. Para valorar esa posibilidad hay que entender qué aporta el servidor, qué presenta el cliente y qué contexto recibe realmente la IA. Un visor junto al texto no convierte al asistente en coordinador omnisciente. Todavía tenemos que proporcionarle los datos.
Tabla de contenidos
Del mensaje al modelo hay dos piezas diferentes
En MCP, una herramienta puede devolver texto y datos estructurados. La extensión MCP Apps permite asociar además una interfaz interactiva que el cliente compatible aloja dentro de la conversación. El servidor declara un recurso de interfaz y una herramienta lo referencia mediante _meta.ui.resourceUri. La dirección utiliza el esquema ui://; el host la interpreta como parte del intercambio MCP, en lugar de tratarla como una página web convencional.
Esto separa dos responsabilidades. La herramienta resuelve la petición y devuelve sus datos; el recurso aporta el HTML con el que el usuario interactúa. El host obtiene ese recurso, presenta la interfaz y facilita la comunicación con ella. No basta con devolver una URL a un visor existente y cambiarle el prefijo. Sería una instalación extraordinariamente rápida, pero el protocolo tiene la desagradable costumbre de exigir que las piezas hagan algo.
Imagina un caso hipotético: quieres discutir una incidencia relacionada con un conducto y pides abrir el diseño de instalaciones. Primero hace falta identificar el proyecto y el diseño correctos. Después se puede preparar la visualización. Si hay dos archivos con nombres parecidos, la interfaz 3D no resuelve por sí sola la ambigüedad inicial. Mostrar muy bien el modelo equivocado sigue siendo mostrar el modelo equivocado, ahora con unas órbitas de cámara bastante convincentes.
El repositorio oficial de Autodesk ofrece herramientas para explorar proyectos y diseños, un recurso de Viewer y la interfaz correspondiente. Utiliza Secure Service Accounts para el acceso a APS y Streamable HTTP para el servidor MCP. Es una referencia de arquitectura y una demo de Autodesk; no es una implementación ejecutada por Sergio ni una capacidad ya incorporada a Issues Manager.
La herramienta preview-design recibe identificadores de proyecto y diseño, y prepara los datos necesarios para abrir la vista. El código de esa herramienta obtiene información de la versión actual y devuelve su URN, nombre y configuración de visualización. Esa elección merece atención si la conversación trata una incidencia antigua: antes de interpretar una selección habrá que asegurarse de que se está examinando la versión que corresponde al problema.
La salida textual y los datos estructurados también tienen usos diferentes. Una confirmación permite explicar al usuario qué se está abriendo; una estructura permite que la interfaz cargue el modelo. Conviene que ambas describan el mismo resultado y que la conversación siga siendo comprensible si el visor no puede mostrarse. Devolver «aquí lo tienes» cuando el cliente no presenta nada deja al usuario contemplando una afirmación con mucha autoestima y poca geometría.
Qué significa seleccionar un elemento durante la conversación
Una vez abierto el diseño, la interacción interesante empieza con la selección. La interfaz del ejemplo escucha los cambios del Viewer y utiliza updateModelContext para comunicar los identificadores seleccionados. También informa cuando no queda ningún objeto seleccionado. Ese intercambio permite relacionar una pregunta posterior con la interacción visible, sin obligar al usuario a copiar un número desde otra ventana.
Enviar un identificador no entrega automáticamente las propiedades del objeto ni las reglas para evaluarlo. Si preguntas por el material de un conducto, la aplicación necesita una operación autorizada que recupere ese dato y lo vincule con la selección. El identificador permite buscar; la fuente permite responder. Confundir ambas cosas puede producir una explicación muy convincente sobre un conducto que la aplicación todavía no ha leído.
La asociación debe incluir suficiente contexto del diseño y de su versión. Un número suelto puede tener sentido dentro del modelo cargado y resultar ambiguo fuera de él. Para un flujo de coordinación, conviene conservar qué se ha abierto, qué objeto se ha seleccionado y qué operación obtuvo los datos utilizados en la respuesta. Así puedes comprobar que la explicación se refiere al elemento visible y detectar cuándo una consulta está usando un contexto anterior.
Pensemos en el mismo conducto. Lo seleccionas, haces una pregunta y después cambias de diseño. Una integración bien resuelta debe actualizar o invalidar el contexto correspondiente, en lugar de seguir contestando sobre la selección anterior. Lo mismo ocurre al deseleccionar. El comportamiento correcto no siempre consiste en responder inmediatamente; a veces consiste en pedir una nueva selección antes de consultar datos. Esperar un clic suele ser más barato que redactar con gran aplomo sobre otro objeto.
Esta relación entre interfaz y herramientas también ayuda a acotar una propuesta de acción. Ver el objeto puede facilitar una revisión humana antes de modificar un dato, pero visualizar no concede permiso de escritura. Si más adelante se quisiera actualizar una incidencia, harían falta una operación específica, validaciones y una confirmación adecuada al efecto. La selección prepara una referencia; no es una firma en blanco sobre lo que decida hacer el siguiente callback.
Por eso la prueba funcional importante va más allá de que aparezca un edificio. Debe comprobarse si una selección llega al contexto esperado, si una consulta recupera el dato del elemento correcto y si el cambio de modelo invalida lo que ya no sirve. El recorrido tiene que poder explicarse de principio a fin. La demo puede seguir siendo vistosa; simplemente habrá algo comprobable debajo del movimiento de cámara.
La seguridad sigue existiendo dentro del rectángulo
El host aloja la interfaz en un entorno aislado y controla su comunicación con la aplicación que la contiene. Ese mecanismo limita capacidades, pero la integración sigue necesitando decidir qué datos recibe el navegador y qué servicios puede consultar. El recurso de Viewer del ejemplo declara una política CSP con orígenes para cargar recursos y establecer conexiones. Son listas con funciones concretas, no un trámite que se resuelve pegando cualquier dominio.
El visor necesita obtener scripts, estilos y contenido del modelo. Si la política bloquea una dependencia necesaria, la interfaz puede quedar incompleta aunque el servidor haya contestado correctamente. Abrir todos los orígenes para que deje de aparecer el error elimina precisamente la restricción que había que comprender. La alternativa es identificar la petición bloqueada, comprobar que corresponde al servicio esperado y ajustar la política mínima que requiere ese despliegue. Eliminar el semáforo arregla su luz roja; el cruce sigue allí.
Las credenciales merecen una revisión separada. El ejemplo entrega un access token de visualización en la configuración que recibe la interfaz. Eso no permite tratar esa configuración como información secreta frente a todas las partes del recorrido. structuredContent conserva datos procesables; su nombre no significa que solo pueda leerlo el visor. Debes revisar qué recibe el host, qué se incorpora al contexto y qué queda registrado en diagnósticos antes de adoptar el patrón.
En un despliegue propio, nunca deben enviarse a la interfaz el secreto de cliente ni la clave privada de una Secure Service Account. Un token que el navegador necesite utilizar debe tener el alcance y la duración adecuados, y la aplicación debe gestionar qué sucede cuando caduca. También conviene revisar los mensajes de consola: el código de demostración registra el resultado recibido, de modo que copiarlo sin evaluar sus diagnósticos puede conservar más información de la que pretendías. Una demo enseña el mecanismo; la operación diaria exige decidir qué conservar y dónde.
El aislamiento visual tampoco sustituye el control de acceso del backend. Que alguien pueda abrir el chat no demuestra que tenga permiso para consultar cualquier diseño. El servidor debe comprobar el recurso solicitado con la identidad y las reglas de la aplicación. En una solución compartida, una cuenta de servicio necesita un modelo de autorización que evite exponer a cada usuario todo lo que esa cuenta puede ver. La credencial puede estar bien custodiada y los datos mal repartidos. Son fallos diferentes y bastante compatibles entre sí.
Cuándo aporta más que abrir el visor en otra pestaña
La compatibilidad básica con MCP no garantiza soporte para MCP Apps. Antes de preparar una demostración, hay que elegir un cliente y una versión que implementen la extensión. La matriz oficial de compatibilidad y la documentación del host permiten iniciar esa comprobación. La lista puede cambiar y no sustituye una prueba del recorrido concreto con el visor, sus conexiones y su interacción.
En este trabajo no se ha ejecutado el ejemplo en ChatGPT ni en otro cliente. La revisión es documental y de código. Para convertirla en un tutorial de ejecución habría que conectar un despliegue autorizado, abrir un diseño disponible y comprobar la selección y su contexto. Las capturas de esa futura prueba deberían corresponder al cliente utilizado. Tomar una imagen ajena, cambiarle la cabecera y anunciar experiencia propia sería una integración particularmente eficaz de la ficción con el marketing.
El visor dentro de la conversación tiene sentido cuando la posición, la selección y la explicación se necesitan mutuamente. Revisar una incidencia espacial o comparar lo que se señala con sus propiedades puede justificar mantener ambas cosas juntas. Si solo necesitas tres valores o un enlace de descarga, una respuesta estructurada puede ser más clara y más barata de mantener. Introducir una interfaz también añade dependencias del host, del recurso y del ciclo de vida de la visualización.
Una aplicación independiente puede ser preferible cuando el trabajo exige sesiones largas de revisión, varias vistas o controles que el chat no acomoda bien. MCP Apps ofrece otra forma de presentar capacidades, no una obligación de encerrar todas las pantallas dentro de una conversación. El artículo sobre MCP y Revit desarrolla la importancia de delimitar las herramientas; añadir un visor mantiene esa necesidad y suma decisiones de interacción.
La interfaz merece la pena si permite identificar mejor el objeto y continuar una tarea que las herramientas realmente saben hacer. Verlo, consultarlo y modificarlo siguen siendo capacidades distintas. Antes de celebrar que el visor vive en el chat, comprueba cuál admite tu host y qué datos devuelve cada operación. Una ventana incrustada puede ahorrar fricción; no viene con un departamento de integración escondido detrás.
Respuestas