GitHub Copilot MCP: пример конфигурации и 26 реальных вызовов API для еженедельного отчёта о соцсетях конкурентов

Продакт-маркетолог в B2B SaaS-компании часто получает по понедельникам один и тот же запрос. Запрос простой: что три главных конкурента опубликовали на прошлой неделе? Мы собрали данные для такого отчёта 6 ноября 2026 года с 00:17 до 00:38 по сингапурскому времени (SGT). Мы сделали 26 реальных вызовов API EveryInfra для Notion, ClickUp и Asana.

Сразу оговорим одно ограничение: на нашей тестовой машине нет подписки на Copilot. Настройка Copilot, issue и workflow в этой статье — примеры конфигурации из документации GitHub. Мы не запускали их в Copilot. Все измеренные значения получены из реальных ответов API EveryInfra.

За неделю с 30 октября по 5 ноября ClickUp опубликовал 14 записей на YouTube, в TikTok и Instagram. Asana опубликовала 3, Notion опубликовал 2.

В схеме из этой статьи агент GitHub Copilot для написания кода запускается один раз. Агент читает несколько реальных ответов через MCP, а затем пишет обычный скрипт на Python и workflow по расписанию. После слияния pull request GitHub Actions запускает скрипт каждую неделю, и модель больше не запускается. По ценам каталога четыре платформы для трёх брендов стоят $0.011961 в неделю, то есть около $0.0518 в месяц.

В этой статье мы рассматриваем узкую задачу. Вам нужен отчёт в формате Markdown, который будет появляться в репозитории каждое утро понедельника. В отчёте указано, что каждый конкурент опубликовал на четырёх платформах, какая публикация показала лучший результат и как изменилась частота публикаций. Код для отчёта вы хотите поручить GitHub Copilot. При этом вы не хотите, чтобы модель ИИ каждую неделю заново искала данные.

Все факты о GitHub в этой статье взяты из GitHub Changelog или с docs.github.com (дата обращения: 6 ноября 2026 г.). Все цифры EveryInfra взяты из реальных ответов API, которые мы сохранили.

Короткий ответ: разделите задачу GitHub Copilot MCP на две части

При подготовке такого отчёта чаще всего ошибочно смешивают две задачи. Одна — написать код, другая — каждую неделю собирать данные. 28 октября 2026 года GitHub выпустил две функции, соответствующие этим задачам.

Первая функция — коннекторы и конфигурация MCP на уровне репозитория: с ними Copilot может вызывать внешние инструменты во время работы. Вторая функция добавляет в Copilot Automations новые инструменты, триггеры и средства контроля расходов (запись в истории изменений об инструментах, триггерах и средствах контроля расходов для автоматизаций). Automations позволяют запускать Copilot по расписанию.

Если Copilot каждую неделю собирает данные и пишет отчёт, каждый запуск открывает сессию облачного агента. В документации по автоматизациям сказано, что каждый запуск расходует AI-кредиты и минуты Actions (документация по Copilot automations, раздел о биллинге). Фиксированному еженедельному отчёту не нужна модель, которая принимает решения. Поэтому мы предлагаем задействовать модель только один раз, когда она пишет код.

Схема простая. Вы создаёте issue, в котором указываете правила, хендлы и тестовый пример. Затем назначаете Copilot исполнителем issue. Прежде чем писать код, агент с помощью MCP-инструментов EveryInfra читает каталог и делает три-четыре тестовых вызова.

Агент видит реальные названия полей и реальные форматы дат. Затем он пишет weekly_report.py и .github/workflows/weekly-report.yml и открывает pull request вам на ревью. После слияния задание Actions по расписанию отправляет POST /api/v1/social, собирает Markdown-файл и делает коммит.

В таблице ниже сравниваются два способа запускать отчёт. Факты взяты из документации GitHub. Левый столбец соответствует нашему варианту.

Значение 30 кредитов — это минимальный лимит на запуск, который можно задать при создании автоматизации (документация по созданию автоматизаций). Один AI-кредит равен $0.01 (тарификация по использованию для индивидуальных пользователей). В документации не сказано, сколько кредитов расходует типичный запуск, поэтому мы не берёмся гадать. Достоверно можно сказать одно: вариант со скриптом Actions расходует ноль AI-кредитов в неделю. Оба варианта можно и совмещать. Скрипт каждую неделю выдаёт цифры, а время от времени вы просите Copilot прочитать отчёты за четыре недели и написать краткий анализ.

Если вы всё же хотите запускать Copilot каждую неделю, используйте автоматизацию. Ей доступны инструменты из настроек MCP репозитория, поэтому JSON из этой статьи подойдёт и там. Правила триггеров и тарификации описаны в документации по Copilot automations. Перед включением автоматизации задайте лимит AI-кредитов на запуск и на неделю.

Что изменилось согласно записи в истории изменений от 28 октября

Многие начинают искать «github copilot mcp», прочитав запись в истории изменений от 28 октября 2026 года. Она называется «Connect your tools to Copilot without all the setup». В ней объявлено о проверенных GitHub MCP-серверах, которые также называют коннекторами; они доступны в режиме публичного предварительного доступа. Вы выбираете сервис, входите в аккаунт и подтверждаете доступ. После этого коннектор работает в приложении Copilot, Copilot CLI, VS Code, Copilot в облаке и GitHub Mobile (запись в истории изменений). На старте доступно 26 сервисов, среди них Slack, Figma, Notion, Sentry, Linear, Atlassian Rovo, Cloudflare, Vercel и Work IQ.

В записи также говорится о тарифах. Функция становится доступна на всех тарифах Copilot. В Copilot Business и Enterprise администратор должен включить политику «Editor preview features». Если в корпоративной учётной записи используется список разрешённых MCP-серверов, администратор также должен добавить в него эти сервисы. Вопросы пользователей о запуске собраны в обсуждении сообщества (GitHub Community discussion 211002).

Для нашего отчёта этот запуск важен по трём причинам. Во-первых, EveryInfra нет среди 26 коннекторов, и GitHub не проверял наш сервер. Чтобы использовать наши данные, добавьте сервер в конфигурацию MCP репозитория или в личную конфигурацию MCP. В обоих случаях нужен короткий блок JSON, который вы пишете сами.

Во-вторых, в документации по коннекторам сказано, что коннекторы работают в локальных сессиях и сессиях в облачной песочнице. Они пока не работают в сессиях, запускаемых в GitHub Actions (документация по Copilot connectors). Один из примеров такой сессии — сессия, которая запускается, когда вы назначаете Copilot исполнителем issue. Страница о конфигурации MCP для репозитория повторяет это примечание в самом начале (документация по конфигурации MCP для репозитория).

Третий момент касается названия продукта. Многие по-прежнему говорят «Copilot coding agent». На docs.github.com та же функция теперь называется «Copilot cloud agent» (об облачном агенте). Старая ссылка на MCP для coding agent ведёт на новую страницу. В этой статье оба названия обозначают одну и ту же функцию.

Настройка MCP для Copilot coding agent: JSON в настройках репозитория

MCP-конфигурацию репозитория добавляют на странице репозитория в разделе Settings, затем Copilot, затем MCP servers. Формат: один объект mcpServers. Каждый ключ в нём является именем сервера. У каждого сервера должны быть ключи type и tools. Удалённому серверу нужен ещё url, а сервер, которому требуется аутентификация, использует headers. Значение заголовка может ссылаться на секрет, имя которого начинается с COPILOT_MCP_, в виде $COPILOT_MCP_API_KEY или ${COPILOT_MCP_API_KEY} (документация по MCP-конфигурации репозитория).

Документация настоятельно рекомендует указывать в tools только конкретные инструменты для чтения. Причина понятна: агент вызывает инструменты сам и не спрашивает вас заранее. Удалённый MCP-эндпоинт EveryInfra — https://api.everyinfra.com/mcp. Для него используется API-ключ по схеме Bearer, а не OAuth, поэтому такая конфигурация поддерживается согласно документации. Вот наш пример конфигурации:

{
  "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"
      ]
    }
  }
}

Почему только три инструмента? В 00:16 SGT мы отправили tools/list без ключа. В 00:26 SGT мы отправили его снова, уже с ключом. Оба ответа содержали 12 инструментов в 16 247 байтах.

Отчёту нужны три из них: один читает каталог, второй выполняет вызов, третий читает результат асинхронной задачи. Остальные девять инструментов показывают баланс, создают ссылку на пополнение баланса, открывают тикет в поддержку или решают капчу. Для отчёта они бесполезны. В списке разрешённых инструментов они лишь дают агенту больше способов ошибиться.

У каждого из 12 инструментов есть MCP annotations. Реальный ответ показывает деталь, которой не видно в документации. У everyinfra_call_api стоят readOnlyHint: false и destructiveHint: true, потому что он может списывать деньги. В документации GitHub сказано, что ревью кода Copilot использует только инструменты, у которых в tools/list значение annotations.readOnlyHint равно true. Инструменты без этой аннотации и со значением false ревью кода пропускает. Поэтому при одной и той же конфигурации репозитория облачный агент может вызывать наш инструмент данных, а ревью кода Copilot не может.

Для этого отчёта такой результат хорош, потому что ревью кода не должно тратить деньги на данные. Если нужно, чтобы ревью кода пропускало все MCP-инструменты, в документации есть настройка и для этого. Поля аннотаций описаны в разделе спецификации MCP об инструментах (спецификация MCP, инструменты).

На настройку влияют ещё два ограничения. Облачный агент и ревью кода поддерживают только MCP-инструменты. Ресурсы и промпты сервера они не поддерживают. Наш отчёт использует только инструменты, так что здесь это ограничение не мешает.

Второе ограничение касается проверки настройки. Назначьте Copilot исполнителем задачи, откройте журнал сеанса и найдите шаг «Start MCP Servers». В конце этого шага перечислены запущенные инструменты.

Пользователь Reddit настроил MCP-сервер Atlassian для агента по написанию кода и увидел, что подключение прошло успешно, но появилось сообщение «retrieved 0 tools» (обсуждение в r/GithubCopilot). Если вы столкнулись с этим, сначала сверьте каждое имя в tools с именами из tools/list. Имена должны совпадать в точности.

Где хранить секреты: два ключа, два ящика

Именно на этом шаге ошибаются чаще всего. Теперь у GitHub есть отдельный тип секретов для облачного агента под названием Agents secrets. Он находится рядом с секретами Actions, Codespaces и Dependabot. В документации сказано, что облачный агент не может читать секреты и переменные Actions, Codespaces или Dependabot. Ему доступны только секреты типа Agents.

Секрет Agents, имя которого начинается с COPILOT_MCP_, передаётся только MCP-серверам. Для команд, которые запускает агент, он не становится переменной окружения (секреты и переменные для облачного агента). Рабочий процесс, запускаемый по расписанию, использует секреты Actions и не может читать секреты Agents. Поэтому для отчёта требуются два ключа.

В той же документации есть ещё три правила. Имя секрета не может начинаться с GITHUB_. В типе Agents есть секреты и переменные, но в облачной песочнице агент получает только секреты, без переменных. Секрет Agents без префикса COPILOT_MCP_ становится переменной окружения для команд и инструментов, которые запускает агент.

Поэтому не добавляйте ключ EveryInfra без префикса, если не хотите, чтобы агент запускал скрипт с доступом к сети. Один секрет Agents на уровне организации может обслуживать много репозиториев. Этот вариант удобен команде, которая отслеживает конкурентов в нескольких репозиториях.

Почему бы не использовать один ключ под одним именем для обеих задач? Причин три. Во-первых, GitHub держит эти два ящика раздельно, так что одно имя не поможет. Во-вторых, журнал запросов проще читать, если у двух ключей EveryInfra понятные имена. Если один ключ утечёт или расходы по нему окажутся слишком высокими, вы увидите, какой именно.

В-третьих, по умолчанию защита GitHub от отправки секретов (push protection) блокирует только известные ей форматы ключей. Ключ EveryInfra к ним не относится (история изменений push protection). Если агент запишет ключ в тестовый файл, отправка изменений может не быть заблокирована. Поэтому укажите в задаче, что ключ должен передаваться только через переменную окружения.

Файрвол добавляет ещё одну ловушку. По умолчанию файрвол ограничивает сетевой доступ облачного агента. В документации сказано, что файрвол действует на процессы, которые агент запускает своим инструментом Bash. На процессы MCP-серверов он не действует (документация по файрволу, ограничения).

Поэтому MCP-вызовы к EveryInfra работают. Но агент может попробовать запустить новый weekly_report.py в сеансе. Тогда файрвол заблокирует запрос к api.everyinfra.com, а в описании пул-реквеста появится предупреждение.

Есть два варианта. Можно добавить api.everyinfra.com в пользовательский список разрешённых адресов в разделе Internet access и завести третий ключ без префикса COPILOT_MCP_ для команд агента. Или можно попросить агента сохранить один реальный ответ MCP как фикстуру. Тогда тесты читают фикстуру и не обращаются к сети.

Мы советуем второй вариант. Первый помещает ключ в окружение команд агента. В документации сказано, что в логах значения секретов маскируются, но открывать эту дверь незачем.

Как составить задачу для агента

На странице рекомендаций GitHub сказано, что задача для Copilot должна описывать проблему, критерии приёмки и файлы, которые нужно изменить. Лучше всего работают небольшие и понятные задачи (рекомендации по задачам для Copilot). В задаче для этого отчёта важнее всего список имён аккаунтов и тестовый пример. Не позволяйте агенту угадывать имена аккаунтов.

Для трёх имён аккаунтов, которые мы попытались угадать, пришли пустые списки. Ошибки и списания не было, а из отчёта незаметно пропала запись. Вот пример задачи:

## Task
Write weekly_report.py and .github/workflows/weekly-report.yml.
Every Monday at 09:00 Asia/Singapore, 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 make 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 are 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

## 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 of the report for a manual check.
5. Read the key only from the EVERYINFRA_API_KEY environment variable. Never write it to a file.
6. Tests read JSON fixtures in tests/fixtures/ (real MCP responses). Tests use no network.

## Test example
With the fixtures, ClickUp TikTok this week = 4 posts (not 0, not 7), total views = 60463.

Последняя строка в задаче — самая важная. Ожидаемые значения в ней взяты из реального ответа tiktok/user_videos, полученного для ClickUp в 00:19 SGT. Из 10 записей первые 3 были закреплёнными видео 2024 года с 20,1 млн, 7,5 млн и 3,2 млн просмотров. Список отсортирован от новых к старым, но закреплённые видео всегда идут первыми.

Из-за такого порядка возможны три неверных ответа. Скрипт, который считает первую запись последней публикацией, сообщит, что ClickUp в последний раз публиковался в TikTok в 2024 году. Скрипт, который читает записи от новых к старым и останавливается на первой записи, опубликованной до начала периода, насчитает 0 публикаций. Скрипт, который отбрасывает закреплённые записи, но не фильтрует по дате, насчитает 7.

Правильный ответ: 4. Если это число указано в задаче, один прогон теста покажет, верен ли код. Читать каждую строку кода не нужно.

Один реальный цикл запроса и ответа: что отправляет Copilot и что приходит обратно

Мы не запускали Copilot. Но MCP является открытым протоколом. Когда агент вызывает инструмент, он отправляет один стандартный JSON-RPC-запрос tools/call через транспорт Streamable HTTP. Каждое сообщение передаётся отдельным HTTP-запросом POST.

Клиент должен принимать и application/json, и text/event-stream (спецификация MCP, транспорты). Поэтому curl может отправить тот же запрос, что и агент, и мы увидим, что возвращает наш сервер. Мы отправили этот запрос 6 ноября 2026 года в 00:26:28 SGT:

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}}}}'

Сервер вернул HTTP 200 через 31,1 секунды. Поле result.content[0].text содержало JSON-строку длиной 13 272 символа. В ней было 5 видео Notion из TikTok, у каждого posted_at, view_count, like_count, is_pinned и другие поля. Самое новое видео вышло 26 мая 2026 года и набрало 22 800 просмотров.

В конце billing показал charged: true и charged_usd: 0.000556. Агент видит те же данные до того, как пишет код. Он узнаёт имена полей и формат дат ISO. А ещё он узнаёт, что этот аккаунт ничего не публиковал в TikTok больше пяти месяцев.

Сначала мы сформировали отчёт, выполнив 26 реальных вызовов API

Прежде чем просить агента написать скрипт, нужно знать правильный ответ. Поэтому сначала мы сами составили отчёт 6 ноября 2026 года, с 00:17 до 00:38 SGT. Отчётный период охватывает семь календарных дней по UTC, с 30 октября по 5 ноября. Каждая возможность и её параметры взяты из бесплатного каталога GET /api/v1/social/catalog. Мы использовали четыре возможности: youtube/user_posts (обязательный url, необязательные since и sort), tiktok/user_videos (обязательный username), instagram/user_posts (обязательный username, в каталоге отмечена как асинхронная) и linkedin/company_posts (обязательный company). Страницы возможностей: Публикации пользователя на YouTube, Видео пользователя в TikTok, Публикации пользователя в Instagram и Публикации компании в LinkedIn.

Эта таблица лежит в основе еженедельного отчёта и позволяет сделать три вывода. Во-первых, три бренда публикуются с очень разной частотой. ClickUp за неделю выпустил 14 публикаций на трёх платформах. В Instagram 7 из 10 его последних публикаций сделаны на этой неделе. В TikTok он опубликовал 4 видео, а на YouTube — 3.

Во-вторых, Notion и Asana почти перестали публиковаться в TikTok. Их последние видео в TikTok вышли 26 мая 2026 года и 4 июня 2026 года. У Asana 7 из 10 последних видео опубликованы в тот самый день в июне, а остальные 3 относятся к 2025 и 2023 годам. Строка «0 за неделю» даёт полезный сигнал. Но польза от него есть, только если вы уверены в правильности имени аккаунта, потому что неверное имя аккаунта тоже даёт 0.

В-третьих, Instagram оказался единственной платформой, где на этой неделе публиковались все три бренда. Если вы можете отслеживать только одну платформу, по этой таблице стоит выбрать Instagram.

У этих результатов есть ограничения. Окно составляет одну неделю, а выборка включает три бренда. Для TikTok и Instagram мы запрашивали по 10 записей. Для ClickUp в Instagram 10 записей охватили 9 дней.

Для SaaS-команды этого обычно достаточно. С потребительским брендом всё иначе. Лимит должен соответствовать тому, как часто публикуется каждый аккаунт, а его увеличение не повышает стоимость, потому что у этих возможностей оплата за каждый вызов, а не за каждую запись.

Пример отчёта по данным этой недели

Одного количества публикаций мало. Маркетинговой команде также нужно знать, какая публикация сработала лучше всего и о чём она была. Ниже приведён пример отчёта, который мы вручную собрали из реальных ответов. Его можно вставить в задачу как образец формата, который должен сформировать агент.

В нём показана лучшая публикация для каждого бренда и платформы. В строки TikTok не попадают закреплённые видео. Строки Instagram отсортированы по лайкам, строки YouTube — по просмотрам. Даты YouTube вида «1d ago» и «5d ago» мы пересчитали от момента получения данных, поэтому они точны только до дня.

Этот пример показывает две вещи, которых не видно при простом подсчёте. Во-первых, ClickUp использует офисный юмор в TikTok. За эту неделю у компании вышло 4 публикации: 2026-11-05, 2026-11-04, 2026-11-02 и 2026-10-30. В сумме они набрали 60 463 просмотра и 3 392 лайка. Самая популярная публикация набрала 27 400 просмотров.

За день до начала окна, 29 октября, одна публикация набрала 145 200 просмотров. Похоже, примерно раз в неделю у этого аккаунта появляется публикация с очень большим числом просмотров. Если в отчёте используется скользящее окно «последние 7 дней на момент запуска», такая публикация может то попадать в отчёт, то выпадать из него.

Во-вторых, все три бренда сейчас говорят об ИИ. Единственное видео Notion на YouTube за эту неделю показывает, как подключить ChatGPT или Claude к Notion. Все три видео ClickUp на YouTube посвящены ИИ. 30 октября в еженедельном обзоре ClickUp в Instagram упоминался новый MCP-сервер ClickUp для Salesforce. За два дня до начала окна, 28 октября, Asana продвигала в Instagram своего ИИ-ассистента Dash. Если вы тоже продаёте ПО для совместной работы, столбец «о чём говорили» может оказаться полезнее количества публикаций.

Чтобы сравнивать лайки, нужно учитывать и количество публикаций. У ClickUp в Instagram 7 публикаций и 273 лайка в сумме, от 1 до 73 на публикацию. У Asana 3 публикации и 82 лайка. У Notion 1 публикация со 143 лайками. Это больше, чем у любой отдельной публикации ClickUp.

Судя по количеству публикаций, в Instagram лидирует ClickUp, а судя по лайкам на публикацию, лидирует Notion. Поэтому мы предлагаем три столбца в отчёте: количество публикаций, суммарная вовлечённость и медианная вовлечённость на публикацию. Добавьте четвёртый столбец с лучшей публикацией. Скрипт может посчитать все четыре показателя по полям, которые уже есть в ответе, без дополнительных вызовов и дополнительных затрат.

Шесть ловушек, выявленных при реальных вызовах, и способы их обработки в скрипте

Половина из 26 реальных вызовов прошла без списания. Мы разбили вызовы на группы. За 13 вызовов средства были списаны. 5 вызовов вернули пустой результат, и за них был оформлен возврат средств. В 4 случаях мы ошиблись с именем аккаунта. В пятом использовался правильный канал Asana, на котором за ту неделю не вышло новых видео.

7 вызовов вернули код 503: 6 вызовов для получения публикаций компаний из LinkedIn и 1 синхронный вызов YouTube, завершившийся по тайм-ауту. Ещё 1 вызов был запланированным тестом с неверным параметром, который возвращает код 422. Ни за один неудачный вызов средства не списывались. Общая сумма списания составила $0,007228, то есть ровно 13 × $0,000556.

Каждой группе сбоев соответствует своя часть скрипта. Список «Обязательно обработать» в задаче составлен по этой таблице:

Вторая ловушка требует подробного разбора. Мы измерили время до первого ответа для 8 синхронных вызовов, которые вернули данные или завершились по тайм-ауту. Ответы на 6 вызовов LinkedIn с кодом 503 пришли за 2,2–2,4 секунды, а ответ на вызов с кодом 422 — за 0,2 секунды, поэтому на графике их нет. Три вызова TikTok заняли 22,2, 68,9 и 21,6 секунды, а вызов через MCP — 31,1 секунды. Вызов YouTube с правильным именем аккаунта занял 11,5 секунды.

Вызов YouTube с неверным именем аккаунта вернул пустой список через 40,3 секунды, а другой вызов вернул код 503 через 89,8 секунды. В сообщении об ошибке сказано, что синхронный вызов ждёт до 85 секунд. Вызов TikTok для ClickUp занял 68,9 секунды, всего на 16 секунд меньше этого лимита.

В GitHub Actions дополнительное ожидание не создаёт проблем. Тайм-аут означает, что вызов придётся отправить заново. Поэтому используйте асинхронный режим, если каталог это допускает. Вызов отправки сразу возвращает job_id. Затем скрипт каждые несколько секунд отправляет GET /api/v1/jobs/{job_id}, а запрос статуса задачи ничего не стоит.

Пятая ловушка связана с LinkedIn. С 00:18 до 00:38 SGT linkedin/company_posts шесть раз вернул 503 для Notion, ClickUp, Asana и google, компании из примера в сообщении об ошибке. Код ошибки был unavailable, и значение billing.charged_usd в каждом ответе было равно 0. После третьего сбоя next_steps сообщил, что за десять минут три вызова завершились ошибкой без списания. Он предложил сделать один вызов с примером запроса. Если и пример не сработает, значит, проблема на нашей стороне, и тогда, согласно сообщению, нужно спросить пользователя, прежде чем открывать тикет.

При этом linkedin/company_profile работал. В 00:34 SGT он получил страницу компании Notion за 6,2 секунды и списал $0,000556. В ответе было 1 137 647 подписчиков и 7 211 сотрудников. Даже в неделю, когда посты не загружаются, столбец LinkedIn по-прежнему может показывать изменение числа подписчиков.

В ту ночь каталог по-прежнему отмечал публикации компаний как доступные. Поэтому скрипт не может полагаться только на каталог и должен обрабатывать 503. Лучше явно написать в отчёте «Данные LinkedIn на этой неделе не собраны», чем молча убрать из него столбец. О том, как возвращаются средства за неудачные вызовы и как это проверить, читайте в нашем руководстве по сверке возвратов за сбои.

Как выглядит скрипт: рабочий процесс, который должен подготовить агент

Pull request от агента должен содержать как минимум два файла. Ниже приведён пример конфигурации workflow. Основные правила взяты из документации GitHub Actions. schedule по умолчанию использует UTC, а теперь также принимает timezone с именем часового пояса IANA. Минимальный интервал составляет 5 минут. В начале каждого часа запуски по расписанию могут задерживаться.

При высокой нагрузке часть запусков в очереди может быть отброшена. Поэтому документация советует выбирать время не ровно в начале часа. Запуски по расписанию используют только ветку по умолчанию. В публичном репозитории workflow по расписанию отключаются после 60 дней без активности (events that trigger workflows, schedule). Пять полей cron соответствуют спецификации POSIX crontab.

name: weekly-competitor-social-report
on:
  schedule:
    - cron: "17 9 * * 1"          # Monday 09:17, not on the hour
      timezone: "Asia/Singapore"
  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

Скрипту нужна одна основная функция. Она отправляет запрос. Если статус running, она опрашивает задачу по job_id. Если приходит 503, она ждёт retry_after и пробует ещё раз.

Затем она возвращает записи или маркер «не собрано». Вот каркас, составленный по результатам наших тестов. Имена полей совпадают с response_fields в каталоге, поэтому его можно вставить в задачу как образец:

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

API = "https://api.everyinfra.com"
KEY = os.environ["EVERYINFRA_API_KEY"]          # read 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":   # job failed: mark it, never report it as 0 rows
            return {"unavailable": True, "status": data.get("status"), "reason": data.get("error")}
        if "results" not in data:                              # success without results: raise
            raise RuntimeError(f"no results field: {platform}/{action}")
        return {"rows": data["results"], "count": len(data["results"])}

Обратите внимание на заголовок User-Agent. Некоторые правила защиты сайтов блокируют стандартный User-Agent Python. Информативный User-Agent может уберечь вас от неожиданной ошибки 403 в журнале Actions. Значение timeout=100 немного превышает серверный лимит в 85 секунд. Поэтому при тайм-ауте вы получите от сервера ответ 503 с retry_after, а не разрыв соединения на стороне клиента.

Важнее всего две последние проверки. Если асинхронная задача завершается с любым status, кроме succeeded, функция возвращает маркер unavailable, и в отчёте пишется «не собрано на этой неделе». Если задача успешна, но в ней нет поля results, функция выбрасывает ошибку, и шаг Actions становится красным. Отчёт пишет «0 постов на этой неделе» только тогда, когда вызов действительно успешно вернул пустой список. Без этих двух проверок сбой сервиса превращается в «конкурент перестал публиковать посты», а это худшая ошибка, которую может допустить еженедельный отчёт.

Проверьте пять вещей в pull request

Когда агент вернёт pull request, не нужно читать каждую строку на Python. Проверьте пять вещей. Каждая проверка занимает несколько минут. Во-первых, secrets.EVERYINFRA_API_KEY встречается только в env шага сбора данных. Он не выводится через echo и не записывается в файл. GitHub маскирует значения секретов в логах, но не маскирует значение, закоммиченное в файл (using secrets in GitHub Actions).

Во-вторых, откройте примеры JSON-файлов в tests/fixtures/. Это должны быть реальные ответы, которые агент сохранил из вызовов MCP, а имена полей в них должны совпадать с таблицей полей в этой статье. Если агент написал примеры сам, тесты лишь повторяют его же код. В-третьих, проверьте, что тестовый пример настоящий: у ClickUp в TikTok за эту неделю 4 поста и 60463 просмотра. Эти числа взяты из реального ответа, и агент не может их изменить. Код должен им соответствовать.

В-четвёртых, проверьте пути обработки сбоев. При 503 скрипт один раз ждёт и повторяет попытку. При status: failed записывается «не собрано». При нуле записей имя аккаунта добавляется в список «проверить имя аккаунта». При 422 повторной попытки нет.

Если какого-то пути нет, верните pull request на доработку. В-пятых, workflow в pull request от агента запускается только после того, как человек с правами на запись нажмёт «Approve and run workflows». Запустите его один раз через workflow_dispatch, посмотрите в журнале Actions время и списание по каждому вызову, а затем объедините изменения. Также можно сверить каждое списание с журналом запросов в консоли EveryInfra, где у неудачных вызовов списаний нет.

Недельная и месячная стоимость API по ценам каталога

Стоимость складывается из двух частей: платы за API EveryInfra и расходов на стороне GitHub. Наша плата определяется значением price_usd для каждой возможности в каталоге. Каждый вызов этих возможностей оплачивается отдельно. Вызов, который вернул 1 запись, стоит столько же, сколько вызов с 30 записями. За неудачные вызовы и пустые результаты деньги не списываются. Цены также можно посмотреть на странице тарифов EveryInfra.

Три бренда стоят $0,011961 в неделю. Если умножить на 52 недели и разделить на 12 месяцев, получается около $0,0518 в месяц. Более длинный список тоже обходится дёшево. Десять брендов стоят около $0,1728 в месяц, 30 брендов — около $0,5183, а 100 брендов — около $1,7277. Реальный запуск на этой неделе обошёлся ещё дешевле.

Средства за вызовы YouTube списались дважды, поскольку вызов для Asana вернул пустой результат и за него был оформлен возврат средств. За вызовы TikTok и Instagram средства списались по три раза. Три вызова LinkedIn завершились ошибкой без списания. Итого оплачено 8 вызовов на сумму $0,004448.

У GitHub три статьи расходов. Две из них понятны, а для третьей мы можем дать только диапазон. Первая статья расходов — минуты Actions. Стандартные раннеры на хостинге GitHub бесплатны в публичных репозиториях. Приватные репозитории расходуют вычислительные ресурсы, которые ваш план включает каждый месяц: $12 для GitHub Free и $18 для GitHub Pro и Team. Стандартный Linux-раннер стоит $0,006 в минуту (GitHub Actions billing).

По нашим замерам 12 последовательных вызовов занимают около 5 минут, что в приватном репозитории обходится примерно в $0,03 в неделю. Если скрипт сначала отправит все асинхронные задачи, а затем будет опрашивать их вместе, запуск может занять одну-две минуты. Вторая статья расходов — тариф Copilot. Например, Copilot Pro стоит $10 в месяц и включает 1 500 ИИ-кредитов, а Pro+ стоит $39 в месяц и включает 7 000 (Copilot plans).

Третья статья расходов — ИИ-кредиты за единственную сессию, в которой создаётся скрипт. Их количество зависит от модели и продолжительности сессии. В документации нет типичного значения, а мы не запускали Copilot, поэтому число не приводим. Реальное значение показано на странице использования Copilot.

Поля: каждая платформа возвращает разные данные

Отчёт сравнивает четыре платформы, и самое сложное в том, что поля не совпадают. Каталог перечисляет response_fields для каждой возможности. Мы сверили с ним каждый реальный ответ и нашли три расхождения, которые меняют столбцы отчёта. Во-первых, в Instagram user_posts в ту ночь не было view_count ни в одной из 50 записей по 5 аккаунтам. В field_note каталога также сказано, что некоторые запросы к Instagram не возвращают view_count, is_comments_disabled, author_follower_count и top_comments. Такие запросы возвращают до 48 постов. Поэтому в столбце Instagram можно сравнивать лайки и комментарии, но не просмотры.

Во-вторых, для YouTube user_posts в каталоге указано 25 полей. В нашем тесте ответ со списком видео канала содержал только 14 полей. В нём были view_count, title и duration. Полей like_count, comment_count и is_paid_partnership не было, а posted_at содержало относительное обозначение времени. В-третьих, ответ TikTok user_videos содержал 35 полей. В нём больше всего информации, и он же занимает больше всего места.

Эту таблицу тоже нужно добавить в задачу. Не позволяйте агенту гадать, на какой платформе доступны просмотры. Укажите, что в столбцах «Просмотры» для Instagram и LinkedIn стоит «н/д», а вовлечённость в отчёте рассчитывается как сумма лайков и комментариев. Большинство различий агент обнаруживает, когда читает реальные ответы. Если таблица включена в задачу, агенту вообще не нужно гадать.

Чем эта статья отличается от статей про Claude Code и ChatGPT

В нашем блоге есть четыре близкие по теме статьи: субагенты Claude Code для брендовых аккаунтов TikTok, запланированные задачи ChatGPT как еженедельный радар спроса, еженедельный отчёт по отзывам о приложениях в Codex Cloud и трекер соцсетей конкурентов в ChatGPT Spaces. Если вы хотите, чтобы ChatGPT сам формировал отчёт каждую неделю, прочитайте статью о запланированных задачах.

Главное отличие этой статьи в следующем: ИИ работает только один раз, когда пишет код, а затем каждую неделю запускается обычный скрипт. Преимущества — стабильный формат, отсутствие еженедельных расходов на модель и понятные логи Actions при сбоях. За это приходится один раз проверить пул-реквест и менять конфигурацию при добавлении бренда или платформы. Если отчёту нужна еженедельная интерпретация, например объяснение того, почему видео показало хорошие результаты, лучше подойдёт подход с ChatGPT. Можно также поручить скрипту рассчитывать показатели, а затем попросить Copilot прочитать отчёты за месяц и подготовить анализ.

Почему бы не использовать собственный API каждой платформы

Резонный вопрос: зачем нужен EveryInfra, если у каждой платформы есть API для разработчиков? Дело в том, что через API большинства платформ непросто читать публичный контент чужих компаний. Каждая строка таблицы ниже взята из документации для разработчиков самой платформы.

YouTube Data API хорошо подходит для части этого отчёта. Если вы отслеживаете только YouTube, используйте его напрямую. При работе с четырьмя платформами вам придётся поддерживать четыре типа аутентификации, учитывать четыре квоты и обрабатывать четыре формата ответа. В скрипте агента тоже появятся четыре отдельные ветки. EveryInfra предоставляет доступ к четырём платформам через единый формат запросов, единую модель оплаты и единый набор кодов ошибок.

Поэтому скрипту нужна всего одна функция call(). Чтобы получить больше данных по каждой платформе, см. API данных YouTube и API данных TikTok. См. также API данных Instagram и API данных LinkedIn. Если посты компании в LinkedIn недоступны, данные о числе подписчиков можно получить с помощью возможности «Профиль компании LinkedIn».

Ограничения и предостережения

Первый риск — промпт-инъекция. Отчёт читает текст постов конкурентов, и этот текст попадает в контекст агента через MCP. OWASP называет этот риск непрямой промпт-инъекцией (OWASP LLM01 prompt injection). Контент из внешнего источника, например веб-страницы или файла, меняет поведение модели. На странице GitHub о рисках сказано, что GitHub фильтрует скрытые символы в задачах и комментариях (риски облачного агента и меры защиты). Поэтому HTML-комментарии до агента не доходят.

Это описание не охватывает текст постов из результатов инструментов MCP. План из этой статьи снижает риск. Агент читает лишь несколько примеров, когда пишет код. Еженедельный отчёт формирует скрипт, а скрипт никогда не выполняет текст постов как инструкции. Кроме того, список из трёх разрешённых инструментов ограничивает возможности агента, если инъекция сработает.

Второй момент — права агента. Согласно документации, облачный агент может отправлять изменения только в собственную ветку copilot/. Пользователь должен проверить и объединить его пул-реквест. Агент не может пометить пул-реквест как готовый, одобрить его или выполнить слияние. Workflow для его пул-реквеста запускается только после того, как пользователь с правами на запись нажмёт «Approve and run workflows». Поэтому workflow агента не сможет расходовать ваш бюджет API до проверки.

Третий момент: расписание в Actions не работает как точный будильник. В документации сказано, что запуски около начала часа могут задерживаться, а при высокой нагрузке могут пропускаться. Поэтому окно данных должно быть «с прошлого понедельника по прошлое воскресенье», а не «последние 7 дней до момента запуска». Иначе задержка на час приведёт к потере часа данных. В публичном репозитории запланированные workflow останавливаются после 60 дней без активности. Еженедельный коммит отчёта считается активностью.

Четвёртый момент касается ограничений с нашей стороны. Мы можем получать только публичный контент: посты, видео и показатели вовлечённости из публичных аккаунтов брендов. Мы не можем получать данные из закрытых аккаунтов, сведения о расходах на рекламу или данные об аудитории. Сбой LinkedIn в ту ночь — реальный пример.

Скрипт должен учитывать такое отсутствие данных, а отчёт должен сообщать о нём. Кроме того, GitHub и EveryInfra не связаны деловыми отношениями. В этой статье лишь используется публичная конфигурация GitHub MCP для подключения к нашему публичному API.

Последние изменения

• 28 октября 2026 г.: GitHub запустил MCP-серверы, проверенные GitHub, также называемые коннекторами, в режиме публичного предварительного доступа для 26 сервисов. Функция постепенно станет доступна на всех тарифах Copilot (история изменений). Что это значит для вас: такие сервисы, как Slack и Notion, теперь подключаются в один шаг. Стороннему API данных по-прежнему нужна MCP-конфигурация репозитория, а в сессиях Actions коннекторы пока не работают.
• 28 октября 2026 г.: Copilot Automations могут использовать инструменты из пользовательских MCP-серверов; в них также появились 24 триггера событий GitHub, 20 инструментов GitHub и лимиты кредитов ИИ на запуск, день, неделю и месяц (история изменений). В тот же день началось поэтапное внедрение автоматизаций для совместного использования, расходы на которые несёт владелец репозитория (история изменений по общим автоматизациям), а в VS Code теперь можно управлять облачными автоматизациями (история изменений по автоматизациям в VS Code). Что это значит для вас: еженедельный запуск Copilot теперь возможен, но каждый запуск расходует кредиты, поэтому сначала установите лимит.
• 28 октября 2026 г.: Copilot стал единой интегрированной облачной средой. Сессии по умолчанию выполняются в облачной песочнице, а включённая квота Actions превратилась в общий бюджет в долларах для раннеров и облачных песочниц (история изменений). Что это значит для вас: минуты workflow отчёта и время песочницы агента расходуются из одного бюджета. В приватном репозитории следите за общим расходом.
• 28 октября 2026 г.: GitHub Agentic Workflows перешли в стадию общей доступности. Вы описываете задачу в Markdown, после чего она компилируется в YAML для Actions, который может использовать Copilot или другого агента для написания кода (история изменений, страница проекта). Файлы блокировки workflow также перешли в стадию общей доступности, поэтому такие действия, как actions/checkout, можно привязать к конкретному коммиту (история изменений файлов блокировки). Что это значит для вас: действия в workflow отчёта можно привязать к конкретным коммитам, чтобы зависимость не изменилась без предупреждения.
• 27 октября 2026 г.: в GitHub Copilot появилась межсерверная аутентификация для GitHub Apps в организациях, доступная в режиме публичного предварительного доступа (история изменений). Сервисы, созданные с помощью Copilot SDK, могут вызывать Copilot без авторизации пользователя, а расходы оплачивает организация. Что это значит для вас: в будущем командный сервис сможет читать еженедельные отчёты с помощью Copilot в рамках бюджета организации.
• 22 октября 2026 г.: API метрик использования Copilot теперь показывает названия пользовательских MCP-серверов, Skill и пользовательских агентов (история изменений). Для каждого типа отображается до 25 названий. Что это значит для вас: администратор организации может увидеть, действительно ли пользователи используют MCP-сервер everyinfra.

FAQ

Где хранится конфигурация MCP для GitHub Copilot и совпадает ли она с mcp.json?

Этот вопрос взят из поисковых подсказок «github copilot mcp configuration» и «github copilot mcp.json». Это разные вещи. Конфигурация для облачного агента и ревью кода задаётся в настройках репозитория на GitHub: Settings → Copilot → MCP servers. Она представляет собой единый объект mcpServers, а для каждого сервера нужны type и tools.

VS Code использует .vscode/mcp.json в репозитории или ваши пользовательские настройки. Чтобы перенести настройку из VS Code, нужно внести несколько изменений (документация по MCP-конфигурации репозитория, документация VS Code по MCP). Например, добавить tools и заменить inputs на env.

Можно ли использовать удалённый HTTP-сервер как MCP-сервер агента GitHub Copilot для написания кода?

Этот вопрос взят из подсказок «copilot coding agent mcp server» и «github copilot coding agent mcp configuration». Да. Значение type может быть local, stdio, http или sse. Удалённый сервер использует url и headers.

Ограничение касается OAuth: для удалённых серверов в конфигурации репозитория облачный агент и ревью кода пока не поддерживают OAuth. Вместо этого можно передать API-ключ в заголовке. EveryInfra передаёт API-ключ по схеме Bearer (документация по MCP-конфигурации репозитория).

Где указать токен MCP-сервера для агента GitHub Copilot, который пишет код?

Этот вопрос взят из треда на Reddit о MCP-сервере Atlassian в агенте для написания кода (тред в r/GithubCopilot). Сохраните токен в разделе Agents secrets репозитория или организации под именем, которое начинается с COPILOT_MCP_. Затем ссылайтесь на него в конфигурации как $COPILOT_MCP_NAME. Секреты этого типа доступны только MCP-серверам (секреты и переменные для облачного агента).

В логе написано, что MCP подключился, но получено 0 инструментов. Что делать?

Этот вопрос взят из треда на Reddit с той же ошибкой (тред в r/GithubCopilot). Сначала проверьте, что каждое имя в списке разрешённых инструментов в поле tools в точности совпадает с именем из tools/list. Затем проверьте, не предоставляет ли сервер только ресурсы или промпты: облачный агент использует только инструменты. Для EveryInfra один POST-запрос с методом tools/list без ключа показывает все 12 имён инструментов, как в нашем тесте в 00:16 SGT (документация по MCP-конфигурации репозитория).

Может ли список разрешённых MCP-серверов в GitHub Copilot заблокировать добавленный мной сервер?

Этот вопрос взят из подсказок «github copilot mcp allowlist» и «github copilot mcp registry». Может. В документации по коннекторам перечислены политики, которые влияют на MCP. Если организация или корпоративная учётная запись GitHub Enterprise отключит параметр «MCP servers in Copilot», ни один MCP-сервер работать не будет.

Если политика «Restrict MCP access to registry servers» разрешает только серверы из реестра, клиенты, которые применяют эту политику, блокируют коннекторы. Если на уровне GitHub Enterprise задан список allowedMcpServers, адрес сервера должен входить в него. Сначала уточните эти настройки у администратора (документация по коннекторам Copilot).

Дешевле ли еженедельная автоматизация Copilot, чем скрипт в Actions?

Этот вопрос взят из нашего собственного теста и подсказки «copilot coding agent mcp». Если считать только деньги, скрипт в Actions каждую неделю расходует ноль кредитов ИИ, а плата за API для трёх брендов составляет 0,011961 $ в неделю. Автоматизация расходует кредиты ИИ при каждом запуске. Минимальный лимит на запуск составляет 30 кредитов, или 0,30 $, и автоматизации работают только в приватных или внутренних репозиториях. Автоматизация удобнее, когда нужен еженедельный анализ (документация по автоматизациям, документация по созданию автоматизаций). Скрипт дешевле, когда нужны только цифры.

С чего начать

1. Создайте в консоли EveryInfra два ключа с именами «copilot-mcp» и «weekly-actions». См. Быстрый старт.
2. В репозитории добавьте COPILOT_MCP_EVERYINFRA_API_KEY в секреты Agents, а EVERYINFRA_API_KEY в секреты Actions.
3. Вставьте JSON из этой статьи в разделе Settings → Copilot → MCP servers, указав три инструмента. Для других MCP-клиентов см. страницу MCP-сервера EveryInfra.
4. Создайте задачу по шаблону из этой статьи и назначьте Copilot исполнителем. Перед тем как объединить пул-реквест, один раз запустите workflow через workflow_dispatch.

Источники

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