GitHub Copilot MCP: ejemplo de configuración y 26 llamadas reales para un reporte semanal de la competencia

Si trabajas en marketing en una empresa de software en Ciudad de México, Bogotá o Buenos Aires, es probable que cada lunes alguien pregunte qué publicó la competencia la semana pasada. Armamos ese reporte con datos reales el 6 de noviembre de 2026, entre las 00:17 y las 00:38, hora de Singapur. Hicimos 26 llamadas a la API de EveryInfra para tres herramientas de productividad que compiten en toda la región: Notion, ClickUp y Asana. En la semana del 30 de octubre al 5 de noviembre de 2026, ClickUp publicó 14 piezas entre YouTube, TikTok e Instagram; Asana publicó 3 y Notion solo 2. También probamos una cuenta de comercio electrónico de la región, Mercado Libre México, y ahí apareció la trampa más instructiva de todo el ejercicio: el usuario global de Instagram devolvió una lista vacía y el usuario del país sí devolvió datos. Un límite va primero: en nuestra máquina de pruebas no tenemos suscripción a Copilot, así que la configuración, el issue y el workflow del lado de Copilot son ejemplos basados en la documentación de GitHub y no los ejecutamos dentro de Copilot. Cada número medido viene de una respuesta real de la API de EveryInfra.

La idea de este artículo es usar el coding agent de GitHub Copilot una sola vez. El agente lee unas cuantas respuestas reales por MCP, entiende los campos y escribe un script normal de Python junto con un workflow programado. Después de que apruebas el pull request, GitHub Actions ejecuta el script cada semana y ningún modelo vuelve a intervenir. Con los precios del catálogo, cuatro plataformas para tres marcas cuestan USD 0.011961 por semana, alrededor de USD 0.0518 al mes. De las 26 llamadas, solo 13 tuvieron costo, por un total de USD 0.007228; las otras 13 fueron 5 resultados vacíos (4 por usuarios mal adivinados y 1 porque el canal correcto de Asana no publicó videos esa semana), seis respuestas 503 de LinkedIn, un tiempo de espera agotado y un error de parámetro, y ninguna generó cobro.

Todo lo que comento sobre GitHub proviene del Changelog de GitHub o de docs.github.com, consultados el 6 de noviembre de 2026. Cada número del lado de EveryInfra proviene de una respuesta real guardada en el momento de la llamada.

La respuesta corta: con github copilot mcp el trabajo se divide en dos

El error más común con este reporte es mezclar dos trabajos distintos. Uno es escribir el código; el otro es recolectar los datos cada semana. El 2026-10-28 GitHub publicó dos funciones que corresponden justo a esas dos mitades. La primera son los conectores y la configuración MCP del repositorio, que permiten a Copilot llamar herramientas externas mientras trabaja. La segunda son nuevas herramientas, disparadores y controles de costo para Copilot Automations, que permiten a Copilot correr con un calendario (changelog de herramientas, disparadores y controles de costo).

Si Copilot recolecta los datos y escribe el reporte cada semana, cada ejecución abre una sesión del cloud agent. La documentación de automatizaciones dice que cada ejecución consume créditos de IA y minutos de Actions (documentación de Copilot automations, sección de cobro). Un reporte con formato fijo no necesita que un modelo tome decisiones cada lunes. Por eso proponemos que el modelo trabaje una sola vez, cuando escribe el código, y que lo demás quede en manos de un script que no cambia de humor.

El flujo es corto. Abres un issue con las reglas, los usuarios de cada marca y un ejemplo de prueba. Asignas el issue a Copilot. Antes de escribir código, el agente usa las herramientas MCP de EveryInfra para leer el catálogo y hacer tres o cuatro llamadas de prueba, así ve los nombres reales de los campos y los formatos de fecha. Luego escribe weekly_report.py y .github/workflows/weekly-report.yml y abre un pull request para que lo revises. Después del merge, un job programado de Actions envía POST /api/v1/social, arma el archivo Markdown y lo sube al repositorio.

La tabla compara las dos maneras de correr el reporte. Los hechos vienen de la documentación de GitHub; la columna de la izquierda es nuestra recomendación.

El valor de 30 créditos es el tope mínimo por ejecución que permite la página para crear automatizaciones (documentación para crear automations), y un crédito de IA equivale a USD 0.01 (cobro por uso para cuentas individuales). La documentación no dice cuántos créditos consume una ejecución típica, así que no lo adivinamos. Lo único seguro es que la ruta del script en Actions consume cero créditos de IA por semana. También puedes combinar las dos: el script produce los números cada lunes y, de vez en cuando, le pides a Copilot que lea cuatro reportes seguidos y escriba un análisis corto.

Si de todos modos quieres que Copilot corra cada semana, una automatización puede usar las herramientas MCP de la configuración del repositorio, así que el JSON de este artículo también sirve ahí. Las reglas de disparo y de cobro están en la documentación de Copilot automations; antes de activar una, fija un tope de créditos por ejecución y por semana.

Qué cambió con el changelog del 28 de octubre

Mucha gente busca "github copilot mcp" después de leer la entrada del changelog del 2026-10-28 titulada "Connect your tools to Copilot without all the setup". Esa entrada anuncia los servidores MCP verificados por GitHub, también llamados conectores, en vista previa pública. Eliges un servicio, inicias sesión y apruebas el acceso; después el conector funciona en la app de Copilot, en Copilot CLI, en VS Code, en Copilot en la nube y en GitHub Mobile (entrada del changelog). En el lanzamiento hay 26 servicios, entre ellos Slack, Figma, Notion, Sentry, Linear, Atlassian Rovo, Cloudflare, Vercel y Work IQ. La activación llega de forma gradual a todos los planes de Copilot; en Business y Enterprise un administrador debe activar la política "Editor preview features", y si la empresa usa una lista permitida de MCP también debe agregar esos servicios.

Para nuestro reporte, el lanzamiento importa por tres razones. Primera: EveryInfra no está entre los 26 conectores y GitHub no ha verificado nuestro servidor; para usar nuestros datos lo agregas en la configuración MCP del repositorio o en tu configuración personal, con un bloque corto de JSON. Segunda: la documentación de conectores dice que funcionan en sesiones locales y en sesiones del sandbox en la nube, pero todavía no en sesiones que corren en GitHub Actions, como la que se abre cuando asignas un issue a Copilot (documentación de Copilot connectors). La página de configuración MCP del repositorio repite esa advertencia al inicio (documentación de configuración MCP del repositorio). Hay un hilo de la comunidad sobre el lanzamiento donde se juntan dudas de usuarios (discusión 211002 en GitHub Community).

Tercera razón: el nombre. Mucha gente todavía dice "Copilot coding agent", pero en docs.github.com la misma función ahora se llama "Copilot cloud agent" (página sobre el cloud agent), y el enlace viejo de MCP del coding agent lleva a la página nueva. En este artículo los dos nombres se refieren a la misma función.

Configuración copilot coding agent mcp: el JSON del repositorio

La configuración MCP del repositorio se pega en la página del repositorio, en Settings, luego Copilot, luego MCP servers. El formato es un objeto mcpServers; cada clave es el nombre de un servidor y cada servidor debe tener las claves type y tools. Un servidor remoto lleva además url, y si pide autenticación usa headers. El valor de un encabezado puede referirse a un secreto cuyo nombre empieza con COPILOT_MCP_, escrito como $COPILOT_MCP_API_KEY o ${COPILOT_MCP_API_KEY} (documentación de configuración MCP del repositorio). La documentación recomienda con fuerza poner en tools solo herramientas concretas y de lectura, porque el agente las usa por su cuenta sin preguntarte. El endpoint MCP remoto de EveryInfra es https://api.everyinfra.com/mcp y usa una llave Bearer, no OAuth, así que encaja en lo que la documentación admite. Este es el ejemplo de configuración:

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer ${COPILOT_MCP_EVERYINFRA_API_KEY}"
      },
      "tools": [
        "everyinfra_list_capabilities",
        "everyinfra_call_api",
        "everyinfra_get_job"
      ]
    }
  }
}

¿Por qué solo tres herramientas? A las 00:16, hora de Singapur, enviamos tools/list sin llave, y a las 00:26 lo repetimos con llave. Las dos respuestas listaron 12 herramientas en 16,247 bytes. El reporte necesita tres: una para leer el catálogo, otra para hacer una llamada y otra para leer un trabajo asíncrono. Las otras nueve sirven para ver el saldo, generar un enlace de recarga, abrir un ticket de soporte o resolver un captcha. Nada de eso ayuda al reporte, y tenerlas en la lista solo le da al agente más maneras de equivocarse.

Cada una de las 12 herramientas trae annotations de MCP, y la respuesta real muestra un detalle que la documentación no menciona. everyinfra_call_api tiene readOnlyHint: false y destructiveHint: true, porque puede cobrar. La documentación de GitHub dice que la revisión de código de Copilot solo usa herramientas cuyo annotations.readOnlyHint es true en tools/list, y descarta las que no tienen esa anotación o la tienen en false. Resultado: con una sola configuración del repositorio, el cloud agent puede llamar a nuestra herramienta de datos y la revisión de código no puede. Para este reporte es lo correcto, porque revisar código no debería gastar dinero en datos. Si prefieres que la revisión de código no toque ninguna herramienta MCP, la documentación también da un interruptor para eso. La especificación de MCP explica estas anotaciones en su sección de herramientas (especificación MCP, tools).

Hay dos límites más. El cloud agent y la revisión de código solo admiten herramientas MCP, no recursos ni prompts del servidor; nuestro reporte usa solo herramientas, así que no afecta. El segundo es cómo verificar la configuración: asignas un issue a Copilot, abres el registro de la sesión y buscas el paso "Start MCP Servers", que al final lista las herramientas que arrancaron. Un usuario de Reddit configuró un servidor MCP de Atlassian para el coding agent y vio una conexión exitosa con "retrieved 0 tools" (hilo en r/GithubCopilot). Si te pasa, compara primero cada nombre de tools con los nombres de tools/list; deben coincidir letra por letra.

Dónde van los secretos: dos llaves, dos cajones

Aquí es donde más configuraciones fallan. GitHub ahora tiene un tipo de secreto propio para el cloud agent, llamado Agents, junto a los de Actions, Codespaces y Dependabot. La documentación dice que el cloud agent no puede leer secretos ni variables de Actions, Codespaces o Dependabot; solo lee los de Agents. Y un secreto de Agents cuyo nombre empieza con COPILOT_MCP_ solo se entrega a servidores MCP, no queda como variable de entorno para los comandos que corre el agente (secretos y variables para el cloud agent). Tu workflow programado usa secretos de Actions y no puede leer los de Agents. Por eso el reporte necesita dos llaves.

La misma documentación agrega tres reglas. El nombre de un secreto no puede empezar con GITHUB_. El tipo Agents tiene secretos y variables, pero en un sandbox en la nube el agente solo recibe secretos, no variables. Y un secreto de Agents sin el prefijo COPILOT_MCP_ queda como variable de entorno para los comandos y herramientas que corre el agente, así que no agregues una llave de EveryInfra sin prefijo salvo que quieras que el agente ejecute el script con acceso a red. Un secreto de Agents a nivel de organización puede servir a varios repositorios, algo útil para una agencia que lleva el monitoreo de varios clientes en repositorios separados.

¿Por qué no usar una sola llave con un solo nombre? Por tres motivos. GitHub separa los dos cajones, así que un mismo nombre no ayuda. Dos llaves de EveryInfra con nombres claros hacen legible el historial de llamadas: si una se filtra o gasta de más, sabes cuál fue. Y la protección de push de GitHub solo bloquea por defecto los formatos de llave que conoce, y el de EveryInfra no está entre ellos (changelog de push protection); si el agente escribe la llave en un archivo de prueba, el push puede pasar. Por eso el issue debe decir que la llave solo se lee de una variable de entorno.

El firewall agrega otra trampa. Por defecto, un firewall limita la red del cloud agent, pero la documentación dice que solo se aplica a los procesos que el agente inicia con su herramienta Bash, no a los procesos de servidores MCP (documentación del firewall, limitaciones). Las llamadas MCP a EveryInfra funcionan; pero si el agente intenta ejecutar el nuevo weekly_report.py dentro de la sesión, la petición a api.everyinfra.com choca con el firewall y aparece una advertencia en el cuerpo del pull request. Tienes dos salidas: agregar api.everyinfra.com a la lista permitida en Internet access y poner una tercera llave sin prefijo para los comandos del agente, o pedirle al agente que guarde una respuesta real de MCP como fixture para que las pruebas no usen la red. Recomendamos la segunda, porque la primera deja una llave en el entorno de comandos del agente, y aunque los registros enmascaran los secretos, no hace falta abrir esa puerta.

Cómo escribir el issue para el agente

La página de buenas prácticas de GitHub dice que una tarea para Copilot debe explicar el problema, los criterios de aceptación y los archivos que se van a tocar, y que las tareas pequeñas y claras funcionan mejor (buenas prácticas para tareas de Copilot). En este reporte lo más importante es la lista de usuarios y el ejemplo de prueba. No dejes que el agente adivine usuarios: en nuestra prueba, tres usuarios adivinados devolvieron listas vacías, sin error y sin cobro, y el reporte habría perdido filas en silencio. Este es un ejemplo de issue:

## Task
Write weekly_report.py and .github/workflows/weekly-report.yml.
Every Monday at 09:00 America/Mexico_City, read config/competitors.yml.
For each brand, collect posts from last Monday 00:00 to Sunday 23:59 UTC.
Write reports/<ISO year>-W<week>.md and commit it to main.

## Data (check parameters with everyinfra_list_capabilities, then one test call each)
- YouTube: youtube/user_posts, param url (channel link), since=last Monday, mode=async
- TikTok: tiktok/user_videos, param username, limit=30
- Instagram: instagram/user_posts, param username, limit=30, mode=async
- LinkedIn: linkedin/company_posts, param company (the part after /company/), limit=20

## Handles (do not change, do not guess; LinkedIn names not checked yet)
notion:  youtube https://www.youtube.com/@Notion | tiktok notionhq | instagram notionhq | linkedin notionhq
clickup: youtube https://www.youtube.com/@ClickUpProductivity | tiktok clickup | instagram clickup | linkedin clickup-app
asana:   youtube https://www.youtube.com/channel/UC2BoogM0AqwOJyoSp1S4ClQ | tiktok asana | instagram asana | linkedin asana
mercadolibre_mx: instagram mercadolibre.mex   # the global handle "mercadolibre" returns 0

## Must handle
1. TikTok: drop is_pinned=true rows, then filter by posted_at. Do not stop at the first old row.
2. YouTube posted_at can be relative text such as "1d ago". Convert it from the fetch time.
3. HTTP 503 or status=failed: wait retry_after, retry once, then write "not collected this week".
4. Zero rows: write "0 this week" and list the handle at the end for a manual check.
5. Read the key only from EVERYINFRA_API_KEY. Never write it to a file or a log.
6. Tests read JSON fixtures in tests/fixtures/ (real MCP responses) and use no network.

## Test example
With the fixtures: ClickUp TikTok this week = 4 posts (not 0, not 7), total views = 60463.
Mercado Libre MX Instagram this week = 5 posts, total likes = 1132.

Escribimos el issue en inglés a propósito: los nombres de campos, los parámetros y los mensajes de error de la API están en inglés, y así el agente no tiene que traducir nada. La última sección es la más importante. Sus valores esperados salen de respuestas reales: la de tiktok/user_videos para ClickUp a las 00:19 y la de instagram/user_posts para Mercado Libre México a las 00:33, ambas hora de Singapur. En la de ClickUp, las primeras 3 de 10 filas eran videos fijados de 2024 con 20.1 millones, 7.5 millones y 3.2 millones de vistas. La lista viene de más nueva a más vieja, pero los fijados siempre van primero. Un script que toma la primera fila como la más reciente dirá que ClickUp publicó en TikTok por última vez en 2024; uno que lee en orden y se detiene en la primera fila vieja contará 0; uno que quita los fijados pero no filtra por fecha contará 7. La respuesta correcta es 4, y con ese número en el issue basta una corrida de pruebas para saber si el código está bien.

El caso Mercado Libre México: el usuario equivocado no avisa

Este ejemplo merece su propia sección porque es el error que más vemos en equipos de la región. A las 00:32, hora de Singapur, pedimos las 10 publicaciones más recientes del usuario de Instagram mercadolibre. La API respondió con éxito, 0 resultados, y reembolsó el cobro. No hubo error, no hubo advertencia, solo una lista vacía. A las 00:33 repetimos con mercadolibre.mex, la cuenta de México, y recibimos 10 publicaciones; 5 caen dentro de la semana, con 1,132 likes en total. Lo mismo nos pasó con YouTube: @ClickUp devolvió vacío tras 40.3 segundos y el canal real era @ClickUpProductivity; @asana agotó el tiempo y el canal correcto se encontró con su URL de canal.

Las marcas grandes de América Latina suelen tener una cuenta por país, y a veces la cuenta "global" está casi vacía o no existe con ese nombre. Para un reporte semanal, un 0 es peligroso porque parece un dato: "esta semana no publicaron". Por eso el issue pide que cada cuenta con 0 resultados aparezca al final del reporte en una lista de "revisar usuario". El costo de equivocarse en el usuario es cero en dinero, porque los vacíos se reembolsan, pero puede costar semanas de conclusiones falsas si nadie lo nota.

Las cinco publicaciones de Mercado Libre México en la semana muestran además qué tipo de contenido rinde en una cuenta de comercio electrónico. Tres pertenecen a su campaña de automovilismo "Unidos por la velocidad" (una del 2026-10-30 y dos del 2026-11-01); la de mayor alcance, con 470 likes, celebra las 300 carreras de un piloto. Otras dos, del 2026-11-03, son de un concurso con premio en pesos. Si tu equipo vende en línea en México, esa es la vara contra la que se compara tu propia cuenta, y el script la calcula sin que nadie copie números a mano.

Una ida y vuelta real: qué envía Copilot y qué responde el servidor

No ejecutamos Copilot, pero MCP es un protocolo abierto. Cuando el agente llama una herramienta, envía una petición JSON-RPC tools/call estándar por el transporte Streamable HTTP: cada mensaje es un POST y el cliente debe aceptar tanto application/json como text/event-stream (especificación MCP, transportes). Con curl podemos enviar la misma petición que enviaría el agente y ver qué responde nuestro servidor. La enviamos el 2026-11-06 a las 00:26:28, hora de Singapur:

curl -s https://api.everyinfra.com/mcp \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"everyinfra_call_api",
                 "arguments":{"platform":"tiktok","action":"user_videos",
                              "params":{"username":"notionhq","limit":5}}}}'

El servidor respondió HTTP 200 a los 31.1 segundos. El campo result.content[0].text traía un JSON de 13,272 caracteres con 5 videos de TikTok de Notion, cada uno con posted_at, view_count, like_count, is_pinned y más. El video más reciente era del 2026-05-26, con 22,800 vistas. Al final, billing decía charged: true y charged_usd: 0.000556. Eso mismo es lo que ve el agente antes de escribir código: aprende los nombres de los campos, aprende que las fechas vienen en formato ISO y aprende que esa cuenta no publica en TikTok desde hace más de cinco meses.

Corrimos el reporte primero con 26 llamadas reales

Antes de pedirle al agente que escriba el script, necesitas saber cuál es la respuesta correcta. Por eso corrimos el reporte nosotros primero, el 2026-11-06 de las 00:17 a las 00:38, hora de Singapur. La ventana son siete fechas UTC, del 2026-10-30 al 2026-11-05. Cada capacidad y sus parámetros salen del catálogo gratuito GET /api/v1/social/catalog: youtube/user_posts (requiere url), tiktok/user_videos (requiere username), instagram/user_posts (requiere username, asíncrona en el catálogo) y linkedin/company_posts (requiere company). Las páginas de cada capacidad están en publicaciones de usuario en YouTube, videos de usuario en TikTok, publicaciones de usuario en Instagram y publicaciones de empresa en LinkedIn.

La tabla es el núcleo del reporte y dice tres cosas. Primera: el ritmo de las tres marcas es muy distinto. ClickUp publicó 14 piezas en tres plataformas; en Instagram, 7 de sus 10 publicaciones más recientes son de esta semana, en TikTok publicó 4 y en YouTube 3, todas relacionadas con IA. Segunda: Notion y Asana casi dejaron TikTok. Sus videos más recientes son del 2026-05-26 y del 2026-06-04; en el caso de Asana, 7 de los 10 más recientes son de ese mismo día de junio y los otros 3 son de 2025 y 2023. Un "0 esta semana" es una señal útil, pero solo si sabes que el usuario es correcto, porque un usuario equivocado también da 0. Tercera: Instagram es la única plataforma donde las tres publicaron esta semana; si solo puedes vigilar una, la tabla apunta ahí.

Estos resultados tienen límites. La ventana es de una semana y la muestra, de tres marcas. En TikTok e Instagram pedimos 10 filas por cuenta; para el Instagram de ClickUp, 10 filas cubrieron 9 días, suficiente para una empresa de software. Una marca de consumo es otra historia: la cuenta global de DJI en Instagram publicó sus 10 piezas más recientes entre el 2026-11-01 y el 2026-11-05, así que 10 filas cubren solo 5 días. El límite debe ajustarse a la frecuencia de cada cuenta, y pedir más filas no cuesta más, porque estas capacidades cobran por llamada y no por fila.

Un reporte de muestra con los datos de esta semana

Los conteos no bastan: un equipo de marketing quiere saber qué publicación funcionó mejor y de qué hablaba. Armamos a mano, con las respuestas reales, la tabla que el script debería generar. Muestra la mejor publicación por marca y plataforma; en TikTok ya sin fijados, en Instagram por likes y en YouTube por vistas. Las fechas de YouTube se calculan a partir de "1d ago" y "5d ago" en el momento de la consulta, así que solo son exactas al día.

La muestra deja ver dos cosas que los conteos esconden. La primera es que ClickUp usa humor de oficina en TikTok: sus 4 videos de la semana (2026-11-05, 2026-11-04, 2026-11-02 y 2026-10-30) suman 60,463 vistas y 3,392 likes, y el mejor llegó a 27,400. Un día antes de la ventana, el 2026-10-29, publicó uno con 145,200 vistas. Parece tener un éxito grande más o menos cada semana, así que si el reporte usara una ventana móvil de "los últimos 7 días desde la ejecución", ese tipo de video entraría y saldría según la hora. La segunda es que las tres hablan de IA: el único video de YouTube de Notion explica cómo conectar ChatGPT o Claude, los tres de ClickUp son de IA, el resumen semanal de ClickUp en Instagram del 2026-10-30 menciona su nuevo Salesforce MCP, y Asana promovió su asistente Dash dos días antes de la ventana, el 2026-10-28.

Para comparar likes también hace falta la base. El Instagram de ClickUp tuvo 7 publicaciones con 273 likes en total, de 1 a 73 por publicación; Asana tuvo 3 con 82; Notion una sola con 143, más que cualquier publicación individual de ClickUp. Por conteo parece que ClickUp domina Instagram; por likes por publicación, gana Notion. Recomendamos tres columnas: número de publicaciones, interacción total y mediana por publicación, más una cuarta con la mejor publicación. El script calcula las cuatro con campos que ya vienen en la respuesta, sin llamadas ni costos extra.

Seis trampas de las llamadas reales y cómo las resuelve el script

La mitad de las 26 llamadas no cobró. Las agrupamos: 13 cobraron, 5 devolvieron resultados vacíos y se reembolsaron (4 por un usuario mal adivinado y 1 porque el canal correcto de Asana no tuvo videos nuevos esa semana), 7 respondieron 503 (6 de publicaciones de empresa en LinkedIn y 1 llamada síncrona de YouTube que agotó el tiempo) y 1 fue nuestra prueba planeada de un error 422 por parámetro equivocado. Ninguna falla cobró. El total fue USD 0.007228, exactamente 13 × USD 0.000556.

Cada grupo de fallas corresponde a una parte del script; la sección "Must handle" del issue sale de esta tabla.

La segunda trampa necesita detalle. Medimos el tiempo hasta la primera respuesta de las 8 llamadas síncronas que trajeron datos o agotaron el tiempo (las 6 respuestas 503 de LinkedIn llegaron en 2.2 a 2.4 segundos y el 422 en 0.2, así que no entran en la gráfica): las tres de TikTok tardaron 22.2, 68.9 y 21.6 segundos, y la de MCP 31.1. Una de YouTube con el usuario correcto tardó 11.5 segundos; una con usuario equivocado tardó 40.3 en devolver vacío, y otra devolvió 503 a los 89.8. El mensaje de error dice que una llamada síncrona espera hasta 85 segundos, y la de TikTok de ClickUp quedó a solo 16 segundos de ese límite. En Actions esperar no es problema, pero un tiempo agotado obliga a repetir la llamada. Por eso conviene el modo asíncrono cuando el catálogo lo permite: el envío devuelve un job_id al instante y el script consulta GET /api/v1/jobs/{job_id} cada pocos segundos, sin costo.

La quinta trampa es LinkedIn. Entre las 00:18 y las 00:38, hora de Singapur, linkedin/company_posts respondió 503 seis veces para Notion, ClickUp, Asana y google, la empresa de ejemplo que sugería el propio mensaje de error. El código fue unavailable y cada respuesta tenía billing.charged_usd en 0. Después de la tercera falla, next_steps indicó que hubo tres fallas en diez minutos sin cobro, sugirió una llamada con el ejemplo y, si también fallaba, preguntar al usuario antes de abrir un ticket. Al mismo tiempo linkedin/company_profile sí funcionaba: a las 00:34 leyó la página de empresa de Notion en 6.2 segundos, cobró USD 0.000556 y trajo 1,137,647 seguidores y 7,211 empleados. En una semana sin publicaciones, la columna de LinkedIn puede mostrar al menos el cambio de seguidores. El catálogo seguía marcando la capacidad como disponible esa noche, así que el script no puede confiar solo en el catálogo; un reporte que dice "LinkedIn sin datos esta semana" vale más que uno que pierde una columna sin avisar. Cómo se reembolsan las fallas y cómo revisarlas está en nuestra guía de conciliación de reembolsos por falla.

Cómo se ve el script: el workflow que debería entregar el agente

El pull request del agente debería traer al menos dos archivos. Abajo va un ejemplo de workflow; las reglas clave vienen de la documentación de GitHub Actions. Un schedule usa UTC por defecto y ahora acepta timezone con un nombre IANA, como America/Mexico_City. El intervalo mínimo es de 5 minutos. Al inicio de cada hora las ejecuciones programadas pueden retrasarse y con mucha carga algunas en cola pueden descartarse, por eso la documentación sugiere evitar la hora en punto. Las ejecuciones programadas solo usan la rama por defecto, y en un repositorio público se desactivan tras 60 días sin actividad (eventos que disparan workflows, schedule). Los cinco campos de cron siguen la especificación POSIX de crontab.

name: weekly-competitor-social-report
on:
  schedule:
    - cron: "17 9 * * 1"          # Monday 09:17, not on the hour
      timezone: "America/Mexico_City"
  workflow_dispatch: {}
permissions:
  contents: write
concurrency: weekly-report
jobs:
  report:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Build report
        env:
          EVERYINFRA_API_KEY: ${{ secrets.EVERYINFRA_API_KEY }}
        run: python weekly_report.py --config config/competitors.yml --out reports/
      - name: Commit report
        run: |
          git config user.name "weekly-report-bot"
          git config user.email "weekly-report-bot@users.noreply.github.com"
          git add reports/
          git commit -m "weekly social report" || echo "nothing to commit"
          git push

El script gira alrededor de una función: envía la petición; si el estado es running, consulta con job_id; si recibe un 503, espera retry_after y reintenta una vez; al final devuelve filas o una marca de "sin datos". Este es un esqueleto basado en nuestras pruebas, con nombres de campos que coinciden con response_fields del catálogo, para que lo pegues en el issue como referencia:

import os, time, json, urllib.request, urllib.error

API = "https://api.everyinfra.com"
KEY = os.environ["EVERYINFRA_API_KEY"]          # only from the environment

def call(platform, action, params, mode="sync"):
    body = {"platform": platform, "action": action, "params": params}
    if mode == "async":
        body["mode"] = "async"
    for attempt in (1, 2):
        req = urllib.request.Request(API + "/api/v1/social", json.dumps(body).encode(),
              {"Authorization": "Bearer " + KEY, "Content-Type": "application/json",
               "User-Agent": "weekly-report/1.0"})
        try:
            data = json.load(urllib.request.urlopen(req, timeout=100))
        except urllib.error.HTTPError as e:
            err = json.load(e).get("error", {})
            if e.code == 503 and attempt == 1:
                time.sleep(err.get("retry_after", 60)); continue
            return {"unavailable": True, "code": e.code, "reason": err.get("code")}
        while data.get("status") in ("submitting", "running", "finalizing"):
            time.sleep(8)
            job = urllib.request.Request(f"{API}/api/v1/jobs/{data['job_id']}",
                  headers={"Authorization": "Bearer " + KEY, "User-Agent": "weekly-report/1.0"})
            data = json.load(urllib.request.urlopen(job, timeout=60))
        if data.get("status", "succeeded") != "succeeded":   # la tarea falló: se marca, nunca se reporta como 0
            return {"unavailable": True, "status": data.get("status"), "reason": data.get("error")}
        if "results" not in data:                              # éxito sin results: error explícito
            raise RuntimeError(f"no results field: {platform}/{action}")
        return {"rows": data["results"], "count": len(data["results"])}

Fíjate en el encabezado User-Agent: algunas reglas de protección de sitios bloquean el user agent por defecto de Python, y declarar uno claro te ahorra un 403 misterioso en el registro de Actions. El timeout=100 es un poco mayor que el límite de 85 segundos del servidor; así, si se agota el tiempo, recibes el 503 del servidor con su retry_after y no una desconexión del lado del cliente.

Las dos últimas comprobaciones son las más importantes. Si una tarea asíncrona termina con cualquier status distinto de succeeded, la función devuelve la marca unavailable y el reporte dice "sin datos esta semana". Si la tarea termina bien pero no trae el campo results, la función lanza un error y el paso de Actions queda en rojo. El reporte solo escribe "0 publicaciones esta semana" cuando la llamada de verdad salió bien con una lista vacía. Sin estas dos comprobaciones, una falla del servicio se convierte en "la competencia dejó de publicar", que es el peor error que puede cometer un reporte semanal.

Cinco cosas que revisar en el pull request

Cuando el agente entregue el pull request no necesitas leer cada línea de Python; basta revisar cinco cosas. La primera: secrets.EVERYINFRA_API_KEY aparece solo en el env del paso de datos, no se imprime con echo ni se escribe en archivos. GitHub enmascara los secretos en los registros, pero no un valor que se sube en un archivo (uso de secretos en GitHub Actions). La segunda: abre los JSON de tests/fixtures/. Deben ser respuestas reales guardadas desde MCP, con los mismos nombres de campos que la tabla de este artículo; si el agente inventó las muestras, las pruebas solo repiten su propio código.

La tercera: confirma que el ejemplo de prueba existe como prueba real, con ClickUp en 4 publicaciones y 60463 vistas en TikTok, y Mercado Libre México en 5 publicaciones y 1132 likes en Instagram. Esos números vienen de respuestas reales y el agente no puede cambiarlos; el código tiene que cuadrar con ellos. La cuarta: revisa los caminos de falla. Un 503 espera y reintenta una vez, un status: failed escribe "sin datos", cero filas agregan el usuario a la lista de revisión y un 422 no se reintenta. Si falta uno, devuelve el pull request. La quinta: un workflow en un pull request del agente solo corre después de que alguien con permiso de escritura pulsa "Approve and run workflows". Córrelo una vez con workflow_dispatch, mira el tiempo y el cobro de cada llamada en el registro de Actions, y luego aprueba el merge; también puedes cruzar cada cobro con el historial de llamadas de la consola de EveryInfra, donde las fallas aparecen sin cobro.

Costo semanal y mensual de la API con precios del catálogo

El costo tiene dos partes: el cargo de la API de EveryInfra y lo de GitHub. Nuestro cargo sale del price_usd de cada capacidad en el catálogo. Estas capacidades cobran por llamada: una llamada que trae 1 fila cuesta lo mismo que una que trae 30, y las fallas y los vacíos no cobran. Los precios también están en la página de precios de EveryInfra.

Tres marcas cuestan USD 0.011961 por semana; con 52 semanas entre 12 meses, unos USD 0.0518 al mes. Una lista más grande sigue siendo barata: 10 marcas cuestan unos USD 0.1728 al mes, 30 marcas USD 0.5183 y 100 marcas USD 1.7277. Una agencia en Bogotá que monitorea a 30 competidores para cada uno de cinco clientes, 150 marcas en total, pagaría unos USD 2.59 al mes en datos. La corrida real de esta semana costó todavía menos: YouTube cobró dos veces (la de Asana fue vacía y se reembolsó), TikTok e Instagram tres cada una y LinkedIn falló tres veces sin cobro, es decir 8 llamadas cobradas, USD 0.004448.

Del lado de GitHub hay tres costos; dos son claros y del tercero solo podemos dar un rango. El primero son los minutos de Actions: los runners estándar alojados por GitHub son gratis en repositorios públicos; los privados consumen el cómputo incluido en tu plan cada mes, USD 12 en GitHub Free y USD 18 en GitHub Pro y Team, y un runner Linux estándar cuesta USD 0.006 por minuto (cobro de GitHub Actions). Con nuestros tiempos medidos, 12 llamadas en secuencia tardan unos 5 minutos, unos USD 0.03 por semana en un repositorio privado; si el script envía todos los trabajos asíncronos primero y luego los consulta juntos, baja a uno o dos minutos. El segundo es el plan de Copilot: por ejemplo, Copilot Pro cuesta USD 10 al mes con 1,500 créditos de IA y Pro+ USD 39 con 7,000 (planes de Copilot). El tercero son los créditos de la única sesión que escribe el script; dependen del modelo y de la duración, la documentación no da un valor típico y no ejecutamos Copilot, así que no damos número. La página de uso de Copilot muestra el valor real.

Campos: cada plataforma devuelve algo distinto

El reporte compara cuatro plataformas y lo más difícil es que los campos no coinciden. El catálogo lista response_fields por capacidad; comparamos cada respuesta real contra esa lista y encontramos tres diferencias que cambian las columnas. Primera: instagram/user_posts no trajo view_count en ninguna de las 50 filas de 5 cuentas esa noche. El field_note del catálogo también dice que algunas solicitudes de Instagram no devuelven view_count, is_comments_disabled, author_follower_count ni top_comments, y que esas solicitudes traen hasta 48 publicaciones; en Instagram solo se comparan likes y comentarios. Segunda: el catálogo lista 25 campos para youtube/user_posts, pero la lista de un canal devolvió solo 14: trae view_count, title y duration, no trae like_count, comment_count ni is_paid_partnership, y posted_at viene como texto relativo. Tercera: tiktok/user_videos trajo 35 campos, la más completa y también la más pesada.

Esta tabla también va en el issue. No dejes que el agente adivine qué plataforma tiene vistas: dile que las columnas de vistas de Instagram y LinkedIn muestran "n/d" y que el reporte compara interacción como likes más comentarios. El agente descubre casi todas las diferencias al leer respuestas reales, pero con la tabla en el issue ni siquiera tiene que deducirlas.

En qué se diferencia de los artículos sobre Claude Code y ChatGPT

En el blog hay artículos cercanos sobre subagentes de Claude Code para cuentas de marca en TikTok, tareas programadas de ChatGPT como radar semanal de demanda, un reporte semanal de reseñas con Codex Cloud y el seguimiento de redes de la competencia con ChatGPT Spaces. Si quieres que ChatGPT corra el reporte por su cuenta cada semana, lee el de tareas programadas.

Este artículo se diferencia en una cosa central: la IA trabaja una sola vez, cuando escribe el código, y después corre cada semana un script común. Las ventajas son un formato estable, cero costo de modelo por semana y registros claros de Actions cuando algo falla. El costo es revisar un pull request y cambiar un archivo de configuración cuando agregas una marca o una plataforma. Si tu reporte necesita una opinión cada semana, por ejemplo por qué un video funcionó, encaja mejor el enfoque de ChatGPT; también puedes dejar que el script produzca los números y pedirle a Copilot que lea un mes de reportes y escriba un análisis.

Por qué no usar la API propia de cada plataforma

Es una pregunta razonable: cada plataforma tiene una API para desarrolladores. La respuesta es que leer el contenido público de otra empresa no es sencillo con la mayoría de esas API. Cada fila de la tabla sale de la documentación de la propia plataforma.

La API de datos de YouTube encaja bien en una parte del reporte; si solo sigues YouTube, úsala directamente. Con cuatro plataformas tendrías que mantener cuatro autenticaciones, cuatro cuotas y cuatro formatos de respuesta, y el script del agente crecería con cuatro ramas. EveryInfra pone las cuatro plataformas detrás de un solo formato de petición, un solo modelo de cobro y un solo conjunto de códigos de error, así que el script tiene una sola función call(). Para más datos de cada plataforma, revisa la API de datos de YouTube, la API de datos de TikTok, la API de datos de Instagram y la API de datos de LinkedIn. Cuando las publicaciones de empresa de LinkedIn no estén disponibles, el perfil de empresa en LinkedIn puede llenar una columna de seguidores.

Límites y precauciones

El primer riesgo es la inyección de prompts. El reporte lee el texto de publicaciones de la competencia y ese texto entra al contexto del agente por MCP. OWASP llama a esto inyección indirecta: contenido de una fuente externa, como una página web o un archivo, cambia el comportamiento de un modelo (OWASP LLM01, inyección de prompts). La página de riesgos de GitHub dice que filtra caracteres ocultos en issues y comentarios, de modo que los comentarios HTML no llegan al agente (riesgos y mitigaciones del cloud agent), pero esa descripción no cubre el texto que devuelven las herramientas MCP. El plan de este artículo reduce el riesgo: el agente lee pocas muestras al escribir código, y el reporte semanal sale de un script que nunca ejecuta el texto de una publicación como instrucción. La lista de tres herramientas también limita lo que podría hacer un agente manipulado.

El segundo punto son los permisos del agente. La documentación dice que el cloud agent solo puede subir cambios a su propia rama copilot/; una persona debe revisar y aprobar el merge de su pull request, y el agente no puede marcarlo como listo, aprobarlo ni fusionarlo. Un workflow en su pull request solo corre cuando alguien con permiso de escritura pulsa "Approve and run workflows", así que el workflow del agente no puede gastar tu presupuesto de API antes de tu revisión. El tercer punto es que un horario de Actions no es una alarma exacta: las ejecuciones cerca de la hora en punto pueden retrasarse y con mucha carga pueden descartarse. Por eso la ventana de datos debe ser "del lunes al domingo pasados" y no "7 días hacia atrás desde la ejecución"; si no, un retraso de una hora pierde una hora de datos. En un repositorio público los workflows programados se detienen tras 60 días sin actividad, y el commit semanal del reporte cuenta como actividad.

El cuarto punto es nuestro propio alcance. Solo leemos contenido público: publicaciones, videos y conteos de interacción de cuentas públicas de marca. No podemos leer cuentas privadas, gasto en anuncios ni datos de audiencia. La caída de LinkedIn esa noche es un ejemplo real: el script debe tolerar el hueco y el reporte debe decirlo. Además, GitHub y EveryInfra no tienen ninguna relación comercial; este artículo solo usa la configuración MCP pública de GitHub para conectarse a nuestra API pública.

Cambios recientes

• 2026-10-28: GitHub lanzó los servidores MCP verificados, o conectores, en vista previa pública con 26 servicios, de forma gradual para todos los planes de Copilot (changelog). Qué significa para ti: Slack o Notion ya se conectan en un paso, pero una API de datos de terceros sigue necesitando la configuración MCP del repositorio, y los conectores aún no funcionan en sesiones de Actions.
• 2026-10-28: Copilot Automations puede usar herramientas de servidores MCP propios y sumó 24 disparadores por eventos de GitHub, 20 herramientas de GitHub y topes de créditos por ejecución, día, semana y mes (changelog). Ese mismo día empezaron las automatizaciones compartidas, cobradas al dueño del repositorio (changelog de automatizaciones compartidas), y VS Code ya puede administrar automatizaciones en la nube (changelog de automations en VS Code). Qué significa para ti: una ejecución semanal de Copilot ya es posible, pero cada una consume créditos; pon un tope primero.
• 2026-10-28: Copilot pasó a ser una experiencia conectada en la nube; las sesiones corren por defecto en un sandbox y la cuota incluida de Actions se volvió un fondo en dólares compartido entre runners y sandboxes (changelog). Qué significa para ti: los minutos del workflow del reporte y el tiempo de sandbox del agente salen del mismo fondo; en un repositorio privado, vigila el total.
• 2026-10-28: GitHub Agentic Workflows llegó a disponibilidad general: escribes una tarea en Markdown y se compila a YAML de Actions que puede usar Copilot u otro agente (changelog, página del proyecto). Los lockfiles de workflows también llegaron a disponibilidad general, para fijar acciones como actions/checkout a un commit exacto (changelog de lockfiles). Qué significa para ti: puedes fijar las acciones del workflow del reporte para que ninguna dependencia cambie sin aviso.
• 2026-10-27: GitHub Copilot admite autenticación de servidor a servidor para GitHub Apps instaladas en organizaciones, en vista previa pública (changelog). Qué significa para ti: un servicio interno podría pedirle a Copilot que lea los reportes semanales sin depender de la sesión de una persona, con cargo a la organización.
• 2026-10-22: la API de métricas de uso de Copilot ahora lista por nombre los servidores MCP, skills y agentes personalizados, hasta 25 de cada tipo (changelog). Qué significa para ti: un administrador puede ver si alguien usa de verdad el servidor MCP everyinfra.

Preguntas frecuentes

¿Dónde va la configuración de github copilot mcp y es lo mismo que mcp.json?

La pregunta viene de las sugerencias de búsqueda "github copilot mcp configuration" y "github copilot mcp.json". No es lo mismo. La configuración para el cloud agent y la revisión de código se pega en GitHub, en Settings, Copilot, MCP servers del repositorio, como un objeto mcpServers donde cada servidor necesita type y tools. VS Code usa .vscode/mcp.json en el repositorio o tu configuración de usuario. Para pasar una configuración de VS Code a GitHub hay que hacer algunos cambios, por ejemplo agregar tools y reemplazar inputs por env (documentación de configuración MCP del repositorio, documentación MCP de VS Code).

¿Un copilot coding agent mcp server puede ser un servidor HTTP remoto?

La pregunta viene de las sugerencias "copilot coding agent mcp server" y "github copilot coding agent mcp configuration". Sí. type puede ser local, stdio, http o sse, y un servidor remoto usa url y headers. El límite es OAuth: para servidores remotos en la configuración del repositorio, el cloud agent y la revisión de código todavía no lo admiten. Una llave en un encabezado sí funciona, y EveryInfra usa una llave Bearer (documentación de configuración MCP del repositorio).

¿Dónde pongo el token de un servidor MCP en el coding agent?

La pregunta viene de un hilo de Reddit sobre un servidor MCP de Atlassian en el coding agent (hilo en r/GithubCopilot). Va en los secretos de Agents del repositorio o de la organización, con un nombre que empiece con COPILOT_MCP_, y en la configuración lo mencionas como $COPILOT_MCP_NOMBRE. Solo los servidores MCP reciben ese tipo de secreto (secretos y variables para el cloud agent).

El registro dice que MCP conectó pero "retrieved 0 tools". ¿Qué hago?

La pregunta viene de un hilo de Reddit con ese mismo error (hilo en r/GithubCopilot). Primero revisa que cada nombre de tu lista tools coincida exactamente con uno de tools/list. Luego revisa si el servidor solo ofrece recursos o prompts, porque el cloud agent solo usa herramientas. En el caso de EveryInfra, un POST de tools/list sin llave muestra los 12 nombres, como en nuestra prueba de las 00:16, hora de Singapur (documentación de configuración MCP del repositorio).

¿La lista permitida de github copilot mcp puede bloquear un servidor que agrego?

La pregunta viene de las sugerencias "github copilot mcp allowlist" y "github copilot mcp registry". Puede. La documentación de conectores lista políticas que afectan a MCP: si la organización o la empresa apaga "MCP servers in Copilot", ningún servidor MCP funciona; si "Restrict MCP access to registry servers" permite solo servidores del registro, los clientes que aplican esa política bloquean conectores; y si la empresa define una lista allowedMcpServers, la dirección del servidor debe estar en ella. Pregunta primero a tu administrador cómo están esas opciones (documentación de Copilot connectors).

¿Sale más barata una automatización semanal de Copilot que un script en Actions?

La pregunta viene de nuestra propia prueba y de la sugerencia "copilot coding agent mcp". Si solo miras el dinero, el script en Actions consume cero créditos de IA por semana y el cargo de API para tres marcas es USD 0.011961 por semana. Una automatización consume créditos en cada ejecución; el tope mínimo por ejecución es de 30 créditos, es decir USD 0.30, y solo funciona en repositorios privados o internos. La automatización es más cómoda cuando necesitas un análisis semanal y el script es más barato cuando solo necesitas números (documentación de automations, documentación para crear automations).

Para empezar

1. Crea dos llaves en la consola de EveryInfra, llamadas "copilot-mcp" y "weekly-actions"; los pasos están en el inicio rápido.
2. En el repositorio, agrega COPILOT_MCP_EVERYINFRA_API_KEY en los secretos de Agents y EVERYINFRA_API_KEY en los de Actions.
3. Pega el JSON de este artículo en Settings, Copilot, MCP servers, con tres herramientas; para otros clientes MCP, revisa la página del servidor MCP de EveryInfra.
4. Abre el issue con la plantilla de este artículo y asígnalo a Copilot; antes del merge, corre el workflow una vez con workflow_dispatch.

Referencias

1. Connect your tools to Copilot without all the setup, GitHub Changelog, 2026-10-28.
2. Copilot connectors, GitHub Docs, consultado el 2026-11-06.
3. Configure MCP servers for your repository, GitHub Docs, consultado el 2026-11-06.
4. Configure secrets and variables for Copilot cloud agent, GitHub Docs, consultado el 2026-11-06.
5. Copilot automations, GitHub Docs, consultado el 2026-11-06.
6. Creating automations with Copilot cloud agent, GitHub Docs, consultado el 2026-11-06.
7. About Copilot cloud agent, GitHub Docs, consultado el 2026-11-06.
8. Risks and mitigations for GitHub Copilot cloud agent, GitHub Docs, consultado el 2026-11-06.
9. Customizing or disabling the firewall for GitHub Copilot, GitHub Docs, consultado el 2026-11-06.
10. Best practices for using GitHub Copilot to work on tasks, GitHub Docs, consultado el 2026-11-06.
11. Plans for GitHub Copilot, GitHub Docs, consultado el 2026-11-06.
12. Usage-based billing for individuals, GitHub Docs, consultado el 2026-11-06.
13. Events that trigger workflows, GitHub Docs, consultado el 2026-11-06.
14. GitHub Actions billing, GitHub Docs, consultado el 2026-11-06.
15. Using secrets in GitHub Actions, GitHub Docs, consultado el 2026-11-06.
16. New tools, triggers, and cost controls for Copilot Automations, GitHub Changelog, 2026-10-28.
17. Build shared workflows for your team with Copilot Automations, GitHub Changelog, 2026-10-28.
18. Create and manage Copilot Automations in Visual Studio Code, GitHub Changelog, 2026-10-28.
19. Work from anywhere with a new, connected Copilot cloud experience, GitHub Changelog, 2026-10-28.
20. GitHub Agentic Workflows generally available, GitHub Changelog, 2026-10-28.
21. GitHub Actions workflow lockfiles are generally available, GitHub Changelog, 2026-10-28.
22. Push protection beyond predefined secret patterns, GitHub Changelog, 2026-10-28.
23. GitHub Copilot supports server-to-server authentication, GitHub Changelog, 2026-10-27.
24. Custom skills, agents, and MCP servers in usage metrics API, GitHub Changelog, 2026-10-22.
25. Secret scanning blocks Anthropic keys by default, adds Salesforce, GitHub Changelog, 2026-10-13.
26. Discusión 211002 sobre el lanzamiento de conectores, GitHub Community, 2026-10-28.
27. GitHub Agentic Workflows, GitHub Next, consultado el 2026-11-06.
28. Tools, especificación Model Context Protocol 2025-11-25, consultado el 2026-11-06.
29. Transports, especificación Model Context Protocol 2025-11-25, consultado el 2026-11-06.
30. crontab, The Open Group Base Specifications Issue 7, 2018.
31. LLM01:2025 Prompt Injection, OWASP GenAI Security Project, consultado el 2026-11-06.
32. Quota Calculator, YouTube Data API, Google for Developers, consultado el 2026-11-06.
33. IG User Business Discovery, Meta for Developers, consultado el 2026-11-06.
34. TikTok Research Tools: Access and Eligibility, TikTok for Developers, consultado el 2026-11-06.
35. Community Management Overview, LinkedIn en Microsoft Learn, consultado el 2026-11-06.
36. Add and manage MCP servers in VS Code, documentación de Visual Studio Code, consultado el 2026-11-06.
37. GitHub Copilot Code Agent: Retrieved 0 tools from MCP server, Reddit r/GithubCopilot, consultado el 2026-11-06.
38. How to use MCP atlassian on Github coding agent, Reddit r/GithubCopilot, consultado el 2026-11-06.
39. Catálogo de capacidades de datos de EveryInfra, EveryInfra, consultado el 2026-11-06 a las 00:16, hora de Singapur.
40. Configure the development environment for agents on GitHub Actions, GitHub Docs, consultado el 2026-11-06.
41. Copilot allowlist reference, GitHub Docs, consultado el 2026-11-06.
42. github/github-mcp-server, GitHub, consultado el 2026-11-06.