Cómo configurar un flujo de migración de Revit Cloud Worksharing con APS y MCP

¿Qué aprenderás en esta guía?

Esta guía explica cómo plantear un flujo de migración de Revit Cloud Worksharing (RCW) en un servidor Model Context Protocol (MCP) que se comunica con APS. El ejemplo de Autodesk muestra cómo un cliente MCP convierte una solicitud en lenguaje natural en llamadas a herramientas, cómo el servidor organiza las operaciones de APS y cómo la automatización de Revit migra el modelo. Los pasos están pensados para entender la arquitectura del ejemplo; no son instrucciones de configuración listas para producción y aplicables directamente a cualquier proyecto.

La distinción clave es la siguiente: el cliente de IA coordina la decisión de migrar y las llamadas a herramientas; la operación real en el modelo se ejecuta en Design Automation for Revit, que utiliza la API de Revit. El servidor MCP gestiona las operaciones y la autorización entre ambas partes.

Requisitos y acceso

El ejemplo de Autodesk amplía un servidor MCP basado en Node.js con funciones de APS. El servidor MCP debe conectarse a un cliente compatible y tener acceso a los datos de APS donde se encuentran el modelo de origen y el proyecto de destino. Para ejecutar la automatización de Revit, también deben estar configurados un motor de Revit apto para la migración y las actividades de automatización. La fuente no especifica una versión de Node.js ni información sobre precios, por lo que no se deben asumir versiones ni costes.

La elección del método de autenticación depende de dónde se ejecute el servidor y de quién sean los datos sobre los que se realiza la operación. En un servidor iniciado mediante STDIO por un cliente de escritorio local, puede que no se necesite una autenticación independiente entre el cliente y el servidor. Para operar en nombre de un usuario en APS, se puede usar OAuth de 3 patas (3LO) o PKCE en situaciones como los procesos locales, donde no es posible almacenar un secreto. Para trabajos que requieran una identidad de aplicación compartida en todo el servidor, se pueden evaluar OAuth de 2 patas (2LO) o una Secure Service Account (SSA) con permisos concedidos. Hay que tener en cuenta que no todas las API admiten todos los tipos de identidad.

Cómo planificar el flujo de migración paso a paso

1. Define el caso de uso y el cliente. Primero, aclara si se trabajará con los permisos del propio usuario o con una identidad de automatización compartida. Después, decide si el servidor MCP funcionará como un proceso local o se ofrecerá de forma remota a través de HTTP. La guía de Autodesk contempla STDIO para el uso local y Streamable HTTP para escenarios remotos y multiusuario. En los servidores expuestos mediante HTTP, la autenticación entre el cliente y el servidor debe diseñarse por separado de la autenticación de APS.

2. Elige el método de autenticación de APS según los permisos necesarios. Para acceder a los datos personales de un usuario, se puede considerar 3LO o PKCE, que se basan en el inicio de sesión del usuario. 2LO puede utilizarse para los recursos propios de la aplicación, pero quizá no baste para las llamadas a API que requieren el contexto de un usuario. Si la automatización necesita acceder a los datos del proyecto sin que un usuario tenga que iniciar sesión continuamente, se puede considerar una SSA autorizada para los hubs y proyectos de destino. No confundas el token de acceso entre el servidor y el cliente con el token de APS: los tokens de ambas capas tienen propósitos diferentes.

3. Separa las funciones de las herramientas MCP. En el ejemplo de Autodesk, el servidor puede descubrir proyectos y carpetas con las herramientas existentes de gestión de datos; el campo extensionType del contenido de una carpeta ayuda a identificar los modelos RCW. La herramienta migrate-rcw-model, añadida para la migración, recibe el modelo de origen, el proyecto y la carpeta de destino, y la versión de Revit de destino. Con esta información, la aplicación prepara y envía el trabajo de APS Automation. Separar el descubrimiento de la acción de migración que modifica los datos hace más claro qué operación iniciará el cliente.

4. Comprueba los requisitos previos y solicita la aprobación del usuario. En el flujo de ejemplo, check-migrator-setup sirve para comprobar los motores de Revit configurados y las actividades de automatización. Autodesk indica que las instrucciones del flujo de trabajo pueden orientar al asistente para verificar los requisitos previos y solicitar la aprobación del usuario antes de migrar. No envíes el trabajo de migración hasta que estén claros el proyecto, la carpeta y la versión de Revit de destino; confirma estas opciones con el usuario.

5. Haz que el trabajo asíncrono se pueda supervisar. Como la migración puede tardar varios minutos, que la herramienta devuelva un ID de trabajo no significa que haya terminado. En el ejemplo, get-migration-status obtiene el estado del trabajo y la información de errores; cancel-migration solicita la cancelación de los trabajos pendientes. En clientes compatibles que usan MCP Apps, un panel de estado puede mostrar los trabajos activos, las migraciones completadas, los detalles de los errores y los controles de cancelación. Esta capa debe considerarse por separado de la herramienta que inicia la migración.

6. Prueba el flujo de forma segura y controlada. Primero, verifica que se puedan enumerar los modelos accesibles y que la comprobación de configuración funcione. Después, con la aprobación del usuario, envía un solo modelo al proyecto de destino y observa si el ID del trabajo, el estado y la información de errores se devuelven como se espera. No es correcto entregar los tokens de APS al cliente ni pasar directamente a APS el token del cliente. Para un servidor MCP remoto, define también quién puede acceder al servidor; esta capa es distinta de la que determina con qué identidad opera APS.

Qué implica para los flujos de arquitectura y visualización

Los estudios de arquitectura que trabajan con varios proyectos de Revit o modelos RCW pueden beneficiarse de la posibilidad de iniciar una migración en lenguaje natural y seguir su progreso desde el mismo cliente. Para los desarrolladores, las herramientas MCP ofrecen un ejemplo de cómo conectar una automatización de APS existente con distintos clientes compatibles. Sin embargo, esto no resuelve por sí solo la coordinación BIM ni el análisis de las dependencias del modelo.

Las fuentes no ofrecen información sobre costes de hardware o licencias. Por tanto, antes de tomar una decisión, hay que verificar por separado el acceso de la empresa a APS, la configuración de automatización de Revit elegida y la compatibilidad del método de autenticación con los permisos del proyecto. En particular, los equipos que trabajan con modelos vinculados no deben suponer que también se migrarán los modelos asociados.

Errores frecuentes y próximos pasos

La principal limitación es que el ejemplo se centra en modelos RCW individuales: no migra automáticamente las relaciones entre modelos vinculados ni repara los vínculos en el proyecto de destino. En los proyectos que incluyen modelos vinculados, se necesitan análisis de dependencias, comprobaciones previas y coordinación adicionales; la fuente considera estas funciones como posibles mejoras futuras.

Otro error de diseño frecuente es asumir que la autenticación entre el cliente MCP y el servidor es lo mismo que el acceso a APS. Primero, determina quién autentica a quién en cada capa. Después, revisa las herramientas, los permisos y la aprobación del usuario teniendo en cuenta esa distinción. Al pasar a la implementación técnica, considera el repositorio de ejemplo de Autodesk y los ejemplos de autenticación de APS MCP como punto de partida; para un entorno de producción, aborda por separado los requisitos de seguridad y de modelos vinculados.

Fuente y licencia

El contenido se ha adaptado de las guías de Autodesk Platform Services “Bringing Revit Cloud Worksharing Migration to AI Assistants with APS and MCP”, “Building Custom MCP Servers with Autodesk Platform Services” y “Authentication Patterns for APS MCP Servers”. Los registros de las fuentes proporcionadas indican que el estado de la licencia es libre, pero no mencionan una licencia abierta concreta; por tanto, no se afirma que el contenido se haya publicado bajo una licencia como CC BY.