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. У переліку змін: інструменти приховування й повернення, збереження версійних user agent для 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.