Qué es un MCP y qué comprobar antes de conectarlo a tu evento

Son las 18:00 y queda un día para abrir las puertas. El cliente pide «limpiar la lista y avisar a los que faltan». Tú sabes que se refiere a revisar duplicados y preparar un recordatorio. Un agente de inteligencia artificial conectado a tu plataforma podría tener herramientas para consultar la lista, modificar inscripciones y enviar mensajes.

Antes de darle esa instrucción, necesitas saber qué acciones puede ejecutar y cuáles requieren que alguien las apruebe. La diferencia importa: un listado preparado se puede revisar; un mensaje enviado ya ha llegado a sus destinatarios.

Cuando un proveedor anuncia una conexión MCP, ha explicado cómo puede conectarse el asistente. Todavía faltan respuestas sobre qué hará con esa conexión y cómo controlará la empresa sus acciones.

Qué es un MCP, explicado desde el trabajo del evento

MCP son las siglas de Model Context Protocol. Es un estándar para conectar asistentes de inteligencia artificial con información y herramientas de otros sistemas.

Imagina que tu equipo le pide al agente «consulta cuántas personas tienen entrada de tarde». Si la plataforma ofrece esa herramienta y la conexión está preparada, el agente puede solicitar los datos al sistema. Ya no depende de que alguien exporte el listado y lo adjunte a una conversación.

Otras herramientas podrían modificar un registro o enviar una comunicación. Las posibilidades dependen de lo que haya expuesto el proveedor y de los permisos de la conexión. Tener un MCP no significa que todas esas acciones estén disponibles, ni que deban activarse juntas.

La documentación oficial de herramientas de MCP describe cómo se ofrecen funciones a las aplicaciones conectadas. Para decidir si una conexión encaja en tu evento, pide al proveedor que te traduzca su catálogo de herramientas a acciones reconocibles por tu equipo.

No necesitas programar el protocolo. Sí necesitas entender qué estás autorizando.

Consultar una lista y enviarla son decisiones distintas

Un agente puede ayudar a preparar un trabajo sin ejecutarlo fuera de la conversación. También puede actuar sobre una plataforma si tiene las herramientas necesarias. Conviene separar esas situaciones desde el principio.

Acción	Qué cambia	Qué deberías poder revisar
Consultar inscripciones	El agente accede a datos	Qué evento y qué campos puede leer
Proponer una audiencia	Se prepara una selección	Los criterios y las personas incluidas
Cambiar un registro	Se modifica información del sistema	El registro y el cambio exacto
Enviar una comunicación	El mensaje llega a personas	El contenido, los destinatarios y el momento
Eliminar o compartir información	Se pierde información o sale de su entorno	El alcance y las consecuencias antes de ejecutar

Estas diferencias ayudan a empezar con un alcance pequeño. Si el equipo solo necesita consultar información, no hay una razón automática para habilitar también herramientas de envío o eliminación.

En la escena inicial, «limpiar la lista» debería convertirse primero en una propuesta revisable: qué registros parecen duplicados y con qué criterio. «Avisar a los que faltan» necesita aclarar quiénes son, qué mensaje recibirán y cuándo. La petición del cliente contiene intención; el equipo debe poder aprobar la operación concreta.

Qué significa pedir permiso de verdad

Una descripción que diga «pide confirmación antes de enviar» orienta al agente, pero no demuestra que la acción esté bloqueada. Tampoco basta con que el propio modelo rellene una casilla de «confirmado».

MCP contempla un mecanismo llamado elicitation para solicitar información al usuario a través de la aplicación. Puede utilizarse dentro de un recorrido de confirmación si cliente y servidor lo soportan. La especificación no obliga a que cada herramienta sensible emplee ese recorrido. Fuente: elicitation en MCP.

Para una aprobación efectiva, el sistema que ejecuta debe esperar una autorización válida para esa acción. La confirmación tiene que corresponder a lo que has revisado: el mensaje, los destinatarios y los parámetros de la operación. Si cambia el contenido o la lista después, el equipo necesita saber si hay que aprobar de nuevo.

Pide una demostración concreta: prepara un envío y rechaza la aprobación. El mensaje no debe salir. Prueba también qué ocurre si no respondes o si la aplicación no ofrece ese tipo de confirmación.

Ese comportamiento vale más que una frase comercial sobre «control humano». El proveedor debe explicar dónde se impide la ejecución y qué pasa cuando falta la autorización.

Las etiquetas de una herramienta no sustituyen al control

Una herramienta puede incluir indicaciones sobre su comportamiento, como que consulta información o que podría realizar una acción destructiva. Esas indicaciones ayudan a interpretarla, pero no deben confundirse con un bloqueo que haga imposible una operación.

La especificación trata las anotaciones como pistas y advierte de que no se confíe en ellas si proceden de un servidor no fiable. Fuente: anotaciones de herramientas MCP.

Para tu evento, la pregunta práctica es otra: ¿puede la empresa desactivar una acción y comprobar que deja de estar disponible? Si un asistente solo debe leer la agenda, necesitas verificar que no tiene acceso a una herramienta que la modifica.

Pide que esa separación se vea en la configuración y en una prueba. El nombre de la herramienta, su descripción o una instrucción en la conversación no sustituyen esa comprobación.

Qué pedir al proveedor antes de conectar la plataforma

Puedes trasladar la revisión técnica a quien mantiene la integración, sin renunciar a entender sus consecuencias. Estas preguntas dan una base para esa conversación:

• ¿Qué herramientas se van a activar? Pide un listado de acciones, con ejemplos de lo que cada una puede hacer sobre tu evento.
• ¿A qué información tendrán acceso? Aclara si la conexión queda limitada a un proyecto o si alcanza otras cuentas y eventos.
• ¿Quién puede utilizar cada acción? La capacidad de consultar una inscripción y la de enviar una campaña no tienen por qué corresponder a las mismas personas.
• ¿Qué requiere aprobación y dónde se bloquea? Pide ver el rechazo, la falta de respuesta y los cambios posteriores a una confirmación.
• ¿Qué queda registrado? Necesitas poder reconstruir quién pidió una acción, quién la autorizó y qué ocurrió.
• ¿Qué se puede recuperar? Distingue cambios internos restaurables de efectos externos que no se pueden retirar.

Si una respuesta queda en «el agente sabe que no debe hacerlo», falta un control verificable. Si te enseñan una configuración, pregunta cómo comprueban que se aplica también cuando la petición es ambigua.

La revisión debe corresponder a la aplicación que utilizará tu equipo. Que un mecanismo exista en el protocolo no demuestra que funcione igual en todas las aplicaciones conectadas.

Recuperar memoria no es retirar un mensaje enviado

EVA Brain trabaja con memoria compartida por proyecto, permisos e historial de cambios. Ese historial ayuda a entender cómo ha evolucionado el conocimiento y a recuperar estados de la memoria cuando corresponde.

Esos controles resuelven una parte del problema: cómo trabaja el equipo con el conocimiento del evento. Las acciones realizadas en plataformas externas necesitan sus propios límites y aprobaciones.

Por ejemplo, restaurar la memoria anterior a un cambio no retira un correo ya enviado, ni hace desaparecer una lista que ya se compartió. Antes de conectar una herramienta de comunicación, hay que controlar el envío. Antes de dar acceso a información, hay que delimitar qué puede salir.

Para una empresa con varios equipos, centralizar la gestión de conexiones y herramientas puede aportar una forma de establecer esas reglas en conjunto. Evalúa esa capa por sus controles concretos: acciones habilitadas, personas autorizadas, aprobación y registro. Pregunta qué está disponible en tu configuración antes de darlo por resuelto.

Si estás valorando cómo conectar agentes al trabajo de tus eventos, cuéntanos qué plataformas utilizáis y qué acciones queréis delegar. La conversación debería empezar por esas tareas y sus consecuencias, antes de escoger una conexión.

Preguntas frecuentes

¿Un MCP es peligroso por definición?

No. El riesgo depende de las herramientas expuestas, los datos accesibles y los controles del cliente y del servidor. Una conexión limitada a consulta tiene consecuencias diferentes de otra que puede enviar mensajes o eliminar información.

¿MCP obliga a pedir permiso antes de cualquier cambio?

No existe una confirmación humana universal para cada acción. El protocolo incluye mecanismos de interacción con el usuario, pero hay que comprobar cómo los utiliza la integración concreta y dónde se bloquean las operaciones sensibles.

¿Tengo que hacer yo una auditoría técnica?

Puedes pedirla al proveedor o a un especialista. Como organizador, necesitas comprender qué tareas delegas y recibir pruebas de los límites, las aprobaciones y los registros acordados.

¿Un historial significa que todo se puede deshacer?

No. Puede ayudar a recuperar información dentro de un sistema. Un mensaje enviado, datos compartidos o una acción externa pueden tener consecuencias que restaurar la memoria no revierte.