4 lecciones aprendidas construyendo con herramientas MCP y API de Vonage

El Protocolo de Contexto Modelo (MCP) ha avanzado rápidamente. Recuerdo cuando oí hablar de él por primera vez el pasado mes de marzo en FOSSASIA 2025. Cuesta creer que haya pasado menos de un año, pero ya parece que se ha hecho omnipresente en la programación.

Aunque oí hablar de ella muy pronto, no fue hasta los últimos meses cuando me sumergí de verdad en ella. Estuve jugando con la Documentación de Vonage y Herramientas para servidores MCPprimero localmente, luego a través de publicaciones en blogs, demostraciones y, finalmente, ayudando con el servidor de herramientas de código abierto. Esto no es una recapitulación de las funciones de MCP ni una guía para comenzar: Es un conjunto de lecciones que surgieron al tratar de hacer las herramientas utilizables en la práctica.

Primera lección: un error precoz: Los agentes generan código por defecto

El primer fracaso real no fue un fallo técnico. Fue un modelo mental defectuoso.

Conecté mi IDE al servidor MCP, confirmé que las herramientas estaban registradas y pedí al agente que enviara un mensaje de WhatsApp. En lugar de llamar a la herramienta existente, el agente abrió un nuevo archivo y comenzó a escribir un script Node.js. Intentó importar el SDK de Vonage, configurar la autenticación y realizar la llamada a la API directamente.

No había nada "malo" en el modelo. Estaba haciendo exactamente aquello para lo que había sido entrenado: resolver problemas escribiendo código.

El problema era cómo enmarcaba el sistema. El agente actuaba como un generador de código más inteligente, en lugar de como una capa de orquestación. Las herramientas ya existían. El agente no necesitaba construir nada: necesitaba seleccionar e invocar lo que estaba disponible.

Una vez que ajusté la forma en que pedía al agente, las cosas se acomodaron. En lugar de pedirle que creara funciones, le pedí que las utilizara.

Ese cambio parece menor, pero en realidad es un gran cambio mental.

Para llevar: MCP funciona mejor cuando se deja de pensar en términos de scripts y se empieza a pensar en términos de herramientas. Si el agente escribe código pegajoso, suele significar que algo no está bien estructurado.

Segunda lección: la configuración era un auténtico sumidero de tiempo

Una vez corregido el modelo mental, esperaba que el resto del trabajo fuera sencillo. Y no lo fue.

La parte que más tiempo consumía en el desarrollo local era conseguir que el IDE se conectara de forma fiable al servidor MCP. La mayoría de los fallos parecían "la herramienta no aparece", lo que hacía fácil suponer que el servidor no funcionaba. Casi siempre era la configuración.

Diferentes IDEs esperan la configuración MCP en diferentes lugares. Por ejemplo, Windsurf se parece a VS Code, pero no es VS Code, y la ruta de configuración no está donde la memoria muscular sugiere que debería estar. Pasé más tiempo del que me gustaría admitir persiguiendo errores inexistentes porque el servidor nunca se puso en marcha en primer lugar.

Las configuraciones MCP tampoco se comportan como scripts de shell. El cliente genera un proceso directamente. No puede confiar en sh -c, cdo comandos encadenados. Si no usas rutas absolutas y comandos explícitos, los fallos tienden a ser silenciosos.

Una vez que todo estuvo configurado correctamente, la experiencia fue sencilla en el mejor de los sentidos. Reinicia el IDE, actualiza el panel de plugins y aparecen las herramientas.

Para llevar: MCP sigue un patrón de programación familiar: la configuración es donde se producen la mayoría de los quebraderos de cabeza. Cuando algo no funciona, suele ser una configuración. Una vez configurado, MCP te deja volar.

Tercera lección: Stdio funciona bien localmente, menos bien en otros lugares

El transporte stdio por defecto de MCP es una buena opción para el desarrollo local. Es simple, rápido y evita exponer puertos o credenciales. Para flujos de trabajo basados en IDE, hace exactamente lo que quieres. Y es exactamente por eso que lo hemos utilizado para nuestro servidor de herramientas. Queríamos ponerlo en manos de los desarrolladores de forma rápida y flexible.

Sin embargo, surgen algunas limitaciones cuando intentas utilizar las mismas herramientas fuera de un IDE, como la integración de un sistema externo. No puedes hacer una petición HTTP a stdin. No hay un punto final para asegurar, y no hay un lugar obvio para adjuntar autenticación.

Para salvar esa distancia, acabé construyendo una pequeña capa de traducción que convertía JSON-RPC sobre stdio en HTTP para que otros sistemas pudieran interactuar con el servidor MCP. Funcionaba, pero era una infraestructura adicional que no existía en la configuración sólo local.

Las pruebas también se han vuelto más complicadas. El "funciona localmente" no tiene mucho sentido si el agente está llamando a la herramienta desde otro lugar. Actualmente, no existe un punto intermedio para validar las herramientas MCP de forma aislada sin iniciar una sesión de agente completa.

Para llevar: MCP facilita los flujos de trabajo IDE, y por eso empezamos por ahí. Para los desarrolladores que se sientan cómodos gestionando su propio alojamiento y autenticación, esa compensación es razonable. Una vez que se va más allá del uso local, stdio plantea retos como la autenticación, las capas de traducción y las pruebas. Esto tiene menos que ver con MCP en sí y más con la ubicación de este servidor. Esté atento a la ampliación de nuestra oferta de MCP.

Lección 4: Planificar el crecimiento: Diseño de herramientas y presupuesto contextual

Esta lección no vino de algo que se rompió. Vino de mirar el servidor de herramientas y preguntarse: "¿Qué pasará cuando más gente empiece a contribuir?".

Mientras escribía sobre el uso de las herramientas MCP de Vonage y fomentando las contribuciones de código abiertose hizo evidente que la estructura de repositorios no estaba diseñada para crecer. Todo vivía en un único archivo. Eso es manejable al principio, pero no escala bien. Ni para los humanos ni para los agentes.

Al observar cómo gestionan el crecimiento otros servidores MCP, surgió una restricción más importante: cada herramienta que expones consume parte de la ventana contextual del modelo.

Los esquemas de las herramientas no son libres. Los nombres, parámetros y descripciones se inyectan en la petición del sistema. A medida que aumenta el número de herramientas, se reduce gradualmente el espacio de que dispone el modelo para razonar sobre la petición real del usuario.

Existe la tentación natural de crear herramientas flexibles y polivalentes: un único comando send_message que gestione todos los canales y comportamientos. Desde el punto de vista de la API, es ordenado. Desde la perspectiva de un modelo, es ambiguo y caro.

Las herramientas más pequeñas y de uso único suelen funcionar mejor. Son más fáciles de seleccionar para el modelo, más baratas de describir y más sencillas de razonar. Internamente, las implementaciones pueden seguir compartiéndose. Lo que más importa es lo que ve el agente.

El actual servidor de herramientas de código abierto aún no implementa la carga contextual, y eso es intencionado. Pero estas limitaciones ya están dando forma a la forma en que estamos pensando en un servidor MCP más productizado; uno que cualquiera pueda usar, no sólo los desarrolladores.

Para llevar: Con MCP, el rendimiento no sólo tiene que ver con la velocidad de ejecución. También se trata de cuánto contexto consumes.

Reflexiones finales

Trabajar con MCP cambió mi forma de ver el trabajo diario. Los procesos que antes aceptaba como manuales o repetitivos ahora se convierten en herramientas potenciales. Una vez que se produce ese cambio, empiezas a ver oportunidades por todas partes; no para automatizar porque sí, sino para eliminar fricciones en lugares que ralentizan el trabajo real.

MCP aún es joven, y muchas de sus asperezas son comprensibles. Pero una cosa quedó clara muy pronto: el éxito de un sistema basado en MCP depende no sólo del modelo que se elija, sino también de lo cuidadosamente que se diseñen las herramientas. Unos límites claros, unas responsabilidades delimitadas y un comportamiento predecible son más importantes que las abstracciones ingeniosas. Cuando esas piezas están en su sitio, es más fácil confiar en el sistema y ampliarlo.

Lo que me parece más interesante es cómo MCP te empuja a pensar en el software como algo que está destinado a ser utilizado. utilizado por agentes, no sólo por humanos. Eso cambia la forma de escribir las API, de estructurar la documentación y de evaluar si algo está "hecho". Es un conjunto diferente de compensaciones, que todavía está tomando forma.

En las próximas semanas, experimentaré con otras herramientas MCP como Laravel Boost y MCP UI para ver cómo otros están abordando estos problemas. Si estás trabajando con MCP, o simplemente pensando en ello, me encantaría escuchar lo que estás construyendo y lo que has aprendido en el camino. Envíame un mensaje en LinkedIn o en Vonage Developer Slack.