Model Context Protocol en Copilot Studio: conectar agentes a sistemas empresariales sin abrir un agujero

Un agente de Copilot Studio que solo puede leer su propia base de conocimiento es un chatbot con buenos modales. En el momento en que un negocio quiere que consulte inventario en vivo, abra un ticket o recupere el estado de un pedido de un cliente, alguien tiene que conectarlo a un sistema real. Durante gran parte de 2025 eso significaba construir a mano un conector personalizado por sistema. Model Context Protocol cambia la forma de ese trabajo — y, silenciosamente, la forma del riesgo.

Me gusta MCP. También creo que la mayoría de los equipos están a punto de conectar agentes a sistemas de producción más rápido de lo que los conectan a su gobernanza, y ese hueco es de donde saldrán los incidentes.

Esto es lo que MCP realmente es dentro de Copilot Studio, cómo configurarlo, y — la parte que los tutoriales se saltan — cómo hacerlo sin abrir un agujero en tu tenant.

¿Qué es Model Context Protocol en Copilot Studio?

Model Context Protocol (MCP) es un estándar abierto que permite a un agente de Copilot Studio conectarse a un servidor externo y usar cualquier herramienta y recurso que ese servidor publique, sin necesidad de construir una integración a medida para cada uno. El servidor MCP describe el nombre, las entradas y las salidas de cada herramienta; el orquestador del agente decide cuándo llamarla en tiempo de ejecución.

Según la visión general de MCP de Microsoft para Copilot Studio, un servidor conectado puede exponer tres cosas: recursos (datos tipo archivo que el agente puede leer como contexto), herramientas (funciones que el modelo puede invocar para realizar una acción) y prompts (plantillas). Copilot Studio actualmente admite herramientas y recursos. La parte elegante es que la conexión es en vivo — cuando el propietario del servidor añade, cambia o elimina una herramienta, el agente lo refleja automáticamente. No estás manteniendo una copia congelada de la superficie de API de otra persona.

Compáralo con el camino anterior. Construir un conector personalizado significaba importar una especificación OpenAPI, mapear cada operación y rehacerlo cuando la API subyacente cambiaba. MCP colapsa eso en "apunta a un servidor, autentica, listo". Si has trabajado con el árbol de decisión de extensibilidad de Copilot, piensa en MCP como una nueva rama, más fina, del lado "conectar a un sistema externo" — una que está ganando terreno rápido porque supone muchísimo menos trabajo.

¿Qué necesito antes de que MCP funcione?

Necesitas tener activada la orquestación generativa. MCP no funciona bajo la orquestación clásica basada en topics — el agente tiene que poder razonar sobre qué herramienta llamar, así que el orquestador generativo es un requisito previo obligatorio, no una preferencia.

Esto confunde a la gente porque es fácil pasarlo por alto. Añades una herramienta MCP, pruebas el agente, y no pasa nada — el modelo nunca invoca al servidor. La solución es casi siempre el ajuste de orquestación generativa, que permite al agente seleccionar herramientas de forma dinámica en función de sus descripciones. Eso tiene una consecuencia de diseño que merece decirse sin rodeos: las descripciones de tus herramientas ahora forman parte de tu superficie de seguridad. El orquestador las lee para decidir qué llamar. Una descripción vaga o engañosa no es solo mala UX — es una forma de que la herramienta equivocada se dispare en el turno equivocado.

Una nota sobre transporte que va a pillar a cualquiera que lea posts antiguos: Copilot Studio admite el transporte Streamable HTTP. Server-Sent Events (SSE) quedó obsoleto en la especificación de MCP y Copilot Studio eliminó el soporte de SSE después de agosto de 2025. Si un servidor que estás integrando todavía solo habla SSE, no conectará, y el error no siempre dirá por qué.

¿Cómo conecto un agente a un servidor MCP?

La vía recomendada es el asistente de incorporación de MCP dentro de Copilot Studio: en la pestaña Tools de tu agente, elige Add a tool > New tool > Model Context Protocol, rellena el nombre del servidor, la descripción y la URL, elige un tipo de autenticación y crea la conexión.

El asistente paso a paso admite tres modelos de autenticación, y la elección importa más que el hacer clic:

• Ninguna (None) — sin autenticación. Está bien para una fuente de datos públicos de solo lectura, es peligroso para cualquier otra cosa. Si un servidor no necesita autenticación y toca datos de negocio, eso es un hallazgo, no una comodidad.
• Clave de API (API key) — el agente envía una clave compartida en una cabecera o parámetro de consulta. Simple, pero significa que cada usuario del agente actúa ante el servidor como la misma identidad. Pierdes la atribución por usuario.
• OAuth 2.0 — cada usuario se autentica y da su consentimiento de forma individual, y el agente actúa en su nombre. Esta es la que recomiendo a los clientes para cualquier cosa que lea o escriba datos reales, porque preserva la identidad de extremo a extremo. Copilot Studio admite configuración manual de OAuth, registro dinámico de clientes y descubrimiento dinámico completo.

Una vez que la conexión existe, añades las herramientas y recursos del servidor al agente desde esa misma página de Tools. Si todavía no tienes un servidor, Microsoft documenta cómo crear un nuevo servidor MCP; si quieres acceso nativo a Microsoft Graph, hay un ejemplo trabajado para el Microsoft MCP Server for Enterprise que conecta Copilot Studio a Graph con credenciales federadas en lugar de un secreto almacenado — que es el patrón a copiar.

¿Dónde está el límite de gobernanza de MCP?

Esta es la frase para subrayar: el acceso MCP en Copilot Studio pasa por los conectores de Power Platform, así que cualquier política de Data Loss Prevention que gobierne los conectores también gobierna tus servidores MCP. Si una política de DLP regula los conectores de Power Platform, regula el servidor MCP y cada herramienta que expone.

Ese único hecho, documentado en la guía de conexión a un servidor, es la mejor noticia de toda esta funcionalidad. No necesitas un régimen de gobernanza separado para MCP. Las políticas de DLP que configuras en el centro de administración de Power Platform son el plano de control. Así que antes de que un solo servidor MCP se acerque a un entorno de producción, decide en qué entorno viven los agentes conectados a MCP, y aplica en ese entorno una política de DLP que refleje qué pueden tocar esos conectores.

Para agentes construidos fuera de Copilot Studio, Microsoft está estandarizando el registro a través de Agents 365 — puedes traer tu propio servidor MCP y hacer que se apruebe de forma centralizada antes de que sea utilizable. Esa puerta de aprobación es el patrón empresarial: los servidores se revisan, luego se ponen a disposición, no se descubren y conectan de forma ad hoc.

¿Cuál es el riesgo real, y cómo lo contengo?

El riesgo real no es el protocolo — es lo que hace una llamada a herramienta. Una herramienta MCP es una función que el modelo puede invocar con argumentos que él mismo eligió. Conecta un servidor cuyas herramientas puedan escribir en un sistema de registro, y le has dado a un modelo de lenguaje la capacidad de tomar acciones irreversibles a partir de una conversación. El modo de fallo es un agente confundido o manipulado que llama a la herramienta equivocada con las entradas equivocadas.

Microsoft lo dice directamente en la documentación: cuando te conectas a un servidor MCP que no es de Microsoft, tú eres responsable de las herramientas y recursos a los que accedes a través de él. Esa responsabilidad no se transfiere al propietario del servidor. Así que el plan de contención se escribe solo:

• Prioriza las herramientas de lectura sobre las de escritura hasta que confíes en la orquestación. Un error de recuperación es vergonzoso; un error de escritura es un incidente.
• Limita el alcance de OAuth al mínimo. Los scopes que solicitas definen el radio de la explosión. "Leer el pedido" es un riesgo distinto de "modificar el pedido", y la pantalla de consentimiento debería decirlo.
• Trata las descripciones de las herramientas como superficie de ataque. Como el orquestador generativo selecciona herramientas a partir de sus descripciones, aplica aquí el mismo razonamiento que usas contra la inyección de prompts. Si ya has blindado agentes con patrones de defensa contra la inyección de prompts en Copilot Studio, extiende esa mentalidad a qué herramientas podría disparar una entrada no confiable.
• Aísla a los agentes conectados a MCP en su propio entorno con una política de DLP ajustada a esos conectores, para que un agente demasiado entusiasta no pueda llegar más allá de lo que ese entorno permite.

Hay una lección de un proyecto reciente de arquitectura de agentes que encaja perfectamente aquí. El instinto del equipo era tratar "¿a qué sistema nos conectamos?" como el problema difícil. No lo era. El problema difícil era la gobernanza y la identidad como capas transversales sobre cada herramienta a la que el agente pudiera acceder — decididas una vez, por adelantado, en lugar de añadidas después de que la demo funcionara. Traza ese límite antes de que se conecte el primer servidor MCP, y MCP es un regalo. Trázalo después, y estás auditando producción.

¿A qué puedo conectar un agente hoy?

Dos tipos de servidor MCP: servidores de Microsoft de primera parte, en los que puedes confiar con menos escrutinio, y servidores de terceros o propios, cuyo riesgo asumes tú. Empieza por los de primera parte para aprender el patrón antes de apuntar un agente a algo que construiste la semana pasada.

Por el lado de Microsoft, el Microsoft MCP Server for Enterprise expone Microsoft Graph — operaciones de identidad y acceso — a un agente de Copilot Studio, y el ejemplo trabajado usa credenciales federadas en lugar de un secreto de cliente almacenado, que es el patrón a copiar para cualquier servidor OAuth. Microsoft también distribuye servidores de línea de negocio, como uno para Dynamics 365 finance and operations, que añades a un agente de la misma forma — lo eliges de la lista de Model Context Protocol, creas una conexión, listo. Una advertencia que conviene saber: estos servidores evolucionan rápido, y Microsoft ya ha retirado y sustituido versiones estáticas tempranas de algunos de ellos, así que fija tu integración a la versión actual del servidor y revisa la documentación antes de asumir que una herramienta todavía existe.

Para tus propios sistemas, construyes u hospedas un servidor MCP y lo registras. Si esos sistemas están orquestados por más de un agente, aplica la misma disciplina que gobierna la orquestación multiagente en Azure: decide qué agente es dueño de qué escritura, antes de que dos agentes puedan actuar sobre el mismo registro. El modo de fallo de "varios agentes, un sistema de registro, sin propietario claro" no es hipotético — es el segundo incidente que tiene todo equipo después de que el primero le enseñara a registrarlo todo.

¿Deberías usar MCP?

Sí — con un límite trazado de antemano. MCP es la forma más limpia que Microsoft ha lanzado para conectar agentes de Copilot Studio a sistemas empresariales en vivo, y solo va a extenderse a medida que más proveedores publiquen servidores. Los equipos que ganan con esto no son los que conectan más rápido. Son los que deciden el entorno, la política de DLP, el modelo de autenticación y la postura de lectura frente a escritura antes de que el agente pueda llamar a algo real. Si acabas resolviendo problemas, Microsoft mantiene una guía dedicada de resolución de problemas de MCP — empieza por ahí, y empieza comprobando si la orquestación generativa está activada.

Preguntas frecuentes

¿Funciona MCP con agentes clásicos (basados en topics) de Copilot Studio?

No. MCP requiere orquestación generativa, porque el orquestador del agente tiene que razonar sobre qué herramienta llamar en tiempo de ejecución. Si tu agente usa la orquestación clásica basada en topics, las herramientas MCP no se dispararán hasta que cambies de modo de orquestación.

¿Cómo se gobierna MCP — necesito un nuevo conjunto de políticas?

Ningún régimen nuevo. La conectividad MCP pasa por los conectores de Power Platform, así que tus políticas de Data Loss Prevention existentes en el centro de administración de Power Platform ya gobiernan los servidores MCP y sus herramientas. Coloca esos agentes en un entorno controlado y ajusta ahí la política de DLP.

¿Qué autenticación debería usar para un servidor MCP de producción?

OAuth 2.0 para cualquier cosa que lea o escriba datos reales, porque preserva la identidad y el consentimiento por usuario. Las claves de API hacen que todos los usuarios actúen como una única identidad compartida, lo que rompe la atribución. Reserva "Ninguna" para fuentes genuinamente públicas y de solo lectura.

¿Quién es responsable cuando un servidor MCP que no es de Microsoft se comporta mal?

Tú. La documentación de Microsoft es explícita en que, cuando te conectas a un servidor MCP externo, eres dueño de las herramientas y recursos a los que accedes a través de él. Revisa los servidores de terceros antes de conectarlos, y limita su acceso de forma estricta.

¿Por qué no conecta mi servidor MCP en absoluto?

Las dos causas más comunes son que la orquestación generativa esté desactivada y que el servidor use el transporte SSE obsoleto. Copilot Studio admite el transporte Streamable HTTP y eliminó el soporte de SSE después de agosto de 2025.