Hay veces que no entrás a un tema porque lo venís estudiando hace meses.
Entrás porque alguien te cuenta algo en una charla y te deja pensando.
Eso fue lo que me pasó con los MCP.
En una conversación, alguien comentó que había armado un MCP para probar su app desde el lado de QA.
No me acuerdo la frase exacta, pero sí del efecto: me quedó picando enseguida.
Porque una cosa es escuchar “IA” en abstracto, y otra muy distinta es ver un caso concreto donde un protocolo, unas tools bien pensadas y un flujo claro te permiten conectar un asistente con algo que realmente usás.
Y ahí empecé a meterme más en ese mundo: MCP, tools, resources, hosts, agentes y toda esa capa que empieza a darle más estructura a cómo trabajamos con IA.
Qué es un MCP
La definición corta es esta: MCP (Model Context Protocol) es un estándar abierto para conectar aplicaciones de IA con sistemas externos.
O dicho más simple: es una forma estándar de hacer que un cliente compatible pueda usar herramientas, leer recursos o ejecutar acciones fuera del chat.
En la documentación oficial lo comparan con una especie de “USB-C para aplicaciones de IA”.
La comparación sirve: apunta a tener una forma estándar de conectar cosas distintas sin inventar una integración nueva cada vez.
Si querés la intro oficial, está acá:
Entonces, ¿para qué sirve?
Sirve para que la IA no quede limitada a responder texto.
Con MCP, un cliente puede conectarse a cosas reales:
- archivos,
- bases de datos,
- APIs,
- tableros,
- calendarios,
- herramientas propias,
- o cualquier integración que tenga sentido para tu flujo.
Y ahí aparecen también las tools.
Las tools son, básicamente, las acciones que ese cliente puede ejecutar: buscar, crear, mover, comentar, consultar, validar.
Lo importante es que define un contrato claro entre el cliente y las herramientas.
Y eso me gusta.
Porque cuando hay contrato, hay menos improvisación. Y cuando hay menos improvisación, bajan bastante las chances de armar un quilombo difícil de mantener.
Lo que me atrapó de verdad
Lo que más me interesó no fue solo la parte técnica del protocolo.
Fue pasar de “preguntarle cosas a una IA” a tenerla conectada a un contexto donde puede hacer acciones concretas.
Ahí ya no estás solo charlando.
Estás diseñando una integración: qué puede hacer, con qué límites, sobre qué sistema y bajo qué reglas.
Menos prueba y error a ciegas.
Más diseño de integración.
Y sinceramente, esa parte me interesa bastante más que quedarse en la novedad.
Mi caso: un MCP para Trello adaptado a mi forma de laburar
Con esa curiosidad dando vueltas, terminé armando este proyecto:
La idea no fue venderlo como si hubiera inventado algo inédito. Ni en pedo.
Seguro hay más gente que hizo integraciones parecidas. El punto no era la originalidad absoluta.
El punto era adaptarlo a mis necesidades reales.
Quería una integración que me sirviera para trabajar con Trello desde un cliente compatible con MCP sin depender de procesos manuales para todo.
Según el README actual del repo, el servidor está hecho en Node.js + TypeScript, integra con la Trello REST API y hoy ya expone tools para buscar tarjetas, agregar comentarios, listar boards, crear tarjetas, moverlas, borrarlas y sumar labels, además de recursos asociados al board.
Ahí deja de ser algo para mostrar.
Pasa a ser una herramienta que puede entrar en el laburo de todos los días.
Lo importante no fue “hacer un MCP”
Para mí, lo más valioso de meterme en esto no fue solamente publicar un repo más.
Fue entender mejor esta capa de trabajo:
- qué problema quiero resolver,
- qué acciones tiene sentido exponer como tools,
- qué límites necesita la integración,
- y cómo hacer que algo así sea mantenible en vez de quedar como experimento de fin de semana.
Ahí está la diferencia entre jugar con una novedad y construir algo que te sirva de verdad.
Cierre
A veces una charla te deja una idea dando vueltas.
Y si la seguís un poco, esa idea te abre una puerta nueva.
En mi caso, esa puerta fue el mundo de los MCP, las tools y las integraciones pensadas con criterio.
Arrancó por curiosidad.
Terminó en un proyecto propio adaptado a cómo laburo.
Y creo que esa es una de las mejores formas de aprender tecnología: no quedarse mirando desde afuera, sino agarrar algo que te intrigue, llevarlo a un caso concreto y hacerlo funcionar en tu terreno.