Loom & Logic
Compartir

La forma más limpia y rápida de “abrir” tu aplicación a la IA

Hace unos días comentaba que, cuando trabajamos con agentes de IA, la arquitectura del código también forma parte del prompt.

Hoy me gustaría ir un paso más allá.

Y ahí es donde creo que MCP (Model Context Protocol) encaja de forma especialmente elegante.

Integrar IA no debería significar reescribir la aplicación

Cuando aparece una nueva tecnología solemos preguntarnos dónde debe vivir dentro de la arquitectura.

Con la IA está ocurriendo exactamente eso.

He visto muchos ejemplos donde “integrar IA” significa añadir llamadas a un LLM desde cualquier parte del código, crear servicios específicos para el chatbot o incluso permitir que un agente consulte directamente la base de datos.

Personalmente creo que ese enfoque rompe una de las cosas más valiosas que tenemos: una buena separación de responsabilidades.

Si una aplicación ya está bien diseñada, probablemente no necesite cambiar su arquitectura para trabajar con agentes.

Solo necesita una nueva puerta de entrada.

Y eso es precisamente lo que representa MCP.

Antes de hablar de arquitectura, conviene aclarar qué es MCP.

MCP (Model Context Protocol) es un estándar abierto que permite exponer las capacidades de una aplicación para que los agentes de IA puedan descubrirlas y utilizarlas de forma segura y estructurada.

No define la lógica del negocio ni sustituye a una API. Define cómo un agente conversa con una aplicación.

MCP es un adaptador más

Si trabajas con Arquitectura Hexagonal seguramente esta idea te resulte familiar.

Una aplicación ya suele tener distintas formas de ser utilizada:

  • una API REST
  • un consumidor de eventos
  • una interfaz CLI
  • un proceso batch
  • una interfaz web

Todas hacen exactamente lo mismo.

Traducen una petición externa hacia un caso de uso de la aplicación.

Desde ese punto de vista, MCP no es algo diferente.

Es simplemente otro adaptador de entrada.

No sustituye la API.

No modifica el dominio.

No contiene reglas de negocio.

Simplemente permite que un nuevo tipo de consumidor —los agentes de IA— pueda utilizar exactamente la misma aplicación.

Lo bonito de este enfoque es que el dominio ni siquiera necesita saber que existe MCP.

Para él siguen existiendo exactamente los mismos casos de uso:

  • Obtener transacciones
  • Diagnosticar recargas fallidas
  • Bloquear una tarjeta
  • Generar un informe

La única diferencia es quién los invoca:

  • Antes podían hacerlo una API, un proceso batch o un consumidor de eventos.
  • Ahora también puede hacerlo un agente. Y eso mantiene intacto uno de los principios fundamentales de la arquitectura hexagonal: el dominio nunca depende de quién llama.

CQRS hace que el encaje sea todavía más natural

En los proyectos donde utilizo CQRS, la integración con MCP resulta casi inmediata.

Las herramientas que exponemos al agente terminan siendo simplemente otra forma de ejecutar los mismos Commands y Queries que ya existen.

Tool MCP [find_failed_recharges()] -> GetFailedRechargesQuery
Tool MCP [block_card()] -> BlockCardCommand
  • No aparece una lógica paralela para IA.
  • No duplicamos comportamiento.
  • No escribimos una segunda implementación.

Y eso hace que el software siga siendo sencillo de mantener.

Lo interesante no es el protocolo

Cuando se habla de MCP muchas veces la conversación gira alrededor del protocolo.

Sinceramente, creo que esa es la parte menos interesante.

Lo realmente importante es el cambio de perspectiva.

Hasta ahora diseñábamos aplicaciones para ser consumidas por personas o por otros sistemas.

Con MCP aparece un nuevo consumidor: los agentes.

Y eso abre posibilidades muy interesantes.

  • Un agente ya no necesita consultar directamente la base de datos.
  • No necesita ejecutar SQL.
  • No necesita conocer la estructura interna del proyecto.

Solo necesita descubrir las capacidades que la propia aplicación decide exponer.

Por ejemplo:

  • Buscar transacciones
  • Diagnosticar una incidencia
  • Obtener el estado de una empresa
  • Consultar métricas
  • Reintentar un proceso
  • Comparar consumos entre períodos

Todas esas capacidades ya existían. MCP simplemente las convierte en herramientas que un agente puede descubrir y utilizar.

Quizá sea la forma más sencilla de empezar con IA

Muchas organizaciones quieren incorporar IA cuanto antes. Y es normal que el primer impulso sea pensar en un chatbot o en un copiloto.

Sin embargo, creo que existe un paso previo mucho más interesante: hacer que las aplicaciones existentes sean capaces de conversar con agentes.

Por ejemplo, un agente podría:

  • diagnosticar incidencias
  • investigar operaciones fallidas
  • cruzar información entre varios microservicios
  • ayudar a un operador durante una investigación
  • automatizar tareas repetitivas apoyándose siempre en los casos de uso existentes

✅ La inteligencia permanece fuera.

✅ Las reglas permanecen dentro.

Y esa separación me parece tremendamente potente.

La arquitectura vuelve a cobrar protagonismo

En mi artículo anterior defendía que una arquitectura limpia ayuda a los agentes a comprender mejor un proyecto.

Creo que MCP lleva esa idea un paso más allá. Una buena arquitectura no solo facilita que la IA modifique el código. También facilita que la IA utilice correctamente la aplicación. Porque el adaptador MCP no necesita inventarse nuevas reglas. Simplemente expone las que ya existen.

Y eso, desde mi punto de vista, es precisamente la mayor virtud de una arquitectura hexagonal. No obliga a cambiar el corazón del sistema. Simplemente añade una nueva forma de hablar con él.

Una reflexión final

Cada vez estoy más convencido de que la revolución de la IA no llegará porque llenemos nuestros microservicios de llamadas a modelos.

Llegará porque nuestros sistemas empiecen a ser consumibles por agentes de la misma forma que hoy lo son por APIs, aplicaciones web o procesos batch.

MCP me parece un excelente primer paso para conseguirlo. No porque haga inteligente a la aplicación. Sino porque convierte sus capacidades en algo descubrible, reutilizable y orquestable por agentes.

Y si además ya trabajas con Arquitectura Hexagonal y CQRS, probablemente descubras que no necesitas reinventar nada. Solo añadir un nuevo adaptador. Uno pensado para un nuevo tipo de cliente: los agentes de IA.

Conversación

Comparte una idea, pregunta o mejora sobre esta publicación.

Únete a la conversación

Your email address will not be published. Required fields are marked *