Почему это важно именно вам
Если в вашей компании есть разработчики, у вас есть GitHub. Репозитории с кодом сайта, ботов, внутренних инструментов. И каждый раз, когда нужно понять «что происходит с проектом» — нужно либо идти к разработчику, либо разбираться в интерфейсе GitHub, который проектировался не для директоров.
Типичная ситуация: вы договорились, что новый модуль будет готов к пятнице. Пятница наступила, пуш в прод не случился. Вопрос «как дела» вернул ответ «почти готово». Чтобы понять реальное состояние, нужно зайти в GitHub, найти нужный репозиторий, открыть pull requests, прочитать комментарии — и это занимает 15 минут, потому что интерфейс для тех, кто знает, что ищет.
С MCP GitHub эта сцена выглядит иначе: вы просто спрашиваете Claude «какие PR открыты в репозитории сайта и кто последний оставлял комментарии», получаете сводку за 20 секунд и идёте на планёрку с конкретными данными. Не «разработчик говорит что скоро», а «три PR открыто, один в review три дня без ответа». Это другой разговор.
Второй сценарий, который встречается реже, но не менее ценен: аудит кодовой базы после инцидента. Утёк лид, не дошло письмо, не сработал вебхук — и нужно быстро понять, в каком репозитории и в каком файле это могло быть реализовано. Раньше это был разговор с разработчиком: «объясни мне, как устроена система». Теперь можно спросить Claude, который имеет прямой доступ к коду и документации в репозиториях. Это не замена разработчику, но это другой уровень самостоятельности при расследовании.
Что это такое
MCP GitHub — это мост между Claude и вашими репозиториями. Работает по той же логике, что и другие MCP-инструменты, о которых мы говорили в Дне 51: Claude получает доступ к внешней системе через стандартный протокол и может обращаться к ней с запросами на человеческом языке.
Если аналогия нужна: представьте, что у вас есть очень толковый аналитик, который умеет работать с GitHub. Вы говорите ему «найди все issues с упоминанием слова "оплата"» — он идёт, ищет, возвращается с результатом. Вам не нужно знать синтаксис поиска GitHub, понимать разницу между labels и milestones или помнить, в каком репозитории лежит нужный проект. Вы формулируете задачу, он делает.
Что GitHub MCP умеет читать: открытые и закрытые PR, их статус и комментарии; issues с фильтрацией по статусу, метке, дате; содержимое файлов в репозитории; историю коммитов; список репозиториев организации. Что умеет создавать: новые issues (задачи/баги для разработчиков). Что не умеет (и правильно): пушить код, мержить PR, удалять данные — это требует отдельных прав и отдельного решения.
Важный нюанс: MCP не хранит данные локально. Каждый ваш запрос — это запрос в реальное время к GitHub API. Это значит, что данные всегда актуальные, но это также значит, что нужно подключение к интернету и валидный токен. Если токен истёк или права изменились — MCP перестанет работать, Claude сообщит об ошибке авторизации.
GitHub MCP — это доступ для чтения плюс создание issues
Большинство рабочих сценариев директора — именно чтение: понять статус, найти информацию, собрать контекст. Для этого достаточно. Создание issues — приятный бонус: вы можете прямо из Claude сформировать задачу для разработчика.
Как работает на практике
Шаг 1. Получить Personal Access Token
Прежде чем подключать MCP, нужен токен — это ваши «ключи» от GitHub-аккаунта или организации.
Открываете GitHub → правый верхний угол → Settings → в боковом меню листаете вниз до Developer settings → Personal access tokens → Tokens (classic) → Generate new token (classic).
Называете токен понятно: claude-mcp или claude-readonly. В разделе Select scopes отмечаете:
repo— доступ к приватным репозиториям (если нужны не только публичные)read:org— если нужен доступ к репозиториям организации
Для публичных репозиториев достаточно создать токен без галочек — он всё равно позволит работать с публичными данными.
Нажимаете Generate token. Токен показывается один раз — скопируйте его и сохраните в менеджер паролей. Это строка вида ghp_xxxxxxxxxxxxxxxxxxxx.
Токен показывается один раз
GitHub больше не покажет вам токен после закрытия страницы. Если потеряли — нужно создавать новый. Сохраните сразу, до того как закрыть вкладку.
Шаг 2. Добавить MCP в Claude Code
Открываете терминал. Выполняете команду:
claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer ghp_ваш_токен"
URL и токен передаются прямо в команде — интерактивных вопросов не будет. Используете официальный удалённый MCP-сервер GitHub:
https://api.githubcopilot.com/mcp/
Команда только записывает конфигурацию, не проверяя токен: при неверном ключе сервер добавится, а упадёт уже при подключении. Проверьте через /mcp — должно быть connected, а не failed.
Альтернативный вариант через npx
Если официальный http-транспорт недоступен, есть вариант через локальный сервер:
claude mcp add github -- npx -y @modelcontextprotocol/server-github
В этом случае токен передаётся флагом --env: claude mcp add --env GITHUB_PERSONAL_ACCESS_TOKEN=ваш_токен --transport stdio github -- npx -y @modelcontextprotocol/server-github. Этот способ требует Node.js на вашем компьютере.
Шаг 3. Проверить подключение
После добавления проверяете, что MCP виден:
claude mcp list
Должны увидеть github в списке. Теперь запускаете Claude Code и проверяете прямым вопросом:
claude -p "Через GitHub MCP: найди репозитории доступные мне"
Если всё подключено корректно — Claude вернёт список репозиториев. Если ошибка авторизации — проверьте, что токен скопирован без пробелов и не истёк.
Шаг 4. Рабочие запросы
Теперь показываю, как это выглядит в реальных сценариях. Claude Code запускаете интерактивно или через -p.
Узнать статус разработки:
Используй GitHub MCP. Репозиторий novostroy-site.
Покажи все открытые pull requests: название, кто создал, когда, статус ревью.
Получите структурированный список, не HTML-интерфейс GitHub.
Найти проблему в истории:
Используй GitHub MCP. В репозитории main-bot найди все issues
с метками "bug" или "критичный", открытые за последние 30 дней.
Для каждого — краткое описание и кто назначен.
Проверить конкретный файл:
Используй GitHub MCP. В репозитории analytics-scripts
прочитай файл README.md и скажи, какие скрипты там описаны.
Полезно, когда нужно понять, что вообще лежит в репозитории, без клонирования.
Создать задачу для разработчика:
Используй GitHub MCP. В репозитории novostroy-site создай issue:
Заголовок: "Добавить UTM-параметры в форму обратного звонка"
Описание: "При приёме звонка через форму на главной не передаются UTM-метки.
Нужно пробросить utm_source, utm_medium, utm_campaign в CRM."
Метка: enhancement
Claude создаст issue, вернёт ссылку. Разработчик получит задачу сразу в трекере, не в мессенджере.
Поиск по содержимому:
Используй GitHub MCP. Найди в организации novostroy все файлы
с упоминанием функции sendLead. В каких репозиториях она используется?
Это уже мощный инструмент аудита — понять, где в кодовой базе что-то используется, без помощи разработчика.
Комбинированный запрос — статус спринта:
Используй GitHub MCP. Организация novostroy-m.
Дай мне сводку по активной разработке:
1. Сколько PR открыто в каждом репозитории
2. Есть ли PR без активности больше 3 дней
3. Сколько issues с меткой "bug" открыто суммарно
Формат — короткий список, без технических деталей.
Это заменяет еженедельный созвон с командой «как дела у разработки» — вы получаете факты, а не ощущения. Если встреча всё же нужна — вы приходите с конкретными вопросами, а не с открытым «расскажи как дела».
Формулируйте запросы через задачу, не через команду
Не «выполни getIssues для репозитория X» — Claude сам разберётся с API. Говорите «найди все открытые баги в проекте X за эту неделю». Результат лучше, запрос проще.
Частые ошибки
Ошибка 1: Забыть указать репозиторий
Самая частая. «Покажи открытые PR» без указания репозитория заставит Claude либо спрашивать уточнения, либо перебирать всё доступное. Всегда указывайте конкретный репозиторий или организацию в запросе — это экономит время.
Ошибка 2: Токен с избыточными правами
Некоторые создают токен с полными правами «чтобы всё работало». Для задач директора достаточно доступа на чтение содержимого и issues; read:org — если нужны репозитории организации. Учтите: у classic-токена repo означает полный доступ, включая запись, поэтому для чтения лучше fine-grained токен. Лишние права admin:repo_hook, delete_repo — риск без пользы. Если токен утечёт (например, случайно попадёт в файл, который вы кому-то отправили), последствия будут минимальными при минимальных правах.
Ошибка 3: Ожидать поиска по коду внутри файлов
GitHub MCP может читать конкретный файл по пути, но глубокий поиск по коду («найди все места, где вызывается функция X») работает только через GitHub Search API и только в репозиториях с включённым индексированием. Если поиск возвращает пустой результат — скорее всего, это ограничение индекса, а не ошибка подключения.
Ошибка 4: Путать организацию и личный аккаунт
Если репозитории принадлежат организации (например, novostroy-m), а токен создан под личным аккаунтом — нужно, чтобы аккаунт был членом организации. Если репозитории не видны после подключения, попросите администратора GitHub добавить ваш аккаунт в организацию с правами на чтение.
Дополнительный момент: если организация использует SSO (Single Sign-On), токен нужно отдельно авторизовать для неё. После создания токена на странице настроек появится кнопка «Configure SSO» рядом с токеном — нажать и авторизовать для нужной организации. Без этого токен работает, но репозитории организации с SSO не видны.
Создание issues — необратимое действие
Issues в GitHub публичны для участников репозитория. Если попросите Claude создать issue, он это сделает без дополнительного подтверждения. Перед тем как давать команду на создание — проверьте, что текст задачи корректный. В отличие от черновика письма, issue сразу видят все.
Когда нужно / когда нет
GitHub MCP нужен, если:
- У вас есть разработчики и GitHub-репозитории, за состоянием которых вы следите
- Вам регулярно нужно знать статус задач без того, чтобы беспокоить команду
- Хотите ставить задачи разработчикам прямо из Claude, без переключения на GitHub
- Нужно быстро найти документацию или README в кодовой базе
GitHub MCP избыточен, если:
- Репозиториев нет или доступа к ним нет — подключать нечего
- Разработка полностью на аутсорсе и в другой системе (GitLab, Bitbucket, Jira) — GitHub MCP здесь не поможет, нужны другие коннекторы
- Вы уже хорошо ориентируетесь в GitHub и открыть вкладку не проблема — MCP даёт выигрыш тем, кто в интерфейсе GitHub чувствует себя чужим
Разовая проверка vs регулярная работа:
Если нужно один раз посмотреть что-то в GitHub — проще открыть браузер. MCP окупается, когда это регулярный паттерн: еженедельный статус-чек разработки, ежедневный мониторинг открытых PR, создание задач после встреч. Тогда 30 минут на настройку возвращаются за первую неделю.
Есть ещё один сценарий, где MCP даёт неожиданный выигрыш — когда репозиториев много и они разбросаны по нескольким командам. Открыть GitHub и обойти пять репозиториев в поисках всех открытых issues по определённой теме — это долго. Claude делает это одним запросом, потому что может последовательно опросить несколько репозиториев и собрать сводку. Для одного репозитория преимущество скромное, для нескольких — уже ощутимое.
GitLab и Bitbucket
Если ваша команда использует GitLab или Bitbucket — для них существуют отдельные MCP-серверы с аналогичной логикой подключения. Принцип тот же: Personal Access Token + claude mcp add. Проверьте наличие сервера на modelcontextprotocol.io/servers.
Связь с другими уроками
День 51 (что такое MCP; транспорты — День 52, области видимости — День 53) — базовые уроки по архитектуре MCP. Если команда claude mcp add кажется непонятной или что-то не подключается, нужные объяснения там: что такое транспорт, как Claude находит инструменты, что означают scopes.
День 55 (MCP Notion) — следующий шаг: подключение Notion для работы с документами и базами данных. Связка GitHub + Notion даёт полную картину: из GitHub смотрим статус разработки, в Notion ведём документацию и планы. Claude умеет работать с обоими источниками в одном запросе.
День 39 (cron и расписание) — если хотите автоматический еженедельный отчёт по открытым PR, это делается через cron + Claude с GitHub MCP. «Каждый понедельник в 9:00 — сводка по репозиториям» настраивается один раз и работает без вашего участия.
Задание на сегодня
Возьмите любой публичный GitHub-репозиторий, связанный с вашей работой — или просто известный проект (например, anthropics/anthropic-sdk-python). Настройте GitHub MCP по шагам выше и выполните один запрос:
Используй GitHub MCP. В репозитории [название]
найди 3 последних открытых issue. Для каждого —
заголовок, когда создан, сколько комментариев.
Критерий «выполнено»: Claude вернул структурированный список из трёх issues с датами и количеством комментариев — не ошибку, не «не могу получить данные», а реальные данные из репозитория.
Если публичный репозиторий, токен можно создать без галочек — он всё равно работает для публичных данных. Так что барьер входа минимален.
Резюме
- GitHub MCP подключается через
claude mcp add --transport http githubи Personal Access Token с правамиrepo+read:org - Для директора главные сценарии: статус PR без похода к разработчику, поиск по issues, чтение документации в репозитории, создание задач прямо из Claude
- Запросы формулируются на человеческом языке — «найди открытые баги за неделю», не API-команды
- Создание issues — необратимо и видно команде сразу, поэтому проверяйте текст перед отправкой
- MCP окупается при регулярной работе с GitHub; для разовых проверок проще открыть браузер