Forem: Cecy Geraldo

𝘚𝘋𝘋 𝘷𝘪𝘯𝘰 𝘢 𝘤𝘢𝘮𝘣𝘪𝘢𝘳 𝘯𝘶𝘦𝘴𝘵𝘳𝘰 𝘧𝘭𝘶𝘫𝘰 𝘥𝘦 𝘥𝘦𝘴𝘢𝘳𝘳𝘰𝘭𝘭𝘰 🤯

Cecy Geraldo — Sat, 11 Apr 2026 22:53:39 +0000

⁣⁣Hace unas semanas tuvimos una iniciativa en el trabajo donde nos enseñaron el flujo de 𝐒𝐃𝐃 con ̲𝙶̲̲𝚒̲̲𝚝̲̲𝚑̲̲𝚞̲̲𝚋̲ ̲𝚂̲̲𝚙̲̲𝚎̲̲𝚌̲ ̲𝚔̲̲𝚒̲̲𝚝̲, 𝘧𝘶𝘦𝘳𝘰𝘯 𝘥𝘰𝘴 𝘴𝘦𝘮𝘢𝘯𝘢𝘴 𝘣𝘪𝘦𝘯 𝘪𝘯𝘵𝘦𝘳𝘦𝘴𝘢𝘯𝘵𝘦𝘴, el primer día hicimos el setup en nuestras máquinas y nuestros repos -𝘥𝘢𝘥𝘰 𝘲𝘶𝘦 𝘩𝘢𝘣í𝘢𝘯 𝘢𝘳𝘤𝘩𝘪𝘷𝘰𝘴 𝘲𝘶𝘦 𝘴𝘦 𝘵𝘦𝘯í𝘢𝘯 𝘲𝘶𝘦 𝘴𝘶𝘣𝘪𝘳, 𝘥𝘦 𝘤𝘰𝘯𝘧𝘪𝘨𝘶𝘳𝘢𝘤𝘪ó𝘯 𝘱𝘢𝘳𝘢 𝘢𝘨𝘦𝘯𝘵𝘦𝘴- empezamos a entender los comandos de 𝐆𝐢𝐭𝐇𝐮𝐛 𝐒𝐩𝐞𝐜𝐊𝐢𝐭: /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝖼𝗈𝗇𝗌𝗍𝗂𝗍𝗎𝗍𝗂𝗈𝗇, /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗌𝗉𝖾𝖼𝗂𝖿𝗒, /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗉𝗅𝖺𝗇 , /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗍𝖺𝗌𝗄𝗌 𝗒 /𝗌𝗉𝖾𝖼𝗄𝗂𝗍.𝗂𝗆𝗉𝗅𝖾𝗆𝖾𝗇𝗍; 𝐜𝐮á𝐥 𝐞𝐫𝐚 𝐞𝐥 𝐟𝐥𝐮𝐣𝐨 𝐝𝐞 𝐒𝐃𝐃 𝐲 𝐭𝐚𝐦𝐛𝐢é𝐧 𝐞𝐥 𝐨𝐫𝐝𝐞𝐧 𝐲 𝐞𝐥 𝐨𝐛𝐣𝐞𝐭𝐢𝐯𝐨 𝐝𝐞 𝐜𝐚𝐝𝐚 𝐜𝐨𝐦𝐚𝐧𝐝𝐨. ⁣⁣
⁣⁣
Y ya cuando íbamos a partir con nuestra épica a desarrollar, 𝐧𝐨𝐬 𝐝𝐢𝐦𝐨𝐬 𝐜𝐮𝐞𝐧𝐭𝐚 𝐪𝐮𝐞 𝐚ú𝐧 𝐧𝐨𝐬 𝐟𝐚𝐥𝐭𝐚𝐛𝐚 𝐢𝐧𝐟𝐨𝐫𝐦𝐚𝐜𝐢ó𝐧 𝐝𝐞 𝐪𝐮é 𝐪𝐮𝐞𝐫í𝐚𝐦𝐨𝐬 𝐡𝐚𝐜𝐞𝐫 𝐲 𝐜ó𝐦𝐨, 𝐩𝐚𝐫𝐚 𝐩𝐨𝐝𝐞𝐫 𝐜𝐫𝐞𝐚𝐫 𝐥𝐚𝐬 𝐒𝐩𝐞𝐜𝐬 𝐚𝐬í 𝐪𝐮𝐞 𝐝𝐢𝐦𝐨𝐬 𝐮𝐧 𝐩𝐚𝐬𝐨 𝐚𝐭𝐫á𝐬. ⁣⁣
⁣⁣
Dejamos el IDE de lado y nos reunimos todo el equipo, a como después lo llamé “𝐟𝐮𝐥𝐥-𝐭𝐞𝐚𝐦-𝐟𝐮𝐥𝐥-𝐭𝐢𝐦𝐞” por un día y medio, 𝐭𝐨𝐝𝐨𝐬 𝐧𝐮𝐞𝐬𝐭𝐫𝐨𝐬 𝐜𝐞𝐫𝐞𝐛𝐫𝐨𝐬 𝐣𝐮𝐧𝐭𝐨𝐬: 𝘗𝘳𝘰𝘥𝘶𝘤𝘵 𝘔𝘢𝘯𝘢𝘨𝘦𝘳, 𝘗𝘳𝘰𝘥𝘶𝘤𝘵𝘰 𝘋𝘦𝘴𝘪𝘨𝘯𝘦𝘳𝘴 𝘺 𝘱𝘦𝘳𝘴𝘰𝘯𝘢𝘴 𝘥𝘦 𝘐𝘯𝘨𝘦𝘯𝘪𝘦𝘳í𝘢-𝘋𝘦𝘴𝘢𝘳𝘳𝘰𝘭𝘭𝘰 a hacer un discovery acompañado también de una lluvia de ideas. ⁣⁣
⁣⁣
Intentando responder las preguntas ¿𝐡𝐚𝐜𝐢𝐚 𝐝ó𝐧𝐝𝐞 𝐪𝐮𝐞𝐫𝐞𝐦𝐨𝐬 𝐥𝐥𝐞𝐠𝐚𝐫? ¿𝐂𝐮á𝐥𝐞𝐬 𝐬𝐨𝐧 𝐥𝐚𝐬 𝐟𝐫𝐢𝐜𝐜𝐢𝐨𝐧𝐞𝐬 𝐨 𝐩𝐮𝐧𝐭𝐨𝐬 𝐝𝐞 𝐝𝐨𝐥𝐨𝐫 𝐪𝐮𝐞 𝐲𝐚 𝐜𝐨𝐧𝐨𝐜𝐞𝐦𝐨𝐬 𝐝𝐞 𝐧𝐮𝐞𝐬𝐭𝐫𝐨 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐨? ¿𝐐𝐮é 𝐜𝐨𝐬𝐚𝐬 𝐚𝐲𝐮𝐝𝐚𝐫í𝐚𝐧 𝐚 𝐥𝐚𝐬 𝐩𝐞𝐫𝐬𝐨𝐧𝐚𝐬 𝐃𝐞𝐯𝐬 𝐚 𝐮𝐭𝐢𝐥𝐢𝐳𝐚𝐫 𝐦á𝐬 𝐲 𝐦𝐞𝐣𝐨𝐫 𝐧𝐮𝐞𝐬𝐭𝐫𝐚 𝐩𝐥𝐚𝐭𝐚𝐟𝐨𝐫𝐦𝐚? ¿𝐇𝐚𝐜𝐢𝐚 𝐝ó𝐧𝐝𝐞 𝐢𝐦𝐚𝐠𝐢𝐧𝐚𝐦𝐨𝐬 𝐪𝐮𝐞 𝐩𝐨𝐝𝐫í𝐚 𝐜𝐫𝐞𝐜𝐞𝐫 𝐞𝐥 𝐚𝐥𝐜𝐚𝐧𝐜𝐞 𝐝𝐞 𝐧𝐮𝐞𝐬𝐭𝐫𝐨 𝐩𝐫𝐨𝐝𝐮𝐜𝐭𝐨? Y en ese día y medio, intentamos encontrar esas respuestas para luego bajar al nivel de implementación y plantearnos cómo podíamos hacer para crear soluciones y mejorías para que las respuestas a nuestras preguntas se vieran reflejadas en el “makeover” de nuestra plataforma. ⁣⁣
⁣⁣
𝐓𝐞𝐧𝐢𝐞𝐧𝐝𝐨 𝐮𝐧 𝐦𝐞𝐣𝐨𝐫 𝐞𝐧𝐭𝐞𝐧𝐝𝐢𝐦𝐢𝐞𝐧𝐭𝐨 𝐲 𝐦á𝐬 𝐩𝐫𝐨𝐟𝐮𝐧𝐝𝐨, 𝐝𝐞𝐥 𝐪𝐮é 𝐲 𝐜ó𝐦𝐨, 𝐧𝐨𝐬 𝐚𝐲𝐮𝐝ó 𝐚 𝐚𝐯𝐚𝐧𝐳𝐚𝐫 𝐦𝐞𝐣𝐨𝐫 𝐜𝐨𝐧 𝐥𝐚𝐬 𝐒𝐩𝐞𝐜𝐬, 𝐜𝐨𝐧 𝐦á𝐬 𝐝𝐞𝐭𝐚𝐥𝐥𝐞, 𝐦á𝐬 𝐜𝐨𝐦𝐩𝐥𝐞𝐭𝐚𝐬 𝐲 𝐚 𝐥𝐚 𝐯𝐞𝐳 𝐦á𝐬 𝐠𝐫𝐚𝐧𝐮𝐥𝐚𝐫𝐞𝐬, 𝐟𝐮𝐢𝐦𝐨𝐬 𝐩𝐨𝐫 𝐥𝐨 𝐦á𝐬 𝐩𝐞𝐪𝐮𝐞ñ𝐨, 𝐜𝐚𝐝𝐚 𝐢𝐦𝐩𝐫𝐨𝐯𝐞𝐦𝐞𝐧𝐭, 𝐜𝐚𝐝𝐚 𝐟𝐮𝐧𝐜𝐢𝐨𝐧𝐚𝐥𝐢𝐝𝐚𝐝, 𝐛𝐢𝐞𝐧 𝐩𝐞𝐪𝐮𝐞ñ𝐨 𝐲 𝐝𝐞𝐭𝐚𝐥𝐥𝐚𝐝𝐨, 𝐭𝐚𝐦𝐛𝐢é𝐧 𝐫𝐞𝐜𝐨𝐫𝐝𝐚𝐧𝐝𝐨 𝐪𝐮𝐞 𝐞𝐬 𝐩𝐫𝐢𝐦𝐞𝐫𝐚 𝐯𝐞𝐳 𝐪𝐮𝐞 𝐞𝐬𝐭á𝐛𝐚𝐦𝐨𝐬 𝐜𝐨𝐧𝐨𝐜𝐢𝐞𝐧𝐝𝐨 𝐲 𝐬𝐢𝐠𝐮𝐢𝐞𝐧𝐝𝐨 𝐞𝐬𝐭𝐞 𝐟𝐥𝐮𝐣𝐨 𝐝𝐞 𝐒𝐩𝐞𝐜 𝐃𝐫𝐢𝐯𝐞𝐧 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭. ⁣⁣
⁣⁣
Intentamos hacerlo con “𝘨𝘳𝘦𝘦𝘯 𝘧𝘪𝘦𝘭𝘥” -𝘶𝘯 𝘳𝘦𝘱𝘰 𝘯𝘶𝘦𝘷𝘰, 𝘷𝘢𝘤í𝘰 𝘺 𝘱𝘢𝘳𝘵𝘪𝘳 𝘥𝘦𝘴𝘥𝘦 𝘤𝘦𝘳𝘰, 𝘵𝘪𝘱𝘰 “𝘦𝘯 𝘣𝘭𝘢𝘯𝘤𝘰”- así como también con “𝘣𝘳𝘰𝘸𝘯 𝘧𝘪𝘦𝘭𝘥” -𝘤𝘰𝘯 𝘦𝘭 𝘳𝘦𝘱𝘰 𝘢𝘤𝘵𝘶𝘢𝘭 𝘲𝘶𝘦 𝘺𝘢 𝘵𝘦𝘯í𝘢 𝘯𝘶𝘦𝘴𝘵𝘳𝘰 𝘱𝘳𝘰𝘥𝘶𝘤𝘵𝘰- y con esa experiencia, el explorar cuál era la mejor alternativa, luego de avanzar con el repo nuevo decidimos pivotear al original y trasladar esos avances, ese aprendizaje sobre las Specs hacia el repo original. ⁣⁣
⁣⁣
𝐀𝐩𝐫𝐞𝐧𝐝𝐢𝐦𝐨𝐬 𝐦𝐮𝐜𝐡𝐨, ¿𝐟𝐮𝐞 𝐮𝐧𝐚 𝐬𝐞𝐦𝐚𝐧𝐚 𝐢𝐧𝐭𝐞𝐧𝐬𝐚? 𝐓𝐚𝐦𝐛𝐢é𝐧. Así como todo lo nuevo “incomoda” también compartimos esos aprendizajes y esta “nueva forma de hacer el código” nos llevó a algunas reflexiones: ⁣⁣
⁣⁣
👉 𝐄𝐥 𝐟𝐥𝐮𝐣𝐨 𝐝𝐞 𝐝𝐞𝐬𝐚𝐫𝐫𝐨𝐥𝐥𝐨 𝐪𝐮𝐞 𝐥𝐥𝐞𝐯á𝐛𝐚𝐦𝐨𝐬 𝐜𝐨𝐧 𝐈𝐀 𝐲 𝐕𝐢𝐛𝐞 𝐂𝐨𝐝𝐢𝐧𝐠, 𝐜𝐚𝐦𝐛𝐢𝐚𝐧 𝐭𝐨𝐭𝐚𝐥𝐦𝐞𝐧𝐭𝐞 𝐜𝐨𝐧 𝐒𝐃𝐃⁣⁣
👉Ya no es que tomemos una tarea, que venga con el “qué se espera” desde al área de producto y desde el área de Ingeniería-Desarrollo decidamos o descubramos el cómo, haciendo un ping pong con el agente de IA, pidiendo que haga un análisis de posibilidades, que implemente una solución, que la mejore, la refactorice, haga los test, etc.. 𝐀𝐡𝐨𝐫𝐚 𝐭𝐞𝐧𝐞𝐦𝐨𝐬 𝐪𝐮𝐞 𝐭𝐞𝐧𝐞𝐫 𝐞𝐬𝐨 𝐜𝐥𝐚𝐫𝐨 𝐃𝐄𝐒𝐃𝐄 𝐔𝐍 𝐂𝐎𝐌𝐈𝐄𝐍𝐙𝐎, 𝐭𝐚𝐧𝐭𝐨 𝐥𝐚 𝐯𝐢𝐬𝐢ó𝐧 𝐝𝐞 𝐃𝐢𝐬𝐞ñ𝐨, 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐨 𝐞 𝐈𝐧𝐠𝐞𝐧𝐢𝐞𝐫í𝐚-𝐃𝐞𝐬𝐚𝐫𝐫𝐨𝐥𝐥𝐨, 𝐚𝐬í 𝐭𝐞𝐧𝐞𝐫 𝐮𝐧𝐚𝐬 𝐒𝐩𝐞𝐜𝐬 𝐬ó𝐥𝐢𝐝𝐚𝐬 𝐲 𝐜𝐨𝐦𝐩𝐥𝐞𝐭𝐚𝐬, 𝐪𝐮𝐞 𝐫𝐞𝐟𝐥𝐞𝐣𝐞𝐧 𝐞𝐬𝐭𝐚 𝐯𝐢𝐬𝐢ó𝐧 𝐝𝐞 𝐟𝐨𝐫𝐦𝐚 𝐭𝐫𝐚𝐧𝐬𝐯𝐞𝐫𝐬𝐚𝐥⁣⁣
👉 ̲𝙽̲̲𝚞̲̲𝚎̲̲𝚜̲̲𝚝̲̲𝚛̲̲𝚘̲ ̲𝚏̲̲𝚕̲̲𝚞̲̲𝚓̲̲𝚘̲ ̲𝚍̲̲𝚎̲ ̲𝚝̲̲𝚛̲̲𝚊̲̲𝚋̲̲𝚊̲̲𝚓̲̲𝚘̲ ̲𝚌̲̲𝚊̲̲𝚖̲̲𝚋̲̲𝚒̲ó, el proceso que llevábamos se cambió por uno diferente⁣⁣
👉 𝐀ú𝐧 𝐬𝐞𝐠𝐮𝐢𝐦𝐨𝐬 𝐚𝐩𝐫𝐞𝐧𝐝𝐢𝐞𝐧𝐝𝐨 𝐲 𝐝𝐞𝐬𝐜𝐮𝐛𝐫𝐢𝐞𝐧𝐝𝐨, el alcance, los límites, las posibilidades, las mejoras de este flujo y también de el Toolkit de GitHub Speckit ⁣⁣
⁣⁣
𝘌𝘯𝘵𝘰𝘯𝘤𝘦𝘴, ¿𝘢𝘩𝘰𝘳𝘢 𝘲𝘶é? 𝐀 𝐬𝐞𝐠𝐮𝐢𝐫 𝐚𝐩𝐫𝐞𝐧𝐝𝐢𝐞𝐧𝐝𝐨 𝐲 𝐜𝐨𝐦𝐩𝐚𝐫𝐭𝐢𝐫 𝐞𝐬𝐭𝐨𝐬 𝐚𝐩𝐫𝐞𝐧𝐝𝐢𝐳𝐚𝐣𝐞𝐬 𝐞𝐧 𝐞𝐥 𝐜𝐚𝐦𝐢𝐧𝐨, ver cuáles son las mejores alternativas y también 𝐞𝐯𝐚𝐥𝐮𝐚𝐫 𝐥𝐨𝐬 𝐫𝐞𝐬𝐮𝐥𝐭𝐚𝐝𝐨𝐬 que este nuevo flujo nos trae a nuestro día a día 🤝⁣⁣
⁣⁣
Así que decidí hacer este post (𝘥𝘦𝘴𝘥𝘦 𝘲𝘶𝘦 𝘩𝘢𝘣𝘭𝘦 𝘥𝘦 𝘈𝘨𝘦𝘯𝘵 𝘚𝘬𝘪𝘭𝘭𝘴 𝘤𝘰𝘯 𝘊𝘭𝘢𝘶𝘥𝘦) cuando hice mención al archivo ̲𝚌̲̲𝚘̲̲𝚗̲̲𝚜̲̲𝚝̲̲𝚒̲̲𝚝̲̲𝚞̲̲𝚝̲̲𝚒̲̲𝚘̲̲𝚗̲.̲𝚖̲̲𝚍̲ donde almacenamos las reglas no negociables de nuestro repo, el que NO debe hacer y el que SI O SI debe hacer -𝘱𝘶𝘴𝘦 𝘶𝘯𝘰𝘴 𝘦𝘫𝘦𝘮𝘱𝘭𝘰𝘴 𝘦𝘯 𝘭𝘢𝘴 𝘴𝘭𝘪𝘥𝘦𝘴- así como también la importancia de este documento y la ventaja que trae: no tienes que recordárselo, cada trozo de código que modifique, mejore o cree será con estas reglas de base, sin que tengas que repetírselo como instrucción en un Prompt una y otra vez. ☝️🤓⁣⁣
⁣⁣
Cuéntame si ya has utilizado o si conocías este flujo y qué cosas te han parecido interesantes 💡✨⁣⁣
También hice este post en instagram con algunos conceptos y pasos del flujo de SDD con Github SpecKit
Les leo! 👀⁣⁣

🧠 What’s the deal with MCP? And why you should start exploring it now

Cecy Geraldo — Sun, 27 Jul 2025 02:25:21 +0000

A couple of weeks ago, I started hearing more and more about something called Model Context Protocol (MCP). Actually, the first thing I saw was a TikTok by ChicaPython, and from that I kind of understood that MCP was like an API… but for communicating with LLMs (Large Language Models) 🤯.

Then I started googling and found the official documentation, with several readings on the architecture of the protocol. From there, with some examples and tutorials using Claude, I jumped into the practical side.

And here’s what makes it powerful: MCP is a standard protocol, declared in November 2024 (so yeah, pretty recent). And being a standard means it’s here to stay. From now on, this is how we communicate with LLMs, not just to consume services like when we used the Gemini API to create an agent. We now use MCP to boost communication and increase model operability.

With MCP, you can create an agent and, through an MCP server, give it specific permissions to perform concrete actions. For example, you can authorize an agent to read and write files in a local folder—it can pull information from there and save outputs too. And the best part is, thanks to the Open Source community, there are already tons of MCP servers available:

To connect with GitHub and have the agent build a Pull Request for you (like Jules, the copilot presented by Google at this year’s I/O),
To read a database,
Or to automate tasks like checking issues, generating reports, and much more.

🟡 Side note: As with anything powerful, use it with good judgment. Review carefully what permissions you’re giving before using third-party MCPs. You might be exposing more than you think. (Let’s bring back the classic phrase: “With great power comes great responsibility.”)

💡 What I loved the most

You don’t need a powerful machine, weird programs, or to learn a brand-new language. None of that.

You can work locally, run the MCP inspector, and test what you’re building in TypeScript, for example or any compatible language (I’ll drop them at the end of the article). You can even configure an existing MCP with a simple JSON file. Easy-peasy.

You can also test the tools you develop directly integrated into Claude, for free.

That’s how I created my first MCP server in TypeScript, following a tutorial by Midu. I used a local viewer to test tools, activated developer view in Claude to test what I was building, automated GitHub pull requests using @modelcontextprotocol/server-github, and managed to create an agent connected to a weather API that gave me real-time weather for any city I asked about. I also accessed the local file system to read and save files in a controlled way.

The most exciting part? Just with the ability to read and write files, you can give your model context with information in directory X and save the synthesized results of your queries to directory Y.

All under control. No hallucinations. Clear steps.

All from your local machine!

Here’s an example of how the MCP config looks when enabling access to your file system, like giving it permission to read your Desktop. When you add this tool to Claude, you can interact with the agent, ask it to read files on the Desktop, give you outputs based on them, and save the results to files.

👀 So, why should you start exploring it too?

Not just because it’s here to stay, and not just for the hype. This goes deeper.

You should start exploring MCP because:

If you feel like you’re late: today is literally the earliest you can start.
You don’t need any Machine Learning background.
You don’t need to learn a new language: MCP has official SDKs in TypeScript, Python, Java, Kotlin, and C#—so chances are you can already start with what you know (and if not, maybe it’s the perfect excuse to learn something new through a fun project).
You’ll unlock creative thinking: playing with MCP will spark all kinds of ideas to connect tools and explore new possibilities.

Also: MCP is model-agnostic. You can use it with Claude, ChatGPT, Gemini, or whatever comes next.

The model itself isn’t the key. What matters is the context you provide, the instructions, the tools you expose, and the permissions you define.

🎮 Exploring is super easy

A single idea bouncing in your head is enough. You don’t need a huge project to get started.

You can wrap an API you already use, build a simple automated flow, or just play around with local files.

And if something feels uncomfortable along the way (like granting permissions, understanding what the model sees or can execute), that’s okay.

That discomfort teaches you too. Questioning boundaries is part of the journey and it’s how we shape more responsible AI.

🧭 100% recommended links to get started

Here are a few useful links if you want to begin (just like I did 👀):

MCP won’t do everything for you, but it gives you the power to decide how and what to build.

Have you tried it yet? If not, I hope this little blog post inspires you to start.

You could start by reading files from your local system, automating a GitHub pull request, connecting to a weather API, or even building a small tool to organize your notes.

It’s not about how big the project is, it’s about the curiosity to explore ✨

🧠 ¿Qué es el famoso MCP? Y por qué deberías estar explorándolo ya

Cecy Geraldo — Mon, 21 Jul 2025 03:52:10 +0000

Hace un par de semanas empecé a escuchar cada vez más sobre algo llamado Model Context Protocol (MCP). De hecho, lo primero que vi fue un video en TikTok de ChicaPython, y lo que entendí a primeras fue que MCP era una especie de API… pero para comunicarse con LLMs (Large Language Models) 🤯.

Después me puse a googlear y encontré esta documentación oficial, con varias lecturas sobre la arquitectura del protocolo. Desde ahí, con algunos ejemplos y tutoriales usando Claude, empecé la parte práctica.

Y lo potente de esto es que MCP es un protocolo de comunicación estándar, declarado en noviembre de 2024 (sí, relativamente nuevo). Y al ser un protocolo estándar, significa que llegó para quedarse. Su objetivo es que los LLMs puedan interactuar con el mundo real: ejecutar acciones, conectarse a servicios externos y recibir información en tiempo real. Y lo mejor: agnóstico del modelo.

Desde ahora, nos comunicamos de esta manera con los LLMs, y no solo para consumir servicios como cuando usábamos la API de Gemini para crear un agente. Ahora usamos MCP para potenciar la comunicación y aumentar la operabilidad del modelo.

Casos de uso prácticos

Con esto, podemos crear un agente y, a través de un MCP server, darle permisos específicos para que ejecute acciones concretas. Por ejemplo, podemos autorizar la lectura y escritura del agente en una carpeta local para que obtenga información desde ahí y guarde los outputs en un archivo. Y lo mejor es que gracias a la Comunidad Open Source, ya existen muchos MCP servers disponibles, acá te dejo algunos ejemplos de uso:

Para conectarte con GitHub y que el agente te arme un Pull Request (como Jules, el copiloto que presentó Google en el I/O de este año)
Para leer una base de datos
O para automatizar tareas como revisar issues, generar reportes y mucho más

🟡 Side note: como con todo lo poderoso, hay que tener criterio. Revisa bien qué permisos estás entregando antes de usar MCPs de terceros. Puedes estar exponiendo más de lo que imaginas. (Apliquemos la frase estrella "Un gran poder significa una gran responsabilidad")

Lo que más me gustó 💡

Lo que más me sorprendió fue lo accesible que es: no necesitas una máquina muy potente, ni programas raros, ni aprender un nuevo lenguaje recién lanzado. Para nada.

Puedes trabajar en tu máquina local, correr el inspector de MCP, y probar lo que estás construyendo en TypeScript por ejemplo o alguno de los lenguajes compatibles (te los dejo al final del artículo). También puedes configurar un MCP existente mediante un archivo JSON, así bien simple.

Además, puedes testear las herramientas que desarrollas directamente integradas en Claude, gratuitamente.

Mi experiencia práctica

Así fue como pude crear mi primer servidor MCP en TypeScript, siguiendo el tutorial de Midu. Usé un Inspector MCP local para probar herramientas (npx -y @modelcontextprotocol/inspector npx -y tsx main.ts se ejecuta en el puerto 6274), activé la vista de desarrollador en Claude para testear lo que estaba construyendo, automaticé pull requests en GitHub con @modelcontextprotocol/server-github y logré crear un agente conectado con la API del clima, para que me respondiera en tiempo real qué clima había en la ciudad que le estaba consultando y también logré acceder al sistema de archivos local para leer y guardar archivos de forma controlada.

Lo más emocionante: tan solo con la capacidad de leer y guardar archivos, podríamos darle contexto al modelo con información ubicada en el directorio X, y guardar los resultados sintetizados de nuestras consultas en el directorio Y.

Todo bajo control. Sin alucinaciones. Con pasos claros. ¡Todo desde tu local!

Así se vería la configuración MCP que está disponible para acceder a tu file system, en este caso le estamos dando acceso al Escritorio. Al agregar esta herramienta en Claude podemos interactuar con el agente, pedir que lea los archivos en escritorio, que nos de outputs en base a eso y que los almacene en archivos.

Bueno, ¿y por qué deberías estar explorándolo tú también?

No solo porque es algo que llegó para quedarse, ni para subirse al hype. Esto va más allá.

Deberías empezar a explorarlo porque:

Si sientes que vas tarde: hoy es lo más temprano que puedes empezar.
No necesitas experiencia en IA.
Tampoco necesitas aprender un lenguaje nuevo: MCP tiene SDKs oficiales en TypeScript, Python, Java, Kotlin y C#, así que probablemente ya puedes empezar con lo que sabes (y si no, quizás es el momento perfecto para aprender algo nuevo con un proyecto entretenido).
Puedes abrir tu ventana de la creatividad. Explorando MCPs se te van a ocurrir mil formas de conectar herramientas y descubrir nuevas posibilidades.
Además, MCP es agnóstico al modelo. Puedes usarlo con Claude, ChatGPT, Gemini o el que venga.

El modelo no importa tanto. Lo importante es el contexto que le das, las instrucciones, las herramientas que expones y los permisos que definas.

Explorar es muy sencillo

Una idea rondando tu cabeza es suficiente, no necesitas tener un gran proyecto en mente. Puedes partir envolviendo una API que ya usas, creando un flujo automatizado simple, o simplemente jugando con archivos locales.

Y si algo te incomoda en el camino (como dar permisos, entender qué ve el modelo o qué puede ejecutar), está bien. Esa incomodidad es parte del aprendizaje.

Cuestionar los límites es parte del proceso. Así construimos IA más responsable.

Links a explorar 100% recomendado:

Te dejo algunos links útiles por si quieres comenzar (como lo hice yo 👀):

MCP no resuelve todo por ti, pero te da el poder de decidir cómo y con qué construir.

¿Ya lo probaste? Si aún no lo haces, ojalá este blogcito te inspire a dar el primer paso. Puedes comenzar leyendo archivos de tu sistema local, automatizando un pull request en GitHub, conectando una API como la del clima o incluso creando una herramienta que te ayude a organizar tus notas.
Lo importante no es el tamaño del proyecto, sino las ganas de explorar ✨