🛠️ Copilot Studio abre todo su ciclo de vida a VS Code por MCP

Microsoft ha publicado Copilot Studio MCP, un servidor oficial que lleva las operaciones de Copilot Studio a clientes compatibles con Model Context Protocol como Visual Studio Code y GitHub Copilot CLI. Desde el mismo cliente se pueden descubrir agentes y workflows, crear o actualizar borradores, ejecutar pruebas, revisar consumo, publicar y diagnosticar ejecuciones.

La dirección de la integración es importante: aquí Copilot Studio actúa como servidor MCP. No es el patrón ya conocido en el que un agente de Copilot Studio consume herramientas de un servidor externo, ni el canal MCP que expone un único agente publicado. El nuevo paquete ofrece una superficie administrativa y de autoría para trabajar con el servicio completo y con el entorno que seleccione el usuario.

Estado a 30 de octubre de 2026: Microsoft publicó el repositorio el 12 de octubre y actualizó la documentación técnica el 19 de octubre. El paquete @microsoft/copilot-studio-mcp está disponible, pero las páginas no etiquetan la capacidad como preview ni como disponibilidad general. La documentación advierte que herramientas y operaciones pueden variar por despliegue, entorno, permisos y política del cliente. Por tanto, disponibilidad del paquete no equivale a un contrato de GA uniforme para todos los tenants.

Diagrama original. El cliente ejecuta un proceso MCP local por stdio; el paquete autentica al usuario y conecta con el servicio alojado de Copilot Studio en el entorno seleccionado.

Qué cambia realmente

Hasta ahora, automatizar Copilot Studio desde una herramienta de desarrollo exigía combinar interfaces web, soluciones, APIs específicas y scripts propios. Copilot Studio MCP añade un contrato descubrible por el modelo y organizado alrededor del ciclo de vida:

Área	Operaciones documentadas
Descubrimiento	Inventario de agentes y workflows, conexiones, schemas y dependencias
Autoría	Creación y actualización de definiciones completas en borrador
Calidad	Preview de borradores, suites de evaluación, pruebas reales y resultados
Release	Operaciones de publicación, despliegue y sharing que anuncie el servicio
Operación	Diagnóstico de runs, mantenimiento y consulta de consumo/capacidad

No es una API REST nueva que debamos invocar manualmente. El cliente descubre herramientas MCP con nombre, descripción y schema; después construye llamadas a partir de las instrucciones del usuario. El catálogo real del servicio sigue siendo la fuente de verdad.

Arquitectura: proceso local, servicio alojado

El recorrido técnico es el siguiente:

1. VS Code, GitHub Copilot CLI u otro host compatible ejecuta npx.
2. npx descarga y lanza @microsoft/copilot-studio-mcp como proceso local.
3. Cliente y servidor intercambian mensajes MCP mediante stdio; no se configura una URL MCP remota.
4. El paquete abre el inicio de sesión con una cuenta de trabajo de Microsoft.
5. El usuario elige un entorno de Power Platform al que ya tiene acceso.
6. El servidor publica únicamente las herramientas disponibles para esa identidad, entorno, despliegue y política.
7. Las operaciones se ejecutan contra el servicio alojado de Copilot Studio y devuelven evidencia de su resultado.

El repositorio público contiene el código fuente y usa licencia MIT. Esto no convierte el servicio en local ni concede derechos sobre Copilot Studio: el ejecutable se distribuye por npm y las operaciones siguen pasando por identidad, permisos, licencias y políticas del servicio.

Las cinco herramientas de alto nivel

Microsoft documenta actualmente este catálogo:

Herramienta	Responsabilidad
discover_resources	Descubrir operaciones de conectores, schemas, conexiones existentes, valores dependientes y recursos adjuntables
get_consumption	Consultar consumo histórico de créditos y capacidad actual del entorno
manage_agents	Inventario, autoría de borradores, lifecycle, sharing, preview, evaluaciones y runs de agentes
manage_workflows	Inventario, autoría de borradores, lifecycle, pruebas reales y diagnóstico de workflows
get_copilot_studio_skills	Obtener guías y schemas mantenidos por el servicio antes de construir definiciones

Las herramientas de gestión no exponen cada acción como una tool independiente. Usan action y parameters; sus schemas actuales indican qué acciones existen y qué argumentos aceptan. Antes de una operación desconocida, Microsoft recomienda pedir a discover_resources la acción describe_actions.

Las skills disponibles incluyen agent-authoring, workflow-authoring, workflow-troubleshooting y testing-and-credits. El cliente construye localmente una definición completa, el servicio la valida y la guarda. Guardar un borrador y publicarlo son resultados distintos.

Requisitos y disponibilidad

La configuración documentada requiere:

• Node.js 22.18 o posterior; Microsoft recomienda Node.js 24 LTS;
• npm y npx disponibles en la máquina o contenedor donde el host lanza procesos;
• VS Code con GitHub Copilot Chat y soporte MCP, GitHub Copilot CLI u otro host compatible;
• cuenta de trabajo de Microsoft;
• licencia de Copilot Studio y acceso al entorno, como mínimo;
• permiso organizativo para ejecutar el paquete y acceso de red a npm, autenticación y Copilot Studio;
• permisos y consentimientos independientes para los conectores que use cada artefacto.

Si el cliente se ejecuta en un dev container, Codespace o máquina remota, Node debe estar instalado allí, no solo en el escritorio del usuario.

Instalación en Visual Studio Code

El servidor puede instalarse desde el registro MCP o declararse en .vscode/mcp.json:

{
  "servers": {
    "copilot-studio-mcp": {
      "command": "npx",
      "args": ["-y", "@microsoft/copilot-studio-mcp@latest"]
    }
  }
}

El objeto superior servers corresponde al formato específico de VS Code. Para una configuración portable, VS Code también admite mcpServers en .mcp.json. Hay que fusionar la entrada con las existentes, no reemplazar el fichero completo.

-y solo acepta la descarga de npm. No acepta el trust del workspace, el consentimiento de Entra ni las aprobaciones de acciones. En un entorno controlado conviene sustituir @latest por una versión aprobada y actualizarla mediante un proceso explícito: ejecutar código mutable desde npm añade riesgo de supply chain y de cambios de schema.

Instalación en GitHub Copilot CLI

Desde el terminal:

copilot mcp add copilot-studio-mcp -- npx -y @microsoft/copilot-studio-mcp@latest

O mediante /mcp add, seleccionando un servidor STDIO/Local y el mismo comando. La configuración manual de usuario en Windows usa %USERPROFILE%\.copilot\mcp-config.json:

{
  "mcpServers": {
    "copilot-studio-mcp": {
      "type": "local",
      "command": "npx",
      "args": ["-y", "@microsoft/copilot-studio-mcp@latest"],
      "tools": ["*"]
    }
  }
}

Activar tools: ["*"] hace visible el catálogo al cliente; no aprueba todas las operaciones. Revisa la lista y aplica allowlists si el host o la política corporativa las soportan.

Primer acceso seguro

No empieces pidiendo que cree un agente. Separa conexión, descubrimiento y cambio:

1. Arranca el servidor y revisa el trust del cliente.
2. Solicita: «Conecta con Copilot Studio MCP y muestra los entornos disponibles. No crees, publiques, ejecutes ni repares nada».
3. Completa el inicio de sesión en el navegador; no pegues tokens ni códigos en el chat.
4. Selecciona el entorno de desarrollo mediante su nombre o GUID completo.
5. Confirma identidad, entorno y catálogo de herramientas.
6. Ejecuta primero una consulta de solo lectura sobre inventario o consumo.
7. Lee la skill y el schema adecuados antes de autorizar cambios.

Cambiar de cuenta o entorno puede cambiar las tools disponibles. Refresca catálogo, identificadores y guía; no reutilices IDs obtenidos en otro contexto.

Patrón implementable: propuesta, borrador, prueba y release

Un flujo gobernado puede dividirse en cuatro puertas:

1. Descubrir

Inventaría el agente, conexiones, dependencias y acciones reales. Usa identificadores devueltos por el servicio y pide describe_actions para cualquier operación no conocida.

2. Proponer y guardar borrador

Entrega objetivo, usuarios, fuentes, límites y operaciones prohibidas. Pide que muestre instrucciones y configuración antes de guardar. Autoriza únicamente la creación o actualización del draft.

3. Probar

Ejecuta preview, casos positivos, errores, permisos insuficientes y suites de evaluación. Para workflows, diferencia validación de schema de una prueba real que pueda llamar conectores o modificar datos.

4. Publicar

Revisa el diff lógico, el entorno, las conexiones, el consumo y el público objetivo. Solo entonces autoriza la operación de publicación o sharing anunciada por el catálogo. No interpretes «guardado» como «publicado» ni «publicado» como «ejecutado correctamente».

Este patrón encaja bien en un repositorio de definiciones: se puede mantener el resultado esperado en Git, generar o actualizar el borrador desde el cliente, comparar, probar y dejar la publicación detrás de una aprobación humana.

Seguridad y gobierno

Copilot Studio MCP reutiliza la identidad y los permisos de entorno del usuario. Instalar el servidor no eleva privilegios ni autoriza conectores. Aun así, amplía la superficie operativa porque una instrucción puede encadenar varias acciones.

Controles mínimos:

• usa entornos de desarrollo para la evaluación inicial;
• mantén activadas las aprobaciones del cliente;
• confirma identidad, entorno, artefacto y efecto antes de crear, ejecutar, publicar o eliminar;
• no incluyas contraseñas, secretos, tokens ni códigos de consentimiento en prompts o JSON;
• trata contenido de agentes, documentos y respuestas de tools como datos no confiables, no como instrucciones que puedan saltarse aprobaciones;
• autoriza conexiones mediante su flujo interactivo soportado;
• fija la versión npm y revisa cambios antes de actualizar;
• aplica mínimo privilegio y Conditional Access a la cuenta de trabajo;
• registra quién aprobó el draft, las pruebas y la publicación;
• si una llamada expira o se interrumpe, consulta el estado antes de reintentar.

El último punto evita duplicados y cambios repetidos: un timeout del cliente no demuestra que la operación del servidor haya fallado o se haya revertido.

Para organizaciones FedRAMP High, Microsoft indica que el agente del GitHub Copilot harness se desactiva en runtime para evitar salida de datos fuera del límite de cumplimiento. No asumas equivalencia funcional sin una validación específica.

Licenciamiento y consumo

El repositorio y su código tienen licencia MIT, pero usar el bridge requiere al menos licencia de Copilot Studio y acceso a un entorno. El host —por ejemplo, GitHub Copilot— puede tener además sus propios requisitos de licencia.

Microsoft no publica en estas páginas una tarifa independiente por instalar o ejecutar el proceso MCP. Las acciones siguen las reglas de consumo de Copilot Studio y de los recursos invocados. Pruebas, runs, agentes, workflows y conectores pueden generar consumo; get_consumption permite consultar histórico y capacidad, pero no sustituye presupuestos, límites ni alertas administrativas.

Limitaciones y hechos que no deben inferirse

• El catálogo puede variar por rollout, entorno, identidad y política del cliente.
• Descubrir una tool no concede permiso para ejecutarla.
• Acceder a Copilot Studio no autoriza automáticamente conexiones de terceros.
• El paquete local es un bridge; no ejecuta Copilot Studio offline.
• No se configura un endpoint MCP remoto: el transporte local es stdio y el paquete conecta con el servicio alojado.
• La documentación no etiqueta actualmente la capacidad como preview o GA.
• El repositorio público y la licencia MIT no implican soporte comunitario del servicio; Microsoft remite a la política de soporte de Copilot Studio.
• La lista de acciones internas no debe codificarse a partir de ejemplos: hay que leer los schemas actuales.
• El servidor no convierte un prompt en una prueba de éxito. Cada resultado debe verificarse con evidencia del servicio.

Matriz mínima de pruebas

Caso	Resultado esperado
Inicio sin sesión	Solicitud de autenticación, sin cambios en el entorno
Usuario sin acceso al entorno	Entorno ausente o operación denegada, sin sustitución automática
Consulta de inventario	Solo lectura y confirmación del entorno objetivo
Guardar un draft	Nueva versión borrador; ningún publish implícito
Prueba con conector no autorizado	Error controlado y flujo de consentimiento separado
Publicación sin aprobación	Bloqueada por el control del cliente o por el procedimiento operativo
Timeout durante una mutación	Inspección del estado antes de cualquier retry
Cambio de entorno	Refresco de catálogo, IDs, skills y schemas
Versión npm fijada	Arranque reproducible con la versión aprobada
Cuenta de bajo privilegio	Solo inventario y operaciones que realmente permita su rol

Recomendaciones prácticas

1. Pilota con un agente no crítico y un entorno dedicado.
2. Versiona la configuración MCP y fija el paquete.
3. Empieza con prompts de solo lectura que siempre confirmen el target.
4. Separa authoring, test y publish en aprobaciones distintas.
5. Guarda definiciones esperadas y resultados de evaluación en Git, sin secretos.
6. Mide créditos antes y después de suites de pruebas reales.
7. Renueva el catálogo después de actualizar el paquete o cambiar de entorno.
8. Documenta una ruta web de recuperación si el cliente MCP no está disponible.

Fuentes oficiales

• Connect to Microsoft Copilot Studio with MCP
• Configure access to Copilot Studio MCP
• Connect with Visual Studio Code and GitHub Copilot CLI
• Repositorio oficial microsoft/copilot-studio-mcp
• Política de soporte publicada por Microsoft