MCP Git даёт агенту инструменты для работы с локальным Git-репозиторием через reference сервер mcp-server-git. Для начального пилота достаточно на тестовой копии прочитать status, diff и log, сверить ответы с Git и отдельно проверить отказ в вызовах записи. Upstream прямо называет проект ранней разработкой, поэтому состав инструментов и границы доступа фиксируют для выбранной версии.
Локальный Git
mcp-server-git предоставляет агенту операции чтения Git, включая `git_status`, варианты `git_diff` и `git_log`, а также инструменты изменения репозитория. Начальный сценарий ограничивают тестовой копией и чтением; полномочие на запись оформляют отдельно.
Официальный README reference сервера описывает доступ к локальному рабочему дереву, индексу и истории. Это другой контур, чем MCP GitHub для облачного репозитория: здесь агент обращается к файловой копии Git через локальный сервер. Проверка PR, разрешений организации GitHub и комментариев на площадке относится к API облачного сервиса. Локальный status показывает состояние выбранной копии, поэтому вывод зависит от её файлов и текущей ветки.
Представим задачу ревью: разработчик подготовил изменение конфигурации в тестовом репозитории и хочет быстро описать, какие файлы затронуты. Агент может запросить `git_status`, затем увидеть unstaged или staged diff и историю соответствующей ветки. Такой обзор помогает сформулировать вопросы к человеку, который владеет изменением. Полный diff и тесты остаются обязательными: смысл правки определяется требованиями проекта, а локальная копия может отличаться от удалённой ветки.
README отдельно предупреждает, что mcp-server-git находится на раннем этапе разработки, а инструменты могут меняться. Инструкцию для рабочей команды стоит привязать к проверенной версии и повторно сверять перед обновлением. В статье описан план пилота, без заявлений о готовности сервера к производственной эксплуатации. Для первого допуска важнее увидеть точный корень репозитория, список предоставленных инструментов и правила запрета записи, чем оценивать удобство диалога с моделью.
Тестовая копия
Перед подключением подготовьте отдельную копию репозитория с разрешёнными файлами и понятным ожидаемым состоянием. Владелец кода выбирает ветку, фиксирует ревизию и убирает из пилота секреты, личные данные и посторонние рабочие изменения. Агент получает ровно тот путь, который согласован для теста. Если команда использует общий компьютер, контролируйте и права ОС на каталог, и доступ клиента к локальному MCP-серверу. Текст запроса к модели служит инструкцией, а техническую границу задаёт среда.
У параметра `--repository` есть важная особенность: согласно README, путь к вложенному каталогу поднимается до корня Git-репозитория. Значит, указание вложенной папки оставляет областью доступа весь Git-репозиторий. Для узкого пилота выбирают целую тестовую копию без нежелательных файлов и проверяют фактический корень, который увидит сервер. Права на чтение и запись применяют к этому корню, а перечень доступных `repo_path` проверяют на стороне сервера или внешнего контрольного слоя.
До запуска команда составляет эталон: известные изменённые файлы, ожидаемый status, содержимое diff и несколько записей log. Эталон получают обычными инструментами Git в той же копии и связывают с ревизией. Для полного перечня файлов парсер или скрипт сравнит выводы без пропусков. Языковая модель объяснит возможные расхождения и предложит гипотезы, а разработчик сверит их с реальными файлами и индексом. Проверку проводит человек с разрешением на тестовый репозиторий.
Выберите целую тестовую копию и зафиксируйте её корень. Вложенный путь в `--repository` ведёт к корню Git, поэтому границу доступа проверяют отдельно.
Маршрут чтения
На тестовой копии начните со списка доступных инструментов и выбранного пути. Затем задайте агенту узкую задачу: перечислить изменённые файлы и различить изменения в рабочем дереве и индексе. README перечисляет `git_status`, `git_diff_unstaged`, `git_diff_staged`, `git_diff` и `git_log`; для просмотра объекта на ревизии есть `git_show`. Названия полезны как точные ориентиры для пилота, однако доступность сверяют с установленной версией сервера.
- Зафиксируйте тестовую ревизию, ветку и ожидаемый список изменений. Запишите фактический корень локальной копии, к которому подключён сервер.
- Вызовите `git_status` для этой копии и сопоставьте ответ с эталоном. Разберите новые файлы, изменённые файлы и состояние индекса.
- Сравните `git_diff_unstaged` и `git_diff_staged`. Для сравнения с выбранной веткой или коммитом используйте `git_diff` с разрешённой целью.
- Прочитайте `git_log` и при необходимости `git_show` для конкретной ревизии. Сверьте путь, содержимое и происхождение записи с локальным Git.
- Попросите агента объяснить изменение в обычном языке. Разработчик сверяет каждое существенное утверждение с diff и запускает профильные тесты.
Ответ по status показывает состояние рабочего дерева, а diff раскрывает содержимое изменений. Эти ответы могут отличаться после любой новой правки, поэтому в журнале пилота фиксируют ревизию и состояние копии на момент запроса. Для длинных или полных выгрузок используйте детерминированный скрипт, который сопоставляет список путей и фрагменты diff. Модель помогает выделить риск, например изменение публичной функции; человек подтверждает его по исходнику и тестовому сценарию.
Связь с облачной площадкой можно оставить за рамками. Если нужен общий маршрут работы с репозиторием и PR, смотрите материал об ИИ-агентах в разработке. Здесь критерий уже: агент через MCP читает локальную копию и возвращает проверяемые сведения о её состоянии. Такой фокус упрощает тест прав, потому что каждый результат привязан к конкретному пути и коммиту.
Хотите проверить локальный Git-доступ агента на тестовой копии?
Граница записи
Тот же README перечисляет write-tools: `git_add`, `git_commit`, `git_reset`, `git_create_branch` и `git_checkout`. Они меняют индекс, историю либо выбранную ветку. Поэтому команда должна отделить чтение от действий записи в политике доступа. На этапе чтения проверяемый слой разрешений отклоняет вызовы этих инструментов, даже если агент просит выполнить их уверенным текстом. При отсутствии проверяемого запрета пилот проводят в среде с технически закрытой записью и фиксируют это условие.
| Группа | Пример инструмента | Проверка |
|---|---|---|
| Состояние | `git_status` | Сверить путь и рабочее дерево |
| Изменения | `git_diff_unstaged`, `git_diff_staged` | Сверить полный diff с Git |
| История | `git_log`, `git_show` | Сверить ревизию и объект |
| Запись | `git_add`, `git_commit`, `git_checkout` | Получить отказ до отдельного допуска |
Отказ проверяют намеренно на тестовой копии: агент запрашивает изменение индекса, а серверная политика или изоляция среды оставляет Git-состояние прежним. Разработчик сверяет status до и после запроса. Такое наблюдение надёжнее словесного обещания модели. Если позже появится задача записи, владелец репозитория отдельно утверждает вид операции, область файлов, порядок просмотра diff и восстановление из проверенной копии. Для записи нужен собственный тест разрешений.
Осторожность нужна и при чтении: diff и log могут содержать закрытые данные, случайно попавшие в историю. Агенту передают только тестовую копию с разрешённым содержимым. Журнал пилота хранит путь, тип запроса, решение политики и краткий результат без копирования секретов. Владелец проекта определяет, где допустимо сохранять такие записи и кому открыт доступ. Это обеспечивает понятный разбор отклонений без расширения полномочий инструмента.
Приёмка пилота
Предложенный пилот принимают по результатам конкретных проверок. Читающие вызовы должны совпасть с эталоном для выбранной копии, вызов записи должен получить отказ, а путь вне разрешённого корня должен остаться закрытым. Затем разработчик просматривает объяснение агента и отмечает утверждения, которые подтверждены diff и тестами. Если найдено расхождение, сначала выясняют его источник: изменившийся индекс, другая ветка, неверная цель сравнения или неполный вывод.
Критерии полезно закрепить в коротком протоколе: версия сервера, корень копии, набор доступных инструментов, результаты чтения, ответы на запрещённые вызовы и решение владельца кода. Повторный тест понадобится при обновлении reference проекта, поскольку авторы предупреждают об изменчивости инструментов. Протокол показывает наблюдаемое поведение выбранной версии в ограниченном контуре. Готовность к производственной эксплуатации требует отдельной оценки.
Стоимость внедрения зависит от поддержки MCP-клиента, изоляции тестовой среды, политики доступа и объёма инженерной проверки. Цены и тарифы обсуждают качественно по составу работ; обещания экономии требуют отдельного замера на задачах команды. Для проектирования такого маршрута пригодится страница об ИИ-агентах для рабочих процессов. Сначала договоритесь, какие Git-операции агент вправе видеть, кто утверждает запись и как проверяют результат.
Успех пилота означает ясную границу: статус, изменения и история читаются из согласованной копии; запись остаётся под отдельным контролем. Человек знает, как воспроизвести вывод и проверить его по исходникам. Такой результат помогает решить, стоит ли расширять сценарий на другие репозитории. Для каждого нового проекта границы доступа и эталонные тесты задают заново, учитывая структуру кода и правила команды.