MCP, Skills, Plugins y Hooks: cómo se construye realmente un agente de inteligencia artificial

La inteligencia artificial está cambiando la forma en que interactuamos con el software. Los asistentes que al principio respondían preguntas o generaban textos hoy pueden consultar bases de datos, trabajar con repositorios, ejecutar herramientas, recuperar información de sesiones anteriores y participar en procesos técnicos complejos.

Al incorporar estas capacidades aparecen términos que suelen confundirse: MCP, Skills, Plugins, Connectors y Hooks. Están relacionados, pero no son lo mismo. Entender sus diferencias permite diseñar agentes más organizados, reutilizables y seguros, sobre todo en entornos profesionales con varios proyectos y aplicaciones.

De un asistente conversacional a un sistema de agentes

Un modelo de lenguaje puede interpretar instrucciones, analizar información y elaborar respuestas. Pero por sí solo no tiene acceso ilimitado a archivos, aplicaciones ni sistemas externos. Para que intervenga en procesos reales hay que sumarle mecanismos que amplíen sus capacidades.

Imaginemos un agente de coordinación BIM que debe analizar las incidencias de un proyecto. Para hacerlo necesitaría acceder a un repositorio de modelos IFC, consultar los registros de incidencias, seguir un procedimiento de revisión, comprobar criterios de calidad y registrar los resultados. Cada función pide una solución distinta:

• El acceso a datos se resuelve con herramientas MCP.
• El procedimiento de análisis se define con una Skill.
• Una comprobación que corre cuando ocurre un evento es un Hook.
• Un Plugin puede distribuir varias de estas capacidades como una integración instalable.

La diferencia de fondo: no todos estos componentes aportan inteligencia. Algunos proporcionan herramientas, otros instrucciones y otros automatización.

MCP: la conexión entre el agente y las herramientas

MCP significa Model Context Protocol. Es un protocolo abierto que conecta aplicaciones de inteligencia artificial con herramientas, servicios y fuentes de información a través de una interfaz estandarizada. Evita construir una integración distinta para cada modelo o cliente compatible.

Un servidor MCP puede exponer herramientas para consultar datos, recuperar documentación, gestionar incidencias o ejecutar acciones autorizadas. En arquitectura, ingeniería y construcción, un agente podría usarlo para consultar información de modelos BIM, acceder a una plataforma de gestión documental o recuperar incidencias de coordinación.

Hay un detalle importante: MCP no garantiza que una herramienta sea segura ni que el modelo la use correctamente. La seguridad depende de la implementación, los permisos, la autenticación y las políticas del entorno.

Los tres alcances de MCP en Claude Code

Claude Code organiza las configuraciones MCP en tres alcances, o scopes:

• User: la configuración pertenece al usuario y vale para todos sus proyectos. Tiene sentido para herramientas generales, como una memoria persistente de uso habitual.
• Local: corresponde a un proyecto específico, pero es privada del usuario y no se comparte por el repositorio. Sirve para conexiones particulares, entornos de desarrollo o herramientas que no todo el equipo necesita.
• Project: se declara a nivel del proyecto y puede compartirse mediante un archivo como .mcp.json. Los demás colaboradores conocen los servidores previstos para ese entorno, aunque la conexión efectiva y los permisos pueden requerir aprobación.

Estos tres niveles no son una jerarquía de poder: definen el alcance de la configuración. Además, esta organización es propia de Claude Code; otras plataformas, como Codex, pueden usar archivos, mecanismos y reglas de alcance diferentes. Y un alcance Local no significa que el servidor corra físicamente en tu computadora: puede conectarse a un servicio remoto por HTTP.

Skills: enseñarle al agente cómo trabajar

Si MCP da acceso a herramientas, una Skill establece cómo desarrollar una tarea. Son paquetes reutilizables de instrucciones y recursos que orientan al agente sobre procedimientos, criterios, secuencias y resultados esperados.

Una Skill de «Auditoría BIM», por ejemplo, podría fijar un proceso que incluya comprobar la estructura de los modelos, verificar identificadores, revisar conjuntos de propiedades, identificar inconsistencias y elaborar un informe técnico. No necesita implementar cada operación: puede usar las herramientas MCP disponibles para consultar el modelo o ejecutar verificaciones.

La separación es clara: MCP responde a qué puede acceder o ejecutar el agente; una Skill orienta cómo usar esas capacidades para cumplir un objetivo. Así se reutiliza el conocimiento técnico sin repetir instrucciones extensas en cada conversación.

En organizaciones del sector, las Skills pueden sistematizar procedimientos internos de coordinación, control documental, revisión técnica o gestión de proyectos. No reemplazan la validación profesional ni garantizan el cumplimiento normativo. Su valor es estructurar procesos repetibles y hacer explícitos los criterios de trabajo, el mismo espíritu de coordinación BIM que se apoya en procedimientos definidos antes de modelar.

Plugins: organizar y distribuir capacidades

Un Plugin es un paquete instalable que puede integrar distintos componentes. Según la plataforma, incluye Skills, configuraciones MCP, recursos adicionales y mecanismos de automatización.

Un Plugin de coordinación BIM podría traer una Skill con el proceso de revisión, un servidor MCP para consultar incidencias y herramientas para generar resultados estructurados. Por eso un mismo complemento puede aparecer a la vez como plugin instalado, como servidor MCP disponible y como conjunto de Skills o Hooks. No son necesariamente instalaciones duplicadas, sino componentes distintos de una misma solución. La arquitectura exacta depende de la plataforma y de cómo se empaquetó el complemento.

Hooks: automatizar acciones cuando ocurre un evento

Los Hooks suman otra dimensión: la automatización basada en eventos. A diferencia de una herramienta que el agente decide usar, un Hook se configura para ejecutarse cuando ocurre una condición específica dentro del ciclo de trabajo.

En entornos como Claude Code hay eventos asociados al inicio de sesión, al envío de instrucciones, al uso de herramientas, al final de una respuesta y a la ejecución de subagentes. SessionStart puede cargar información del proyecto al abrir una sesión. UserPromptSubmit permite ejecutar un procedimiento cuando el usuario envía una instrucción. SubagentStop sirve para revisar o registrar resultados cuando un subagente termina.

El caso de la memoria persistente

Tomemos un agente con una herramienta de memoria persistente, como Engram. El servidor MCP ofrece las funciones para guardar y recuperar información. Pero tener esas herramientas no significa que el agente las use automáticamente en todos los momentos adecuados.

Los Hooks permiten configurar ciertos comportamientos: recuperar contexto al iniciar una sesión, procesar información en eventos definidos o intervenir alrededor de una compactación del contexto. El resultado depende de los scripts configurados, de los eventos disponibles y de si la plataforma permite ejecutarlos. La distinción es fundamental: tener un MCP de memoria conectado no equivale a tener automatizado todo el ciclo de memoria.

La seguridad: por qué no conviene habilitar todo automáticamente

Sumar herramientas amplía lo que puede hacer un agente, y también su superficie de riesgo. Un servidor MCP puede tener acceso a información sensible o permisos de escritura. Un Hook puede ejecutar scripts de Python, PowerShell o Bash. Una Skill puede contener instrucciones que orienten al agente hacia determinadas acciones.

Por eso conectar una herramienta, instalar un complemento y aprobar una ejecución son decisiones distintas. En Codex, por ejemplo, los Hooks incluidos en ciertos plugins requieren una revisión de confianza antes de ejecutarse: que el plugin esté habilitado no significa que todos sus scripts estén autorizados.

En proyectos profesionales conviene aplicar el principio de mínimo privilegio: cada agente y cada herramienta con solo los accesos necesarios para su función. También conviene separar la configuración compartible de las credenciales privadas. Declarar un servidor MCP en un proyecto no debería implicar distribuir las claves de acceso. Lo mismo vale para la responsabilidad profesional sobre lo que el agente produce, tema que tratamos en riesgos de la IA en arquitectura.

Una aplicación práctica en el entorno BIM

Pensemos en un sistema de coordinación que recibe modelos IFC de varias disciplinas y debe elaborar una revisión preliminar. La arquitectura podría organizarse así:

• Plugin: distribuye el conjunto de capacidades de coordinación.
• Skill: define el procedimiento de revisión y los criterios para presentar resultados.
• MCP: conecta al agente con el repositorio de modelos y el sistema de incidencias.
• Hook: activa ciertas comprobaciones cuando ocurre un evento compatible.
• Memoria persistente: conserva decisiones relevantes y contexto recuperable entre sesiones.

Ninguno de estos componentes sustituye a los demás. Y detectar interferencias geométricas no surge solo por conectar un MCP: hace falta un motor de análisis adecuado, reglas de comprobación y resultados verificables, como los que describimos en detección de interferencias. El agente puede coordinar esas herramientas y ayudar a interpretar los resultados, pero el rigor técnico depende de la calidad de los datos y de las operaciones implementadas. Trabajar sobre IFC y openBIM ayuda a que esos datos sean consultables por distintas herramientas.

Esta separación permite construir sistemas modulares: una organización puede cambiar su procedimiento de revisión sin reemplazar el servidor de acceso a datos, o cambiar una integración sin rehacer todas las instrucciones del agente.

Entender la arquitectura antes de aumentar la automatización

La evolución de los agentes no consiste solo en usar modelos más potentes. También implica diseñar bien los mecanismos que conectan razonamiento, información, procedimientos y acciones. MCP, Skills, Plugins y Hooks forman parte de ese ecosistema y resuelven necesidades distintas. Cuando sus responsabilidades están bien definidas, es más fácil mantener las integraciones, reutilizar procedimientos, controlar permisos y diagnosticar errores.

Para arquitectura, ingeniería y construcción, donde la trazabilidad, la interoperabilidad y el control de la información son fundamentales, la distinción pesa todavía más. Qué es real y qué es demo en este terreno lo desarrollamos en IA en arquitectura.

El desafío no es conectar la mayor cantidad posible de herramientas a un agente, sino construir una arquitectura donde cada componente tenga una función clara, verificable y proporcional a las necesidades del proceso. Un agente con más herramientas no es necesariamente mejor: su valor depende de cómo las usa, bajo qué criterios trabaja y qué controles existen sobre sus resultados.

Si querés evaluar cómo incorporar agentes y automatización a la coordinación de tus proyectos sin perder control de la información, escribinos desde la página de contacto. En nuestra sección de recursos encontrás además una checklist de coordinación BIM para ordenar los datos desde el inicio.

Preguntas frecuentes

¿Cuál es la diferencia entre MCP y una Skill?

MCP define a qué puede acceder o qué puede ejecutar un agente: consulta datos, llama a servicios, usa herramientas. Una Skill define cómo debe trabajar: el procedimiento, los criterios y el formato del resultado. Una Skill puede apoyarse en herramientas MCP, pero no las reemplaza ni las implementa por sí sola.

¿Conectar un servidor MCP significa que el agente lo usa solo y de forma segura?

No. MCP estandariza la conexión, no garantiza que el modelo use bien cada herramienta ni que esa herramienta sea segura. La seguridad depende de la implementación, los permisos, la autenticación y las políticas del entorno. Conviene dar a cada agente solo los accesos que necesita.

¿Para qué sirven los Hooks si el agente ya tiene herramientas?

Una herramienta la elige el agente cuando la necesita; un Hook se ejecuta cuando ocurre un evento definido, como el inicio de una sesión o el fin de una respuesta. Sirve para automatizar comprobaciones o cargar contexto sin depender de que el agente se acuerde de hacerlo.