De los chatbots a los agentes autónomos

La mayoría de la gente sigue usando la inteligencia artificial como un buscador mejorado: escribes una pregunta, obtienes una respuesta, fin. Pero en investigación, donde las tareas son complejas y requieren múltiples pasos, ese modelo se queda corto. Necesitas algo que haga cosas, no solo que responda cosas.

Ahí entran los agentes de IA: sistemas que usan un modelo de lenguaje como núcleo de razonamiento, pero que además tienen acceso a herramientas, capacidad de planificación y memoria. Pueden buscar en múltiples bases de datos, ejecutar código, comparar resultados, y tomar decisiones sobre qué hacer a continuación sin que tengas que darles instrucciones en cada paso.

La Guía para el uso académico de la inteligencia artificial de la UNED dedica una sección a los agentes y al estándar MCP (Model Context Protocol), y es un recurso excelente para entender hacia dónde vamos. Vamos a desgranarlo.

MCP: el «USB-C» de los agentes de IA

Hasta ahora, si querías que un asistente de IA usara una herramienta externa —una base de datos, una API, un sistema de archivos— tenías que escribir código a medida. Cada integración era un desarrollo separado. Si cambiabas de proveedor de IA, muchas integraciones se rompían.

El Model Context Protocol (MCP) es una propuesta de Anthropic para estandarizar esta comunicación. Piensa en MCP como el USB-C de los agentes: un conector universal que cualquier modelo de lenguaje puede usar para hablar con cualquier herramienta que implemente el protocolo.

En la práctica, MCP tiene tres componentes:

• Cliente MCP — el agente o modelo de lenguaje que inicia la comunicación
• Servidor MCP — el proveedor de herramientas o datos (una API de PubMed, una base de datos SQL, un sistema de archivos)
• Recursos y herramientas — lo que el servidor expone: datos que se pueden leer o acciones que se pueden ejecutar

La ventaja es inmediata: construyes un servidor MCP una vez, y cualquier agente compatible puede usarlo. Si mañana decides cambiar tu modelo de lenguaje base, las herramientas siguen funcionando.

¿Qué puedes hacer con MCP en investigación clínica?

Varias cosas que antes requerían integraciones complejas ahora pueden montarse en horas. Algunos ejemplos reales:

• Watchdog bibliográfico: un servidor MCP conectado a la API de PubMed (E-utilities) permite que tu agente busque, filtre y resuma literatura nueva cada día sin que tengas que escribir integraciones ad hoc.
• Consulta a base de datos de toxicidad: un servidor MCP sobre tu base de farmacovigilancia (o sobre un sistema PRO-CTCAE como TOXMON) permite que el agente consulte grados de toxicidad, tendencias y alertas.
• Análisis de imagen médica: un servidor MCP que expone un pipeline de segmentación (tipo MARTE) permite que un agente de IA pida análisis de imágenes DICOM sin intervención humana.
• Búsqueda federada: el agente consulta simultáneamente PubMed, ClinicalTrials.gov y tu propia base de datos local, y cruza los resultados.

Cómo diseñar tu propio asistente con MCP

Si te animas a construir tu propio asistente, el flujo es más sencillo de lo que parece. Aquí tienes los pasos prácticos:

### Paso 1: Define el caso de uso

Un solo agente, una sola tarea. Por ejemplo: «un asistente que recibe un abstract de congreso y me dice si encaja con mis líneas de investigación, justificando por qué.»

### Paso 2: Identifica las herramientas necesarias

Para ese caso: capacidad de leer texto (el abstract), acceso a una base con tus líneas de investigación (PubMed query guardada, o un vector store con tus papers favoritos), y capacidad de escribir un informe estructurado.

### Paso 3: Monta los servidores MCP

Esta es la parte más técnica, pero también la más gratificante. Cada servidor MCP es un proceso independiente que expone herramientas. La especificación es abierta, hay SDKs en Python y TypeScript, y plataformas como Flowise o Langlow permiten montar el esqueleto visualmente antes de escribir código.

### Paso 4: Configura el agente

El agente necesita saber qué herramientas tiene disponibles y cuándo usarlas. Esto se hace mediante system prompts bien diseñados — aquí aplican los principios de diseño de prompts que la UNED recoge en otra sección: contexto, claridad, especificidad.

### Paso 5: Prueba, itera, prototipa

Los agentes son impredecibles. Un mismo prompt puede funcionar un día y fallar al siguiente si cambia el modelo subyacente. La clave es probar con datos reales desde el principio, y tener un sistema de logging que te permita ver qué decisiones tomó el agente y por qué.

Ventajas para el entorno hospitalario

MCP tiene una característica que lo hace especialmente atractivo para hospitales: la seguridad por diseño. Cada servidor MCP expone solo lo que el administrador decide. Puedes tener un servidor MCP dentro de la red del hospital que da acceso a la base de datos de pacientes — pero ese servidor solo permite consultas de lectura, sin exponer los datos fuera de la red. El modelo de lenguaje que usa el agente puede ser local (como un Qwen o Llama corriendo en una GPU del hospital) y todo el tráfico se queda dentro de la institución.

Esto resuelve de golpe el problema que frena a muchos servicios de oncología: cómo aprovechar la IA sin enviar datos de pacientes a servidores externos.

Lo que la guía UNED acierta (y lo que falta)

La guía de la UNED es excelente para entender el ecosistema y tener una visión general. Acierta al incluir MCP como estándar emergente, y al mencionar plataformas low-code que bajan la barrera de entrada. Pero, como es lógico en una guía general, no profundiza en los aspectos más espinosos: la evaluación de calidad de las respuestas de un agente, la gestión de errores cuando un servidor MCP falla, o las implicaciones regulatorias (GDPR, LOPD, uso en entorno clínico) de delegar tareas en sistemas autónomos.

Aquí es donde quienes trabajamos en clínica tenemos que aportar: no solo usar las herramientas, sino documentar cómo se comportan en el mundo real, dónde fallan, y cómo hacer que sean seguras y fiables.

Para llevar a casa

MCP no es una tecnología del futuro. Está aquí, es usable hoy, y resuelve un problema real: cómo hacer que los modelos de lenguaje dejen de ser chatbots y se conviertan en herramientas de investigación que realmente hagan cosas. Si trabajas en investigación clínica, vale la pena dedicar una tarde a entender el protocolo y a montar tu primer servidor MCP. La guía de la UNED es un buen mapa de carreteras. El resto es ponerse a conducir.

Soy Javier Pumares, oncólogo médico en el Centro Oncológico de Galicia. Escribo aquí sobre la intersección entre oncología, inteligencia artificial y práctica clínica real. Si te ha parecido útil, puedes seguirme en LinkedIn o suscribirte al blog en ppj.es.