- Copilot Studio permite crear herramientas y acciones que conectan agentes con APIs, datos y aplicaciones, con orquestación generativa para elegir la mejor opción en cada conversación.
- Las tools se configuran por secciones (Details, Inputs, Completion), controlando nombre, descripción, recogida automática de inputs, autenticación y tipo de respuesta al usuario.
- GitHub Copilot coding agent automatiza tareas de desarrollo de extremo a extremo usando GitHub Actions, trabajando como un compañero asíncrono que abre y actualiza pull requests.
- El uso conjunto de Model Context Protocol, herramientas declarativas y coding agent amplía capacidades, manteniendo seguridad, auditoría y control humano sobre los cambios.
Si trabajas con Copilot, GitHub y Copilot Studio, seguro que ya has oído hablar de las famosas acciones y herramientas que permiten a estos agentes hacer cosas “del mundo real”: enviar correos, consultar APIs, mover código entre ramas o abrir pull requests. Aquí vamos a ver, con calma y en castellano de España, cómo encaja todo eso bajo el paraguas de un tutorial completo de Copilot Actions, unificando tanto la parte de herramientas en Copilot Studio como el nuevo coding agent de GitHub.
La idea es que termines entendiendo qué son las herramientas, acciones y agentes, cómo se configuran, qué tipos existen (conectores, REST, MCP, uso de ordenador, etc.), qué papel juega la orquestación generativa y cómo GitHub Copilot coding agent utiliza GitHub Actions y MCP para automatizar tareas de desarrollo de principio a fin.
Qué es una “acción” o herramienta para Copilot
En el ecosistema de Copilot Studio, las llamadas tools (herramientas) son los bloques básicos que permiten al agente interactuar con sistemas externos: servicios en la nube, APIs, bases de datos o incluso aplicaciones de escritorio con interfaz gráfica. Cada herramienta encapsula una capacidad concreta que el agente puede ejecutar cuando la conversación o el flujo de trabajo lo requieren.
Por ejemplo, puedes dotar a tu agente de herramientas para enviar correos con Outlook 365, consultar la previsión del tiempo, leer y escribir en Dataverse o publicar mensajes en Teams. Todas estas capacidades se exponen como tools que Copilot puede seleccionar automáticamente mediante orquestación generativa o que tú puedes invocar de forma explícita desde un tema (topic) concreto.
Con la orquestación generativa activa, el agente es capaz de elegir por sí mismo la herramienta o el tema más adecuado, o incluso tirar de búsquedas sobre la base de conocimiento, para responder a lo que pide el usuario. En modo clásico, con la orquestación desactivada, solo puede usar topics que tú has diseñado, aunque sigues teniendo la opción de llamar a herramientas desde esos temas de forma totalmente controlada.
Todo esto convierte a las tools de Copilot Studio en una especie de “superpoder” para tus agentes, porque ya no se limitan a chatear: pasan a ejecutar acciones reales contra tus sistemas corporativos, siempre respetando la autenticación y las políticas que definas.
Tipos de herramientas que puedes usar como Copilot Actions
Copilot Studio ofrece varios mecanismos para añadir herramientas a un agente y, en la práctica, todas pueden verse como acciones que Copilot puede disparar para cumplir una tarea. Cada tipo de herramienta está pensado para un escenario distinto, desde conectar APIs ya existentes hasta automatizar el uso del propio ordenador.
El primer gran bloque son los connectors de Power Platform, que permiten conectar con servicios propietarios o de terceros. Aquí entran dos variantes: los conectores precompilados (prebuilt) que ya vienen listos para usar contra cientos de servicios conocidos, y los conectores personalizados (custom connectors), que te permiten definir una conexión a un sistema propio o una API interna de tu organización.
Otro mecanismo clave es el agent flow, una especie de flujo de trabajo que define una secuencia de acciones encadenadas. Este tipo de tool es ideal cuando quieres que el agente ejecute varios pasos en orden, por ejemplo consultar un sistema, transformar los datos y luego devolver el resultado formateado.
También tienes las herramientas tipo Prompt, que son peticiones de un solo turno a un modelo, con la posibilidad de enganchar fuentes de conocimiento y de generar código para analizar datos. Se usan, sobre todo, cuando necesitas que el modelo haga una tarea bien acotada, y pueden funcionar con modos como Quick Response para ajustar la respuesta. Se usan, sobre todo, cuando necesitas que el modelo haga una tarea bien acotada, pero con acceso a información adicional.
Completan el conjunto los tools basados en REST API, Model Context Protocol (MCP) y Computer use. Los dos primeros se centran en conectarse a APIs HTTP o a servidores MCP para exponer herramientas y recursos extra; el tercero permite que el agente controle una interfaz gráfica (web o escritorio) simulando clicks, menús y escritura, lo que abre la puerta a automatizar aplicaciones que no tienen API.
Crear una nueva herramienta en Copilot Studio paso a paso
Para que tu agente pueda aprovechar todas estas capacidades, necesitas crear y configurar las tools directamente en Copilot Studio. El proceso es guiado, pero conviene conocer qué se hace en cada paso para evitar malentendidos y sacar el máximo partido a la orquestación generativa.
Lo primero es abrir tu agente desde la sección Agents y entrar en la página de Tools. Desde ahí, eliges la opción de añadir una herramienta y, en el panel correspondiente, seleccionas crear una New tool. Copilot Studio te mostrará la lista de tipos disponibles: Prompt, Agent flow, Computer use, Custom connector, Model Context Protocol o REST API, según lo que quieras integrar.
Una vez elegido el tipo de tool, aparecen los pasos de configuración específicos. Por ejemplo, si optas por un Prompt, tendrás que definir la plantilla de prompt y las instrucciones al modelo, los parámetros de entrada, las fuentes de conocimiento que puede consultar y el formato y las restricciones de la respuesta.
Cuando termines esa configuración inicial, puedes pulsar Save o Publish, según proceda, para que la herramienta quede creada. Después se activa la opción Add and configure, que añade la tool al agente y abre una página de configuración completa en la que puedes seguir ajustando detalles y cambiar parámetros más adelante tantas veces como necesites.
En cualquier momento, desde la página de Tools del agente, podrás volver a editar la configuración de esa herramienta: su nombre, descripción, entradas, comportamiento de salida y demás aspectos finos que influyen mucho en cómo la orquestación generativa decide cuándo invocarla.
Secciones de configuración: Details, Inputs y Completion
La página de configuración de una herramienta estándar se divide en tres bloques principales: Details, Inputs y Completion. Entender qué hace cada uno es clave para que tus Copilot Actions se comporten de forma fiable y predecible dentro de las conversaciones con los usuarios.
En la sección Details defines los datos básicos de la tool. Aquí eliges el nombre, que es lo que verás en la lista de herramientas del agente, y la descripción, que es todavía más importante porque la orquestación generativa dependerá mucho de ese texto para decidir en qué contexto debe usar la herramienta y cuándo no es pertinente invocarla.
Dentro de Details también se muestran opciones avanzadas, como permitir que el agente decida dinámicamente si usar la herramienta o no, pedir confirmación al usuario antes de ejecutar la acción o configurar el tipo de autenticación. Puedes indicar si la tool debe correr con credenciales del usuario final o con credenciales del “maker” (el autor), e incluso añadir una descripción de lo que se va a autenticar para que el usuario tenga claro qué está autorizando.
La sección Inputs muestra todas las entradas que necesita la herramienta en forma de tabla, con una línea por input. Por defecto, cada entrada se rellena con la opción “Dynamically fill with AI”, lo que significa que el agente intentará deducir el valor necesario a partir del contexto disponible, como los mensajes recientes de la conversación.
Si el agente no encuentra un valor adecuado, generará preguntas de forma automática al usuario para recopilar esa información. Con el botón de personalización puedes ajustar el nombre visible y la descripción de cada input, definir cómo se interpreta la respuesta (texto libre, entidad predefinida, etc.), la lógica de reintentos y validaciones extra para el dato introducido.
En caso de que quieras total control, puedes cambiar un input a Custom value y asignarle un valor fijo, una variable o una fórmula Power Fx. De esta forma, el agente no preguntará nada al usuario sobre ese campo, porque ya sabe exactamente qué debe enviar a la herramienta al ejecutarla.
En la sección Completion decides qué ocurre cuando la tool termina su trabajo. Puedes dejar que el propio agente genere una respuesta contextual basada en el resultado recibido, o bien crear tú una respuesta formateada a medida, con posibilidad de insertar variables de salida y aplicar fórmulas Power Fx para adaptarla.
Cómo responde la herramienta: opciones de salida y tarjetas adaptativas
Dentro de Completion, la opción “After running” te permite escoger entre varias estrategias de respuesta. La más sencilla es “Don’t respond”, donde el agente integra internamente la salida de la herramienta en su mensaje posterior sin que la tool emita nada directamente al usuario.
Otra alternativa es activar “Write the response with generative AI”, dejando que el modelo se encargue de redactar un mensaje bien hilado utilizando los datos de salida, algo muy práctico cuando quieres respuestas ricas pero no te apetece escribir una plantilla compleja.
Si necesitas un control milimétrico, puedes seleccionar “Send specific response” y redactar tú mismo el texto con placeholders para variables, dándole al usuario un formato uniforme cada vez que se ejecute la herramienta, lo que suele ir muy bien en entornos más formales.
Por último, existe la opción de “Send an adaptive card”, que permite generar respuestas interactivas con botones y acciones, muy útiles cuando quieres que el usuario pulse, confirme o elija algo tras el resultado del tool. En paralelo, decides qué variables de salida estarán disponibles para el propio agente o para otras herramientas que se encadenen a continuación.
En el caso concreto de los servidores MCP conectados como tools, la pantalla de configuración es algo distinta: el bloque de Details se mantiene, pero se sustituyen Inputs y Completion por secciones de Tools y Resources, donde se listan las herramientas y recursos disponibles en ese servidor MCP, lo cual da una visión rápida de todo lo que Copilot puede hacer a través de esa conexión.
Selección de herramientas e input collection automática
Cuando defines una herramienta en Copilot Studio, no solo le dices lo que hace, sino cuándo y cómo debe usarse. El nombre, la descripción y la información asociada a los inputs sirven como guía al orquestador generativo para reservar esta tool para los escenarios adecuados y evitar que se dispare a destiempo.
La orquestación tiene en cuenta elementos como el contexto actual de la conversación, la intención detectada en el mensaje del usuario, los inputs disponibles, las salidas previas de otras tools y el historial de invocaciones recientes. Con todo ello, el agente decide si tiene sentido ejecutar una herramienta, cuál de todas y con qué parámetros.
Una de las ventajas es que el propio agente se ocupa de la recogida de inputs. No hace falta que diseñes manualmente nodos de pregunta para cubrir cada dato necesario, algo que puede ser muy pesado en flujos complejos. El orquestador analiza qué falta para poder llamar a la tool y lanza preguntas concretas al usuario para completar esos campos.
Cuando trabajas en modo generativo, las herramientas suelen devolver su resultado directamente al agente, que lo incorpora a la respuesta final que verá el usuario. No obstante, si te interesa, puedes configurar que la tool emita siempre una respuesta explícita, tanto generativa como basada en una plantilla fija.
En cualquier caso, sigues teniendo la opción de invocar una herramienta desde un topic de forma explícita. Eso te permite componer experiencias híbridas: temas clásicos con ramas, condiciones y nodos, combinados con tools que ejecutan acciones concretas, como consultar un tiempo meteorológico o crear un registro en un sistema externo.
Llamar a una tool desde un topic: ejemplo práctico
Imagina que quieres construir un topic sencillo tipo “Obtener el tiempo”. En Copilot Studio irías a la página de Topics, crearías un nuevo tema con ese nombre y definirías una serie de frases disparadoras, como “¿Va a llover?”, “previsión de hoy”, “qué tiempo hace” o “dame el pronóstico”.
Dentro de ese topic, añadirías un nuevo nodo mediante el botón de Add node y escogerías la opción de “Add a tool”. En el cuadro de selección verás pestañas para herramientas básicas, conectores o tools en general, y ahí localizarías la herramienta que previamente has configurado para consultar el tiempo.
Una vez que el nodo de acción se ha añadido al topic, tu flujo ya sabe llamar a la herramienta en el momento adecuado. Solo necesitarías ajustar las salidas, guardar el topic y probarlo en el emulador para asegurarte de que las preguntas de input y la respuesta final son las que buscas.
Este patrón se puede replicar con cualquier otra tool: desde enviar un correo hasta registrar una incidencia, pasando por leer datos de una tabla o invocar un flujo de Power Automate que haga una tarea más compleja aprovechando las integraciones de la plataforma.
Además, si combinas esto con la orquestación generativa, el propio agente puede decidir cuándo usar ese topic o esa tool sin que el usuario tenga que seguir un guion rígido, lo que se traduce en una experiencia conversacional mucho más natural y menos “robótica”.
Información específica sobre MCP y recursos asociados
En el caso de las herramientas basadas en Model Context Protocol, la interfaz muestra información adicional muy útil. Puedes ver en una tabla los nombres de todas las tools MCP disponibles y los recursos asociados que el servidor expone al agente, cada uno en su propia fila para identificar rápidamente qué hace.
Este enfoque permite que un único servidor MCP agrupe varias capacidades (por ejemplo, Playwright para pruebas end-to-end o herramientas propias de GitHub), y que Copilot acceda a ellas como si fueran acciones nativas. La ventaja es que no dependes de un único proveedor, sino de un estándar abierto para compartir contexto y herramientas con los LLMs.
La configuración de estos servidores se suele hacer mediante archivos JSON en el repositorio o en la configuración del entorno, lo que encaja muy bien con flujos de CI/CD basados en Git, donde los cambios de configuración se revisan con el mismo rigor que el código.
Una vez que el servidor MCP está declarado y accesible, tu agente puede tomar decisiones de forma autónoma sobre qué herramienta MCP llamar y cuándo, ampliando muchísimo el abanico de tareas que puede asumir sin intervención humana directa.
Autenticación y seguridad de las herramientas en Copilot Studio
Muchas herramientas necesitan algún tipo de autenticación para funcionar de forma segura, sobre todo si tocan datos sensibles o APIs internas: casos típicos son Dynamic Prompt, herramientas que hablan con Dataverse o servicios corporativos protegidos.
Las tools siempre se ejecutan en el runtime del agente en el contexto del usuario, y no pueden correr si no existe un mecanismo de autenticación configurado. Copilot Studio soporta dos grandes tipos de credenciales: las del usuario final (End user) y las del creador o administrador de la solución (Maker-provided).
Con credenciales de usuario final, cada persona solo accede a los datos para los que tiene permisos, manteniendo las fronteras de seguridad que ya estén definidas en la organización. Con credenciales del maker, en cambio, es la identidad del autor la que se usa para acceder a recursos compartidos, algo útil cuando no quieres que todo el mundo tenga acceso directo individual al sistema.
En la configuración de la herramienta también puedes activar o desactivar la opción de solicitar confirmación al usuario antes de correr la action, lo cual añade una capa extra de transparencia para que la gente sepa qué está a punto de hacer el agente y qué datos se van a tocar.
Además, desde la misma pantalla de configuración puedes encender o apagar una tool para el agente. Si desactivas la herramienta, el agente deja de usarla, pero se puede volver a activar más adelante sin perder la configuración previa.
Si necesitas una limpieza más radical, siempre puedes eliminar la herramienta del agente. Solo tienes que ir a la lista de tools, abrir el menú de más opciones y elegir la opción de borrado; tras confirmar, la herramienta desaparece de la lista y deja de estar disponible para ese agente de forma permanente.
GitHub Copilot coding agent y su relación con GitHub Actions
Más allá de Copilot Studio, GitHub ha lanzado su propio Copilot coding agent, un agente de software engineering que funciona como un compañero asíncrono y está profundamente integrado con GitHub Actions. En la práctica, actúa como otro desarrollador de tu equipo al que puedes delegar tareas concretas.
El coding agent arranca cuando le asignas una tarea, normalmente a través de un issue, el panel de agentes o desde Copilot Chat en el IDE. A partir de ahí, genera un entorno de desarrollo efímero y configurable basado en GitHub Actions, examina el repositorio en busca de contexto (issues relacionados, discusiones de pull requests, instrucciones personalizadas) y empieza a trabajar.
Está pensado para asumir tareas de complejidad baja o media, como corregir bugs, mejorar la cobertura de tests o refactorizar secciones de código que te quitan tiempo. Su objetivo es que puedas centrarte en las partes más interesantes del desarrollo, mientras él se ocupa de lo más tedioso.
Una vez en marcha, el coding agent abre un pull request en modo borrador, con etiqueta de trabajo en progreso, y va empujando commits según avanza. Cada paso clave se registra y puedes seguir la evolución casi como si vieras a un compañero trabajando en directo, pero sin necesidad de estar encima todo el rato.
Aunque el agente hace el trabajo, tú mantienes siempre el control: revisas el código, pides cambios, añades comentarios y decides si se aprueba o no la propuesta. El objetivo es que la experiencia sea colaborativa y transparente, no un “autopilot” opaco que suba código a producción sin revisión.
Diferencias entre coding agent y asistentes de código tradicionales
Las herramientas clásicas de autocompletado o ayuda en el IDE son, básicamente, asistentes en tiempo real que te sugieren líneas o bloques de código mientras escribes, pero todo se queda en tu máquina, en tu sesión local y bajo tu control inmediato.
Con ese modelo, sigues siendo tú quien crea la rama, escribe los mensajes de commit, empuja los cambios, abre el pull request, discute los comentarios, reitera… todo ese circuito consume una buena cantidad de tiempo y atención que podría destinarse a tareas más creativas.
El coding agent, en cambio, está orientado a automatizar el flujo completo de desarrollo dentro del propio GitHub: crea ramas, genera commits, abre y actualiza pull requests, ejecuta tests y linters en el entorno de Actions y deja todo preparado para que solo tengas que revisar y aprobar.
Además, existe una diferencia clara con el llamado agent mode en el IDE. El agent mode trabaja de forma síncrona contigo, en tu editor favorito (VS Code, JetBrains, Eclipse, Xcode, etc.), mientras que el coding agent opera asíncronamente en segundo plano, como si fuese “otra persona” del equipo que se encarga de issues mientras tú haces otras cosas.
Ambos utilizan peticiones premium de Copilot, aunque el coding agent solo necesita una por tarea y se apoya en minutos de GitHub Actions para ejecutar todo su trabajo, por lo que conviene tenerlo en cuenta al planificar costes y uso en equipos grandes.
Seguridad del coding agent: sandbox, permisos y auditoría
GitHub ha diseñado el coding agent con seguridad por defecto, ejecutándolo en un entorno aislado (sandbox) con acceso limitado a internet y permisos reducidos sobre el repositorio. Esto minimiza la superficie de ataque y protege tanto el código como la infraestructura de CI/CD.
El agente solo puede hacer push a ramas que crea él mismo, normalmente con prefijo tipo copilot/*, de manera que no toca directamente main ni otras ramas manejadas por el equipo. Así se evita que un error del agente acabe rompiendo la rama principal del proyecto.
Otro aspecto importante es que el coding agent no puede aprobar ni fusionar sus propios pull requests. Todas las propuestas pasan por una revisión humana independiente, y además los workflows de CI/CD en Actions no se ejecutan hasta que alguien los autoriza, añadiendo una capa más de protección.
Cada commit generado por el agente se marca como coautor, lo que mejora la trazabilidad y deja claro en el historial qué cambios han sido impulsados por Copilot y cuáles por personas del equipo. A esto se suman los logs de auditoría y las protecciones de rama ya existentes en la organización, que siguen aplicándose normalmente.
En conjunto, este diseño garantiza que el coding agent trabaje bajo las mismas reglas y políticas que el resto del equipo, con controles y límites claros que encajan con prácticas de seguridad empresarial.
Cómo usar GitHub Copilot coding agent en tu día a día
El flujo de uso del coding agent se parece bastante a delegar una tarea a un compañero. Empiezas asignando un issue al usuario @github en GitHub.com, GitHub Mobile o a través de la CLI, o bien creando una tarea desde el panel de agentes accesible desde prácticamente cualquier página del repositorio.
También puedes iniciarlo desde Copilot Chat en tu IDE favorito, usar Hey Copilot o desde cualquier herramienta que soporte Model Context Protocol. Gracias a MCP, incluso puedes pasarle capturas de pantalla o mockups en issues cuando tienes servidores MCP de visión configurados, ampliando las formas en que describes lo que quieres que haga el agente.
Cuando la tarea arranca, el coding agent abre un pull request en modo borrador con una etiqueta de . A partir de ese momento, verás cómo va registrando sus progresos a través de commits y actualizaciones del PR, siempre dentro del flujo estándar de GitHub.
Cuando termina, actualiza el título y la descripción del pull request, te menciona para la revisión y se queda pendiente de tus comentarios. Si necesitas cambios, puedes etiquetar de nuevo a @copilot en el propio PR y el agente utilizará ese feedback para iterar sobre el código hasta llegar al resultado que buscabas.
Entre bambalinas, todo esto ocurre en un entorno seguro impulsado por GitHub Actions, donde el agente puede ejecutar tests, linters, herramientas externas y cualquier acción que hayas incluido en tu catálogo de más de 25.000 acciones comunitarias, lo que hace que el entorno sea completamente personalizable según las necesidades de tu proyecto.
Potenciar Copilot con MCP: herramientas y contexto ampliados
Si combinas Copilot con el Model Context Protocol y con Copilot Labs, el agente gana acceso a un ecosistema de herramientas y datos externos enormemente más amplio. MCP es un estándar abierto que define cómo compartir contexto y capacidades entre aplicaciones y modelos de lenguaje.
El coding agent ya incluye servidores MCP para Playwright y GitHub, lo que le permite, por ejemplo, lanzar pruebas end-to-end o interactuar con APIs de GitHub sin tener que reinventar la rueda. Además, puedes definir tus propios servidores MCP adaptados a tus sistemas y flujos de trabajo particulares.
La configuración suele hacerse a nivel de repositorio, mediante un archivo JSON que describe los servidores y las herramientas expuestas. Una vez activos, el agente puede utilizarlos de manera autónoma para resolver tareas, consultar datos, generar artefactos y, en definitiva, reducir la carga manual sobre el equipo.
Es importante tener en mente que el acceso a internet del coding agent pasa por un firewall con reglas por defecto que solo permiten ciertos hosts necesarios para GitHub y para descargar dependencias. Si necesitas accesos adicionales, tendrás que ajustarlos según las políticas de tu organización.
Con este enfoque, MCP convierte a Copilot en un socio de desarrollo mucho más context-aware, capaz de orquestar herramientas diversas como si fueran Copilot Actions, pero con un diseño estándar y extensible que no te ata a un único proveedor o tecnología.
Al combinar las herramientas declarativas de Copilot Studio con el coding agent y MCP en GitHub, obtienes un ecosistema en el que tus agentes pueden hablar con usuarios, conectar con APIs, usar el ordenador, abrir pull requests y pasar por CI/CD casi sin fricción, manteniendo control, seguridad y trazabilidad en todo momento.
Redactor apasionado del mundo de los bytes y la tecnología en general. Me encanta compartir mis conocimientos a través de la escritura, y eso es lo que haré en este blog, mostrarte todo lo más interesante sobre gadgets, software, hardware, tendencias tecnológicas, y más. Mi objetivo es ayudarte a navegar por el mundo digital de forma sencilla y entretenida.