El Model Context Protocol (MCP) aún se encuentra en una etapa muy temprana de evolución—o al menos eso espero—pero ya está abriendo nuevas formas muy interesantes de conectar modelos de lenguaje con herramientas y servicios reales. Me siento como cuando tuve mi primer módem y podía conectar mi computadora, a la increíble velocidad de 1200 bits por segundo, con otras computadoras (inserte los sonidos de marcado, timbre y los tonos felices del 'handshake').
Dato curioso: este video es divertido de ver con los subtítulos activados: https://youtu.be/xalTFH5ht-k
En Nimble Gravity hemos estado automatizando procesos con servidores MCP que habrían sido muy difíciles de implementar sin el poder del MCP (y los LLMs), y queríamos compartir algunos aprendizajes.
Generalmente Usamos el SDK de MCP de Anthropic
Hay un montón de variantes de SDKs de MCP surgiendo por todos lados. Nosotros preferimos la versión de Anthropic porque, bueno, es la original, está bien documentada y nos ofrece todo lo que necesitamos.
Esa claridad nos ha ahorrado mucho tiempo. Nos dio una base sólida para experimentar sin adivinar qué hacía cada parámetro o cómo debía comportarse. También facilitó mucho la incorporación de nuevos miembros al equipo—tenían una guía clara en lugar de depender de conocimiento tribal. Esa confiabilidad es lo que nos sigue haciendo elegirlo, incluso con más opciones disponibles.
Las Descripciones Importan
Al implementar herramientas, es obvio que hay que ser claro con lo que hacen, cuáles son los parámetros (¡y enums!), qué valores esperan y qué devuelven. Pero es útil pensar en tus esquemas como algo que debe poder ser interpretado tanto por máquinas como por humanos. ¿El campo de fecha de entrega en qué formato está?
Piensa Como Usuario
Solo porque ya tengas un API, no significa que sea útil para lo que realmente quieren hacer los usuarios. Las herramientas pueden ser más del tipo “haz un mueble” en lugar de “cómo usar una sierra”—ese nivel más alto de abstracción es excelente.Por ejemplo, una herramienta “get_customer_orders” que acepte nombre o ID de cliente podría, de forma interna, hacer primero un lookup de ID si solo recibe el nombre, o llamar directamente al API si ya tiene el ID. Siempre que definas bien la herramienta, el LLM sabrá usarla de diferentes maneras. Es mucho más rápido. Y eso no impide que tengas una herramienta auxiliar si necesitas algo más específico.
Usa Caché y Sé Selectivo con la Salida
Si el LLM tiene que hacer varias llamadas para resolver algo que no cambia tan seguido (como contactos de CRM), un patrón de caché puede ser útil. Al iniciar el cliente, puedes precargar algunos datos y luego trabajar desde la caché. Recordatorio: las buenas prácticas de ingeniería de software siguen aplicando.Y si hay algo que vas a devolver al LLM pero no se necesita, simplemente no lo devuelvas. Si estás repitiendo los mismos pasos una y otra vez, considera crear una sola herramienta que lo haga todo, en lugar de que el LLM orqueste cada paso. Vas a llenar el contexto permitido de la conversación y vas a pasar un mal rato.
Herramientas como Inngest pueden servir para orquestaciones más complejas, aunque hasta ahora no hemos tenido que llegar a eso.
Los LLMs Se Esfuerzan Demasiado
Si algo no está bien definido (o directamente no es posible), el LLM a veces igual lo intenta. Puede incluso inventar valores para los parámetros. A veces funciona (como adivinar un valor de industria válido en un CRM), pero otras veces un poco de programación defensiva ahorra muchos problemas. Con el tiempo, ir viendo cómo los usuarios interactúan con el servidor también ayuda a refinar los casos de uso.
APIs con Endpoints de Descubrimiento Son un Sueño
Si tienes un API que describe otros APIs o los parámetros disponibles, son una maravilla porque puedes decirle al LLM qué hacer sin hardcodear nada. Por ejemplo, puedes usar el API de HubSpot para obtener todas las propiedades de un tipo de objeto (como Contactos) y así evitar codificar a mano cada campo en tu herramienta de actualización. Esto permite que tus herramientas sean mínimas, componibles y, en cierto sentido, “a prueba del futuro”.
El Inspector de MCP Es Muy Útil (y También los Logs de Claude)
Tener una interfaz sencilla para probar herramientas es oro. Es como el Postman de los primeros días, pero para interfaces con LLMs.
Y si algo falla (o funciona demasiado bien), los logs de Claude, por ejemplo, son muy útiles—un log por servidor MCP para saber exactamente dónde mirar. Esta es una señal clara de que estamos en un espacio nuevo, con herramientas en etapas muy tempranas. Mucho de esto mejorará con el tiempo.
Planea Bien Tu Uso
Si de pronto estás integrando mucha más información, es posible que empieces a chocar con los límites del contexto o de la sesión de conversación. Si necesitas hacer 20 cosas, tal vez sea mejor dividirlas en dos o más sesiones para evitar (o al menos reducir) el temido mensaje: “por favor, inicia una nueva conversación para continuar”.
Conviene pensar tu flujo de trabajo como capítulos bien definidos, cada uno resolviendo una parte clara del proceso. También podrías almacenar resultados intermedios o resumir salidas para usarlas más adelante. No se trata de limitarse, sino de diseñar para escalar.
Se Siente Como la Época del Dial-Up
Este espacio aún está en una etapa muy temprana de desarrollo. Pero me da nostalgia del módem dial-up (en el mejor sentido). Se puede sentir el potencial: interfaces modulares, seguras y semánticamente ricas para la IA. Hoy es como esa caja beige conectada a tu computadora. ¿Mañana? Infraestructura central.
La Revolución del Dial-Up
Todavía estamos descifrando las mejores prácticas. Si estás experimentando con MCP, nos encantaría intercambiar ideas.
Escríbenos a Nimble Gravity si estás construyendo algo interesante (o si estás atorado).
.png?width=360&height=240&name=email%20sign%20up%20graphic(2).png)