Hace unos días creé un agente de voz para una clínica, le añadí su web como base de conocimiento y revisé por qué había fallado una llamada de prueba.
No abrí el panel de Diga en ningún momento.
Lo hice desde Claude, escribiendo lo que quería como si se lo estuviera pidiendo a un compañero.
Esto es posible gracias a MCP (Model Context Protocol), un estándar que permite conectar modelos de IA con herramientas y sistemas externos de una forma común.
En este artículo vamos a explicar qué es MCP, qué problema resuelve en los agentes de voz, cómo funciona en Diga en las dos direcciones y qué hemos aprendido construyéndolo.
Porque hay una diferencia importante entre que una IA pueda hablar sobre tu plataforma y que pueda utilizarla de verdad.
¿Qué es MCP y para qué sirve en los agentes de voz?
MCP (Model Context Protocol) es un estándar abierto que permite a una aplicación de IA descubrir y utilizar herramientas y datos externos. En lugar de crear una integración diferente para cada modelo, MCP define una forma común de exponer esas capacidades para que clientes compatibles puedan descubrirlas y utilizarlas.
Dicho de forma sencilla: MCP es una capa de conexión entre una IA y las herramientas que necesita para hacer cosas.
Un servidor MCP puede exponer herramientas que un modelo puede descubrir y utilizar. Por ejemplo, consultar un calendario, buscar información en un CRM o crear un registro.
La idea se parece a USB-C: no significa que todos los dispositivos hagan lo mismo, sino que existe una forma estandarizada de conectarlos.
Y esto resulta especialmente interesante en agentes de voz, porque un agente que solo conversa tiene un alcance limitado. Un agente que puede utilizar herramientas puede consultar información, tomar acciones y completar procesos durante una llamada.
El problema: integrar cada herramienta era trabajo artesanal
Un agente de voz que solo habla sirve para algunos casos.
Pero piensa en una llamada real:
— Quería cambiar mi cita del jueves.
— Claro, voy a comprobar la disponibilidad.
Para responder correctamente, el agente necesita consultar un sistema externo.
Hasta ahora, conectar ese sistema normalmente implicaba definir la integración manualmente: qué endpoint llamar, qué parámetros enviar, cómo autenticarse y qué información debía recibir el modelo para utilizarla correctamente.
Para una API propia sigue siendo una opción válida y flexible. En Diga puedes hacerlo mediante integraciones HTTP.
Pero cuando tienes muchos sistemas y muchas operaciones, la complejidad aumenta rápidamente.
MCP estandariza precisamente esa capa de conexión.
Un servidor MCP puede describir qué herramientas ofrece, qué parámetros necesitan y cómo utilizarlas. El cliente compatible puede descubrir esas herramientas y ponerlas a disposición del modelo.
La diferencia no es que MCP elimine toda la integración. Es que reduce el trabajo específico que cada cliente tiene que hacer para entender cómo utilizarla.
MCP hacia dentro: tu agente de voz usa herramientas externas
Este es probablemente el uso más fácil de entender.
Imagina una clínica cuyo sistema de gestión de citas expone herramientas mediante MCP.
Un paciente llama:
— Quería cambiar mi cita del jueves.
— Claro, un momento que lo compruebo.
El agente consulta la disponibilidad.
— Tengo hueco el viernes a las 10:00 o el lunes a las 16:30. ¿Cuál te viene mejor?
El agente ha utilizado una herramienta externa durante la conversación.
En voz esto tiene una particularidad: el usuario está esperando mientras la herramienta trabaja.
Por eso no basta con conectar una herramienta y dejar que el modelo decida qué hacer. También hay que diseñar cómo se comporta el agente alrededor de esa acción.
Por ejemplo:
Avisar al usuario antes de realizar una consulta que puede tardar.
Evitar silencios largos durante la espera.
Pedir confirmación antes de acciones importantes.
Explicar el resultado de forma breve.
Tener un comportamiento definido si la herramienta falla.
La herramienta puede venir de un servidor que no controlas, pero la experiencia de voz sigue siendo responsabilidad de tu agente.
MCP hacia fuera: ahora Diga también puede ser una herramienta
Aquí es donde el concepto se vuelve especialmente interesante.
Hasta ahora hemos hablado de un agente de Diga utilizando herramientas externas.
Pero podemos darle la vuelta:
¿Y si fuera tu asistente de IA el que pudiera utilizar Diga?
Eso es exactamente lo que permite el servidor MCP de Diga.
Puedes conectar clientes compatibles como Claude, Cursor o Codex a Diga mediante una API key de proyecto. Una vez conectado, el asistente puede descubrir las herramientas disponibles y utilizarlas según los permisos de esa clave.
En lugar de entrar al panel y hacer cada acción manualmente, puedes pedir cosas como:
“Créame un agente para una inmobiliaria que cualifique compradores y recopile sus datos.”
O:
“Súbele como base de conocimiento la web de esta clínica.”
O:
“¿Por qué ha fallado la última llamada de este agente?”
O incluso:
“¿Cuántos minutos llevamos este mes y qué números tenemos activos?”
Dependiendo de los permisos de la API key, el servidor MCP de Diga permite gestionar agentes y versiones, consultar llamadas y sus logs, crear bases de conocimiento, gestionar números, integraciones, webhooks y flujos, además de consultar otros recursos del proyecto.
Diga deja de ser únicamente una interfaz que utilizas y pasa a ser una herramienta que tu IA puede utilizar.
¿Cómo funciona?
La arquitectura es bastante sencilla:
Tu asistente de IA → servidor MCP de Diga → herramientas de Diga
El cliente se conecta al servidor MCP de Diga mediante Streamable HTTP y se autentica con una API key asociada a un proyecto. La clave determina qué proyecto gestiona el asistente y qué permisos tiene.
La configuración es corta y puedes encontrarla en nuestra documentación del servidor MCP de Diga.
Consejo: empieza con una acción de solo lectura, como listar tus agentes, antes de dar permisos para modificar o eliminar recursos.
Melo utiliza este mismo enfoque
MCP tampoco apareció de la nada dentro de Diga.
Melo, nuestro copiloto, utiliza herramientas para trabajar con Diga desde el principio.
Cuando le pides que modifique un agente, consulte una llamada o configure parte de un proyecto, necesita utilizar operaciones de la plataforma para hacerlo.
Y construir Melo nos enseñó una lección importante.
Al principio hicimos algo bastante lógico: coger nuestra API y exponer sus endpoints como herramientas MCP, devolviendo prácticamente la misma información que devolvía la API.
Funcionaba.
Pero no funcionaba especialmente bien.
Una API para software no es necesariamente una buena API para una IA
El problema eran las respuestas.
Pedías la lista de agentes y el modelo recibía agentes completos, con prompts, configuración, flujos y metadatos.
Pedías información sobre una llamada y podía recibir una cantidad enorme de información relacionada con ella.
El contexto se llenaba rápidamente.
Y no era solo un problema de cantidad. Demasiada información también puede hacer que el modelo tome peores decisiones.
Es parecido a preguntar a una persona cuántos agentes tienes y entregarle antes un informe de cuarenta páginas.
La información está ahí, pero encontrar el dato correcto se vuelve más difícil.
La solución fue diseñar las herramientas pensando en cómo las utiliza un modelo:
Listados con los campos realmente necesarios.
Detalle adicional solo cuando se solicita un recurso concreto.
Paginación para recursos que pueden crecer.
Respuestas más pequeñas y orientadas a la siguiente decisión.
La conclusión fue clara:
Una API pensada para programas no siempre es una API pensada para modelos.
Un programa puede ignorar fácilmente cien campos que no necesita. Un modelo tiene que procesar ese contexto antes de decidir qué hacer con él.
MCP no significa “conecta todo y ya está”
Es fácil caer en la idea de que cuantos más servidores y herramientas conectes, más potente será tu agente.
En realidad, puede ocurrir justo lo contrario.
Más herramientas pueden significar peores decisiones
Si un agente tiene acceso a cincuenta herramientas, tendrá más posibilidades de hacer cosas.
Pero también tendrá más posibilidades de elegir la herramienta equivocada.
En un agente de voz esto es todavía más importante porque cada decisión ocurre dentro de una conversación en tiempo real.
Por eso recomendamos asignar solo las herramientas que realmente necesita cada agente.
MCP no hace rápida una herramienta lenta
MCP estandariza la forma de descubrir y utilizar herramientas, pero no hace que el sistema que está detrás responda más rápido.
Si una herramienta tarda dos segundos, el usuario puede percibir esos dos segundos.
Y en una llamada de voz, la latencia importa mucho más que en una interfaz web.
Si quieres profundizar en cómo funciona la latencia en los agentes de voz, puedes consultar nuestro análisis sobre Speech-to-Speech.
También dependes del servidor externo
Cuando utilizas un servidor MCP que no controlas, dependes de cómo esté diseñado y de los cambios que haga su proveedor.
Una herramienta puede cambiar sus parámetros, dejar de existir o empezar a devolver información diferente.
Por eso, MCP simplifica la conexión, pero no elimina la necesidad de supervisarla.
Seguridad: darle herramientas a una IA también implica darle permisos
Esta parte es especialmente importante cuando hablamos de MCP hacia fuera.
Si conectas una IA con Diga, estás permitiendo que esa IA realice determinadas acciones sobre un proyecto.
Por eso las API keys de Diga están asociadas a un proyecto y pueden restringirse según los permisos que necesite el asistente. La documentación recomienda utilizar claves diferentes por cliente y entorno, conceder únicamente los permisos necesarios y revisar las acciones que modifican o eliminan recursos.
La regla es sencilla:
una IA debería tener exactamente los permisos que necesita para hacer su trabajo, no todos los que podría llegar a necesitar algún día.
Empieza con acciones de lectura y aumenta los permisos progresivamente.
Lo que MCP cambia para los agentes de voz
Hasta ahora, buena parte de la automatización consistía en conectar aplicaciones entre sí.
Una empresa tenía un CRM, un calendario, un sistema de telefonía, una base de datos y varias herramientas de automatización. Cada conexión necesitaba su propia configuración.
MCP apunta hacia una capa más estandarizada para que las aplicaciones de IA puedan descubrir y utilizar herramientas de diferentes sistemas.
En agentes de voz esto abre una posibilidad especialmente interesante: el agente no solo puede hablar con una persona; puede hablar con los sistemas que necesita para resolver lo que esa persona está pidiendo.
Y hacia el otro lado: tu asistente de IA no solo puede hablar sobre tus agentes; puede crearlos, modificarlos, analizarlos y gestionarlos.
Ese cambio es más importante que una nueva integración.
Es pasar de una IA que responde a una IA que utiliza herramientas para actuar.
MCP y Diga: dos direcciones, una misma idea
En Diga utilizamos MCP en las dos direcciones:
Dirección | Qué ocurre |
|---|---|
Agente → MCP externo | Tu agente de voz utiliza herramientas de otros sistemas durante una llamada. |
IA externa → Diga MCP | Claude, Cursor, Codex u otros clientes utilizan Diga como herramienta para crear y gestionar agentes. |
En ambos casos, la idea es la misma: la IA no se limita a generar una respuesta. Puede utilizar herramientas para hacer algo.
Y para nosotros, ahí está la parte realmente interesante de MCP.
El futuro no es tener más herramientas, sino hacerlas utilizables por la IA
MCP todavía está evolucionando, y el estándar continúa incorporando mejoras en transporte, autorización, descubrimiento y ejecución de herramientas. La especificación publicada en julio de 2026, por ejemplo, introdujo cambios importantes en el funcionamiento del protocolo y en su modelo de transporte.
Pero la dirección resulta bastante clara.
Durante años, integrar una plataforma significaba aprender su API y escribir código contra ella.
Ahora existe una capa estándar para que una aplicación de IA pueda descubrir qué puede hacer esa plataforma y utilizar esas capacidades.
Eso cambia también cómo diseñamos los productos.
Ya no basta con preguntarnos:
“¿Qué puede hacer una persona desde nuestra interfaz?”
También tenemos que preguntarnos:
“¿Qué puede hacer una IA con nuestra plataforma?”
En Diga, queremos que las respuestas sean cada vez más amplias.
Tus agentes hablan con tus sistemas.
Y ahora, tu IA también puede hablar con Diga.
Empieza a trabajar con Diga desde tu IA
MCP abre una nueva forma de interactuar con las plataformas: no tienes que limitarte a hacer clic en ellas; tu asistente de IA también puede utilizarlas.
Conecta Diga con tu cliente MCP, empieza con una acción sencilla y descubre todo lo que puedes automatizar desde lenguaje natural.
Crea tu primer agente de voz y empieza a construir automatizaciones que no solo hablan, sino que hacen.
