Beneficios y desafíos

Las principales son tres: una integración por sistema que sirve a todas las aplicaciones de IA, un punto único donde viven las definiciones de tools y prompts, los permisos y la auditoría, y servidores sin estado que se despliegan y escalan como cualquier servicio HTTP. Además el servidor no queda atado a un proveedor de modelos, porque el protocolo es una especificación abierta con clientes de varias empresas competidoras. Los límites: solo hay reutilización si al menos dos aplicaciones usan el mismo servidor, y los controles de ese punto único hay que programarlos.

Lo nuevo es que un modelo elige qué operación ejecutar guiándose por textos que pueden venir de terceros, así que el riesgo principal es la inyección de instrucciones en el contenido que devuelven las tools, como el cuerpo de un ticket de un cliente. La lección repasa también el tool poisoning, el token passthrough, el confused deputy, el secuestro de identificadores de estado y los servidores MCP en la sombra. La defensa fiable no es el modelo, sino que el servidor compruebe permisos en todas las llamadas, junto con la confirmación humana en el host para las acciones con efecto.

Cuando ningún modelo decide la llamada (una tarea programada con una secuencia fija), cuando el sistema lo usa una única aplicación que mantiene el mismo equipo, en cuyo caso basta el function calling directo, o cuando todavía no puedes garantizar la identidad de cada persona y la auditoría de cada llamada. Si el modelo no tiene que invocar ninguna operación, por ejemplo porque responde sobre un documento que no cambia, basta con incluir ese documento en las instrucciones de la propia aplicación. Son criterios del curso, porque la especificación no trata esta cuestión.