Cuando hablamos del protocolo MCP (Model Context Protocol), todos pensamos en IA, LLMs y agentes que hablan con herramientas mediante este «lenguaje».
Pero y si te digo que tras analizarlo, le veo un punto más humano, más natural de lo que habías imaginado.
En ingeniería del software cuando te pones a tomar requisitos, construir la arquitectura, analizar los flujos y funcionalidades que va a tener tu software, uno de los diagramas que se suele usar en UML, es el diagrama de Casos de Uso, si, ese del muñequito
Que se suele usar para ir definiendo y descubriendo las funcionalidades que cada actor o role podrá hacer en el software.
En un modelo clásico, esto nos valía para, sabiendo lo que el actor quiere conseguir, poder bajarlo a funcionalidades, funcionalidades que probablemente se viesen finalmente bajadas a funciones o incluso endpoints en APIs.
Pasando de un :
Actor: Administrador
Caso de uso: Crear factura
Desglosado:
- El administrador selecciona un cliente.
- Añade productos.
- El sistema calcula impuestos.
- Se genera la factura.
- Se guarda.
Que al final se traducirá en diseño de sistema:
API / funciones / BBDD
Es decir, hemos hecho el viaje:
Intención humana –> especificación –> diseño –> funciones técnicas
Un camino natural cuando bajamos a tierra lo que queremos construir, pero un camino que cada vez nos acerca más a lo técnico, lo cual nos aleja más de lo humano.
Este camino nos llevaría a construir una API por ejemplo:
POST /invoices
GET /invoices/{id}
Y hasta aquí no hay nada malo, es más, hemos construido software así durante décadas.
Pero hemos pasado de un «quiero crear una factura», a métodos HTTP, endpoints, parámetros ….
Si volvemos al principio del proceso, el usuario nunca pensó en endpoints, ni funciones, él pensó:
Quiero crear una factura
Es decir, el actor piensa qué quiere, no cómo conseguirlo.
Si miras el diagrama inicial de casos de uso, eso es precisamente lo que representa.
En este sistema clásico de definición de funciones / API … software, la pregunta que se resuelve es:
¿Cómo accedo al sistema?
Pensamos en el modelo de datos, y como podemos construir puertas para conseguir lo que el usuario quiere, o como otros software obtiene dicha info.
Ahora vayamos al modelo de MCP.
En este caso, el consumidor va a ser a priori un Agente IA.
Y cuando diseñamos para él, realmente los casos de uso van a ser los mismos:
Crear factura / Obtener factura / ver informe
Pero en este caso la pregunta que queremos resolver es:
¿qué puede hacer el actor (agente) con el sistema?
Si intentas contestarla, tu mente se queda en los distintos nodos del diagrama de casos de uso, es decir, tu mente se queda en ese nivel de abstracción.
No le hace falta bajar al modelo de datos, para saber que una factura tiene un cliente asociado y por consiguiente tiene que haber un endpoint GET /clients …
Evidentemente esto no significa que una tool de MCP tenga que corresponder exactamente con un caso de uso.
Pero conceptualmente existe una similitud muy interesante:
Ambos nos permiten pensar en términos de capacidades que un actor puede realizar, en vez de pensar en detalles de implementación.
Durante años hemos ido transformando intenciones humanas en abstracciones cada vez más técnicas:
intención → caso de uso → diseño → servicio → función → endpoint
Ahora aparece un nuevo tipo de consumidor: un agente capaz de interpretar intenciones.
Y resulta curioso que, para conectar estos agentes con nuestros sistemas, estemos recuperando una forma de describirlos que nos resulta muy familiar:
¿Qué puede hacer un actor con este sistema?
Y esto ya no va de «tecnología MCP», sino de modelo de abstracción MCP, más cercano al humano, más cercano al natural.
Quizá por eso MCP me parece un protocolo más humano de lo que parece.
Y si te estás preguntando cómo podría quedar este mismo sistema de facturación llevado a tierra, podríamos tener algo así:
Mismo sistema. Distinta forma de exponerlo.
La API nos acerca a la implementación y a los recursos del sistema.
MCP nos permite exponer las capacidades que un agente puede utilizar.
Y quizá ahí esté precisamente la parte «humana» de MCP.