AI Extensions: GitHub MCP Server 1.13.0 добавляет инструменты скрытия комментариев
MCP-сервер, умеющий скрыть рецензию на pull request, уже не только читает ваш репозиторий.
MCP-сервер, умеющий скрыть рецензию на pull request, уже не только читает ваш репозиторий. GitHub MCP Server 1.13.0, вышедший 1 октября, добавляет такую возможность записи, и это хороший повод проверить, как сочетаются наборы инструментов, режим только чтения и режим lockdown.
Коротко
Официальный проект: github/github-mcp-server, лицензия MIT. Релиз v1.13.0 добавляет детальные инструменты скрытия и возврата комментариев к issue, комментариев к PR и рецензий PR, а также снимает флаг с интерфейса MCP Apps в удалённом сервере. Наблюдение 2 октября: 33 324 звезды, 5070 форков, последний push в 10:48:50 UTC. Звёзды показывают внимание, а не качество или безопасность. Я изучил проект на GitHub, не устанавливал и не запускал его. ↗
Что изменилось в 1.13.0
Релиз опубликован 1 октября в 19:11:31 UTC. В списке изменений: инструменты скрытия и возврата, сохранение версионных пользовательских агентов STDIO API между протоколами MCP, ревизии исходников для нерелизных сборок Docker и постоянное включение интерфейса MCP Apps. Pull request с инструментами скрытия описывает по одной паре на тип объекта, мутации GraphQL minimize, обязательный классификатор вроде SPAM или OFF_TOPIC при скрытии и флаги функций issues_granular и pull_requests_granular. ↗
Перед установкой: настройка, лицензия, активность
README описывает размещённый GitHub удалённый сервер с OAuth или персональным токеном и локальный сервер в Docker (образ ghcr.io/github/github-mcp-server) или как бинарный файл. Файл LICENSE - MIT. Недавние релизы: v1.12.2 от 16 сентября и v1.13.0 от 1 октября, так что поддержка активна. Звёзды и форки на 2 октября говорят лишь о внимании. Для первой пробы я бы зафиксировал версию, использовал токен или область OAuth для одного тестового репозитория и записал, какие именно наборы включены. ↗
Где проходят границы разрешений
README сообщает, что наборы выбираются через --toolsets, а режим только чтения приоритетнее: инструменты записи пропускаются при --read-only, даже если запрошены через --tools. Lockdown описан как приблизительный фильтр содержимого публичных репозиториев от авторов без права записи, снижающий риск инъекции подсказок, и явно не граница авторизации. Мой анализ: только чтение определяет, что сервер предлагает, lockdown - часть того, что он возвращает, а токен - что примет GitHub. Текст репозитория остаётся недоверенным входом модели. Новый инструмент записи требует осознанного решения, а не обновления по умолчанию.
Чек-лист, который я написал
Код ниже - учёт, который я выполнил локально с выдуманными названиями. Он фильтрует список по префиксу имени, показывая, какие записи отбросит план только для чтения. Сервер так ничего не обеспечивает: проверьте настоящий флаг --read-only на тестовом репозитории и убедитесь, что инструменты скрытия не предлагаются.
Оригинальная синтетическая проверка
write_prefixes = ("hide_", "unhide_", "create_", "update_", "merge_", "delete_")
tools = ["get_issue", "list_issues", "hide_issue_comment", "unhide_issue_comment"]
read_only = [t for t in tools if not t.startswith(write_prefixes)]
assert read_only == ["get_issue", "list_issues"]
print("kept in a read-only plan:", read_only)
# Name-prefix bookkeeping for a review list. The server's --read-only flag,
# not this script, is the control to test.