MCP en arquitectura: el protocolo que conecta la IA con las herramientas del estudio

---

Autor: Francisco Palomo, responsable de IA aplicada a arquitectura e interiorismo en The Factory School.

---

Qué es el Model Context Protocol, qué cambia cuando un modelo puede leer y actuar dentro del software que ya utilizamos, y qué precauciones exige su uso profesional.

El techo de la conversación

Cualquiera que haya trabajado unas semanas con un modelo de lenguaje conoce el mismo cuello de botella. El modelo razona con soltura sobre normativa, sistemas constructivos o estrategias de visualización, pero no alcanza nada. Para que entienda el proyecto hay que pegarle la memoria a mano; para que su respuesta sirva de algo hay que copiarla a mano al documento o a la herramienta que ejecuta el trabajo. El arquitecto termina ejerciendo de mensajero entre un sistema que sabe y unos programas que pueden.

Ese transporte manual es hoy la mayor parte del coste de usar inteligencia artificial en un estudio: no el precio de la suscripción, sino el tiempo de mover datos de un sitio a otro. El MCP en arquitectura, es la respuesta técnica a ese problema.

Esta transición desde una IA utilizada como herramienta aislada hacia sistemas integrados en el flujo de trabajo es precisamente uno de los ejes del Programa Profesional en Inteligencia Artificial para Arquitectura y del Programa Profesional en Inteligencia Artificial para Interiorismo, donde la tecnología se aborda desde su aplicación práctica a procesos reales de proyecto, diseño y visualización. 

---

Qué es un MCP

El Model Context Protocol (MCP) es un estándar abierto que define una forma común de conectar modelos de inteligencia artificial con datos y herramientas externas. Fue presentado por Anthropic en noviembre de 2024 y en diciembre de 2025 su gobernanza se transfirió a la Agentic AI Foundation, un fondo dentro de la Linux Foundation, con el respaldo de compañías como OpenAI, Google, Microsoft o AWS. Dejó de ser el proyecto de un fabricante para convertirse en infraestructura compartida del sector.

La lógica resultará familiar a cualquiera que haya sufrido la interoperabilidad entre programas de la disciplina. Antes del MCP, cada combinación de modelo y aplicación exigía un conector propio. El protocolo invierte el planteamiento igual que lo hizo el IFC en su momento: no elimina las diferencias entre aplicaciones, acuerda un lenguaje de intercambio. Quien desarrolla una herramienta publica un servidor MCP que declara qué puede hacer (leer un archivo, crear un registro, lanzar una generación de imagen) y cualquier modelo compatible sabe leer esa declaración.

Técnicamente hay tres piezas: el host, la aplicación con la que conversamos; el cliente, la parte del host que habla el protocolo; y el servidor, que expone las capacidades de una herramienta concreta con su catálogo de acciones y sus permisos. Para el usuario final todo esto se traduce en una operación sencilla: activar una conexión y comprobar que aparecen nuevas capacidades en la conversación.

---

Qué cambia en el trabajo

Con un servidor conectado, la conversación deja de ser un lugar donde se pregunta y pasa a ser un lugar donde se trabaja. El cambio se aprecia en tres frentes.

• El primero es que el contexto deja de caducar: el modelo consulta el documento en su origen, no la copia que pegamos hace veinte minutos. Es una lógica que ya empieza a verse en herramientas como Google Antigravity y sus agentes capaces de trabajar con archivos de proyecto. 
• El segundo es que las tareas se encadenan. Buscar un dato en la documentación del proyecto, redactar con él un texto y guardar el resultado en la carpeta correspondiente dejan de ser tres operaciones separadas por nuestra intervención. Este salto conecta directamente con la evolución de las automatizaciones con IA en arquitectura hacia sistemas capaces de ejecutar procesos completos. 
• El tercero, y el más relevante para un estudio, es que el valor se desplaza de la generación a la circulación. Lo que un despacho gana no es tanto que el modelo produzca contenido nuevo como que la información deje de detenerse en cada frontera entre aplicaciones.

---

Lo que ya utilizamos

Conviene ser concreto y hablar solo de conexiones que hemos usado en producción.

Comfy Cloud (ComfyUI). Es el ejemplo más directamente proyectual. El servidor expone la ejecución de flujos de generación de imagen: se describe la intención en la conversación y el modelo monta o recupera el flujo, lo lanza y devuelve el resultado sin abrir la interfaz de nodos. En visualización arquitectónica permite iterar variantes de una misma imagen o aplicar un modelo propio entrenado con material propio. Su límite conviene decirlo: el protocolo elimina la fricción de la interfaz, no la necesidad de saber qué se está pidiendo. 

Este enfoque, en el que la IA deja de funcionar como una herramienta aislada y pasa a integrarse dentro del proceso de diseño, forma parte del Curso en Inteligencia Artificial para Interiorismo, orientado precisamente a construir flujos de trabajo aplicables a proyectos reales. 

Google Drive. El modelo lee la documentación del proyecto donde vive: memorias, pliegos, actas, referencias. Es la conexión que más reduce el trabajo de transporte y la más fácil de justificar en un estudio.

Gmail y Google Calendar. Correspondencia y fechas: permiten preparar el seguimiento de un encargo o reconstruir el histórico de una decisión sin abrir el gestor de correo. Canva cierra el circuito por el otro extremo, llevando el material producido a un formato publicable.

Ninguna de estas conexiones es una herramienta de arquitectura, y ahí está precisamente el punto: la infraestructura documental, gráfica y administrativa que rodea a un proyecto consume una parte considerable del tiempo de estudio, y es la primera en beneficiarse.

---

Límites, permisos y confidencialidad

Un protocolo que amplía lo que un modelo puede hacer amplía también lo que puede salir mal, tres cautelas:

• Alcance. Leer no es escribir. Conceder a un modelo permiso de escritura sobre el repositorio de un proyecto exige la misma disciplina que dar permisos de edición a un colaborador que acaba de entrar: alcance mínimo, y confirmación explícita para acciones irreversibles.
• Inyección de instrucciones. Es el riesgo específico de este escenario. Un documento, un correo o incluso la descripción de una herramienta pueden contener texto dirigido al modelo con la intención de alterar su comportamiento. La regla de trabajo es sencilla: lo que el modelo lee es dato, nunca instrucción.
• Confidencialidad. La pregunta útil no es nube o local, sino qué contrato de tratamiento de datos ampara el servicio y qué garantías de cumplimiento del RGPD ofrece. Es el mismo criterio con el que el sector aceptó BIM 360, ACC o el trabajo compartido en la nube.

A ello se suma la madurez del estándar: la especificación sigue evolucionando y conviene asumir que trabajamos sobre una base joven.

---

El acceso y el método

El MCP no es una herramienta más que añadir a la lista: es la capa que permite que las demás sean alcanzables desde una conversación. Su efecto no se mide en resultados espectaculares, sino en la desaparición silenciosa de tareas de intermediación que nunca fueron proyecto.

Y encaja con lo que veníamos construyendo. Si una skill define el método (qué se consulta, en qué orden, con qué criterios y qué se entrega), el MCP proporciona el acceso. Una skill sin acceso es un método sin manos. Un acceso sin método es una herramienta sin criterio.

Integrar ambas capas, método y acceso, dentro de procesos reales es también uno de los principios del Curso en Inteligencia Artificial para Arquitectura, donde la IA se trabaja como parte del flujo completo del proyecto y no como una colección de herramientas independientes. 

---

También puede interesarte:

Agentes de IA para arquitectura: de la pregunta a delegar

Google Antigravity 2.0: la IA que por fin trabaja dentro de tu ordenador (y con tus archivos de proyecto)

Inteligencia Artificial Aplicada al Análisis de Impacto Visual Arquitectónico