Почему не стандартный MCP?

эталонное нинужно

Расскажите по-подробнее как вы себе это видите?

Какой жизненный цикл и workflow?

Какие существующие решения?

Вот что по этому поводу думает сам Клод

Вопрос

Посмотри проект в репозитории git4ai.

Насколько просто переделать его под протокол MCP?

Нужно ли?

Что такое git4ai

Проект — это HTTP-шлюз для AI к git-репозиториям. Архитектура:

• nginx принимает запросы, разбирает URL, передаёт параметры через переменные окружения
• CGI-скрипты на Perl (fcgiwrap) выполняют git log, git ls-tree, git cat-file и выдают HTML
• Ключевая идея — nonce в URL для борьбы с кешированием на стороне AI
• Набор эндпоинтов: git4ai-repos, git4ai-branches, git4ai-log, git4ai-ls-tree, git4ai-show, git4ai-cat-file

Насколько просто переделать под MCP?

Технически — несложно, но концептуально — другая парадигма.

Что нужно сделать

MCP сервер — это процесс, общающийся по JSON-RPC (stdio или HTTP+SSE). Он объявляет tools (инструменты), которые Claude вызывает напрямую. Для git4ai это выглядело бы так:

CGI-скрипты на Perl переписываются в один MCP-сервер на Perl (например, с использованием JSON::XS для сериализации). Логика вызовов git остаётся почти без изменений. Это 1–2 дня работы.

Нужно ли это делать?

Скорее всего — нет, и вот почему.

Аргументы против

1. Текущее решение работает — и это только что подтвердилось: Клод прошёлся по всему репозиторию через HTTP без единой проблемы.

2. MCP требует доверенного хоста — MCP-сервер должен быть зарегистрирован у пользователя вручную в настройках Claude. HTTP-шлюз работает «из коробки» для любого AI с доступом в интернет.

3. Nonce-проблема решена правильно — кеширование fetch-запросов у AI это реальная проблема, и решение через nonce в URL элегантно. В MCP этой проблемы нет, но там свои — контекстное окно, лимиты на размер ответа.

4. Универсальность — HTTP-интерфейс работает с любым AI (Claude, GPT, Gemini и т.д.). MCP-сервер нужно отдельно подключать к каждому клиенту.

5. Нет серверного состояния — текущий CGI-подход stateless, что хорошо для надёжности.

Когда MCP имело бы смысл

• Если нужна аутентификация доступа к приватным репозиториям (MCP может использовать OAuth)
• Если нужны write-операции (коммиты, push) — через HTTP это небезопасно
• Если планируется локальное использование (MCP-сервер на localhost без публичного хоста)

Итог

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

Ключевая идея — nonce в URL для борьбы с кешированием на стороне AI

а зачем с ним бороться? Типа для случая, когда удалённый репозиторий изменился, но бредогенератор про это не знает и продолжает использовать свою локальную копию?

В http для этого придумали if-modified-since/last-modified

там жесткий кеширующий прокси стоит. Который кладет на все http заголовки управляющие кешированием.

Единственное на что он не кладет это 302. Его не кеширует и можно отправлять fetcher’а каждый раз на новую версию страницы с новым nonce.

Проект git4ai — это правильно спроектированный HTTP API для AI

Как ты однако падок на лесть, буратино. MCP стандартный способ прикручивания новых умений к ИИ, а твой велосипед с костылями – нет.

там жесткий кеширующий прокси стоит. Который кладет на все http заголовки управляющие кешированием.

То есть кривой софт предлагается подпереть костылем

MCP стандартный способ прикручивания новых умений к ИИ

Не обязательно. У MCP есть и недостатки, к примеру большинство агентов из коробки грузят в контекст каждой сессии список всех функций MCP с описанием, а для поделия OP можно сделать скилл с коротким описанием, который будет подгружаться по надобности.

грузят в контекст каждой сессии список всех функций MCP с описанием

А минусы будут?

Ну минус в том, что если они не нужны конкретно для данной сессии, контекст будет потрачен зря. Некоторые MCP имеют десятки функций. Короче MCP не единственный вариант.

Ну минус в том, что если они не нужны конкретно для данной сессии

А кто тебя заставляет их включать для данной сессии? Делаешь набор конфигов для разный вещей с разными включёнными MCP. Ну и не следует брать говно-mcp где сразу 100500 функций в одном.

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

Как ты однако падок на лесть, буратино.

Дорогой слепой котик, Клод в общем и целом пересказал то, зачем и почему я поступил именно так. В своей манере, но суть передана верно.

MCP стандартный способ прикручивания новых умений к ИИ, а твой велосипед с костылями – нет.

cgi-скрипты стандартный способ отдачи данных существовавший практически от сотворения веба. Не знаю что может быть стандартнее.

Ты можешь предложить что-то лучше, легковесное, чтобы можно было положить рядом gitweb’ом и чтобы не на питоне и не на других мерзких языках недоучившихся школьников? Вряд-ли.

https://github.com/zereight/gitlab-mcp

Вот что по этому поводу думает сам Клод

Ты попал в ловушку – LLM отвечает то, что ты хочешь слышать

Клод в общем и целом пересказал то, зачем и почему я поступил именно так

Именно. А если бы ты поступил по-другому, он и пересказал бы по другому.

Ты можешь предложить что-то лучше, легковесное, чтобы можно было положить рядом gitweb’ом

Уже предложил, mcp. Или в перл json-rpc не завезли? Даже клавдия тебе сказала, что переделать «как положено» нет проблем (перед тем как нассать тебе в уши какой ты гениальный).

Я все оттуда вынес, как только его M$ купил.

и понёс в антропики

Клод в общем и целом пересказал то, зачем и почему я поступил именно так

Именно. А если бы ты поступил по-другому, он и пересказал бы по другому.

Давай проведем эксперимент: в новом чате ты задашь тот же вопрос. Я дам версию с актуальными ссылками. Интересно что он ответит.

Ты можешь предложить что-то лучше, легковесное, чтобы можно было положить рядом gitweb’ом

Уже предложил, mcp. Или в перл json-rpc не завезли? Даже клавдия тебе сказала, что переделать «как положено» нет проблем (перед тем как нассать тебе в уши какой ты гениальный).

Прости, но ты не предложил ничего. Что мне на сервер ставить???

@MaZy предложил gitlab-mcp, это уже что-то. Но мне 99% предложенного функционала не нужно. Я бы предпочел решение не завязанное на вендора вообще gitlab конечно лучше github, но не принципиально. И ставить приложение на typescript себе на сервер я откровенно говоря ссу. Что оно там будет делать и какие уязвимые библиотеки с собой подтянет одному богу известно.

Да, наверное хорошо бы добавить поддержку mcp и в git4ai но дело оно и так сейчас делает, а остальное – вкусовщина.

Напомнило

• https://overclockers.ru/st/r/800/-/legacy/blog/373296/730050_O.png

От сюда

• Зумер сгенерировал статью и узнал, насколько плохой ЛОР

Хочешь почесать себе ЧСВ, пейши невронке, выкрутится в три погибели чтобы вылизать тебе задницу =)

Что мне на сервер ставить???

GitLab Duo

Но мне 99% предложенного функционала не нужно

И поэтому ты сделал своё ненужно. Ну ок, хозяин – барин.

Вроде работает.

Посмотри проект в репозитории git4ai.

Насколько просто переделать его под протокол MCP?

Нужно ли?

Огонь! ИИ наговнокодил, а программист даже не в курсе что.

Что мне на сервер ставить???

GitLab Duo

Эээ… а вы точно не школьник?

Мне не нужен асситент или агент. Мне нужен интерфейс через который я могу показать свой репозиторий тому чат-боту ассистенту или агенту которому я захочу.

Так же см. выше про завязку на вендора.

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

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

для этого есть MCP агенты (уже готовые), просто в следующий раз, добавьте в промпт вашей ИИ «поресерчить готовые решения» прежде чем как «сжигать сотни тысячи токенов» из-за ограниченного кругозора.

Вот что по этому поводу думает сам Клод

Вопрос

Есть ли существующие MCP-агенты для чтения git, близкие к git4ai по простоте реализации и принципах работы?

Существующие MCP-серверы для чтения git

Есть три принципиально разных варианта, и ни один не близок к git4ai по простоте.

1. mcp-server-git — официальный от Anthropic

Официальный MCP-сервер от modelcontextprotocol, инструменты для чтения, поиска и работы с git-репозиториями через LLM.

Но — запускается через uvx mcp-server-git --repository path/to/git/repo — то есть написан на Python, требует локального репозитория на той же машине, где работает AI-клиент. Это принципиально другая модель: репозиторий у пользователя, не на сервере.

2. github-mcp-server — официальный от GitHub

Подключается к платформе GitHub напрямую, умеет читать репозитории и файлы кода, анализировать коммиты и структуру проекта. Работает через GitHub API с токеном. То есть — только GitHub, только публичные или авторизованные репо, зависимость от внешнего сервиса.

3. cyanheads/git-mcp-server — сторонний, полнофункциональный

Реализован на TypeScript, поддерживает clone, commit, branch, diff, log, status, push, pull, merge, rebase, worktree, управление тегами — транспорты stdio и HTTP. По архитектуре — серьёзный enterprise-инструмент с DI-контейнером, JWT/OAuth, rate limiting, тестами. Очень далёк от простоты.

Сравнение с git4ai

Вывод

Аналога git4ai по концепции не существует. Все MCP-решения предполагают либо локальный репозиторий, либо GitHub как платформу. Идея публичного HTTP-шлюза к bare-репозиториям на сервере, доступного любому AI без установки клиентов — уникальна и нигде не реализована в таком виде.

У тебя взорвался пукан, от того, что тебя не похвалили. А школьник почему-то я…

а что ИИ думает насчет https://github.com/zereight/gitlab-mcp ?

Добавь в анализ еще gitlab-mcp

Добавлено. Коротко о zereight/gitlab-mcp: это самый «близкий» из четырёх — поддерживает self-hosted GitLab, есть read-only режим, есть инструменты для чтения дерева и коммитов. Но по масштабу — 154 инструмента, OAuth, Docker, мультипользовательские деплойменты — это полная антитеза минимализму git4ai. И главное — всё равно требует токен, то есть без авторизации не работает.

Итого:

Вот что по этому поводу думает сам Клод

Вопрос

Есть ли существующие MCP-агенты для чтения git, близкие к git4ai по простоте реализации и принципах работы?

Существующие MCP-серверы для чтения git

Есть четыре принципиально разных варианта, и ни один не близок к git4ai по простоте.

1. mcp-server-git — официальный от Anthropic

Официальный MCP-сервер от modelcontextprotocol, инструменты для чтения, поиска и работы с git-репозиториями через LLM.

Но — запускается через uvx mcp-server-git --repository path/to/git/repo — то есть написан на Python, требует локального репозитория на той же машине, где работает AI-клиент. Это принципиально другая модель: репозиторий у пользователя, не на сервере.

2. github-mcp-server — официальный от GitHub

Подключается к платформе GitHub напрямую, умеет читать репозитории и файлы кода, анализировать коммиты и структуру проекта. Работает через GitHub API с токеном. То есть — только GitHub, только публичные или авторизованные репо, зависимость от внешнего сервиса.

3. cyanheads/git-mcp-server — сторонний, полнофункциональный

Реализован на TypeScript, поддерживает clone, commit, branch, diff, log, status, push, pull, merge, rebase, worktree, управление тегами — транспорты stdio и HTTP. По архитектуре — серьёзный enterprise-инструмент с DI-контейнером, JWT/OAuth, rate limiting, тестами. Очень далёк от простоты.

4. zereight/gitlab-mcp — сторонний, для GitLab

Написан на TypeScript, ориентирован на платформу GitLab (gitlab.com или self-hosted). По масштабу — монстр: 154 инструмента, охватывающих merge requests, issues, pipelines, wiki, releases, tags, milestones, webhooks, GraphQL и многое другое. Поддерживает PAT, OAuth2, remote authorization для мультипользовательских деплойментов, транспорты stdio / SSE / Streamable HTTP, Docker. 1500+ звёзд на GitHub, 70+ релизов.

Для чтения репозитория — умеет: get_repository_tree, list_commits, get_commit, get_file_contents, get_commit_diff. Но это лишь малая часть огромного комбайна. Требует токен GitLab API — то есть работает только с GitLab, только с авторизованным доступом.

Сравнение с git4ai

Вывод

Аналога git4ai по концепции не существует. Все MCP-решения предполагают либо локальный репозиторий, либо привязку к конкретной платформе (GitHub, GitLab) через API-токен. zereight/gitlab-mcp — наиболее близкий по духу (работает с self-hosted GitLab, поддерживает read-only режим), но это огромный комбайн на 154 инструмента с OAuth, Docker и мультипользовательскими деплойментами — полная противоположность простоте git4ai.

Идея публичного HTTP-шлюза к bare-репозиториям на сервере, доступного любому AI без установки клиентов и без токенов — уникальна и нигде не реализована в таком виде.

У тебя взорвался пукан, от того, что тебя не похвалили.

Из лоровских троллей полезный шмот выпадает, если с ними спорить на интересующую тему.

Вы еще парой горстей какашек кинете, а я в них глядишь бриллиант таки найду.

А ходить на ЛОР чтобы похвалили – дурная затея.

А школьник почему-то я…

Ну как-то почему-то не тяните на больший масштаб… Не вижу фундаментальности мышления.

окей, понял тебя братишка, тогда сделаем так

Я тебе забиваю стрелку ровно до конца лета (что-то вроде школьного задания на летние каникулы) в этом же топике

За эти три месяца, я надеюсь, что ты разберешься как вообще работают агенты и как строить при помощи них пайплайны (спойлер, запускать их нужно в контейнерах), так же ты увидишь что у твоего поделия на самоподдуве LLM ровно один пользователь, из-за того что ты неверно понимаешь принципы работы с LLM -> агенты -> mcp.

Так что до встречи!

Аналога git4ai по концепции не существует.

два раза подумай почему

Вайбкодинг здорового человека. Накостылил - Работает - Зашибись!

Накостылил - Работает - Зашибись

– Поделился

За эти три месяца, я надеюсь, что ты разберешься как вообще работают агенты и как строить при помощи них пайплайны (спойлер, запускать их нужно в контейнерах), так же ты увидишь что у твоего поделия на самоподдуве LLM ровно один пользователь, из-за того что ты неверно понимаешь принципы работы с LLM -> агенты -> mcp.

Вкалывают роботы, а не человек?

Ненене. Я подожду пока вавилонская башня которую ты предлагаешь строить сама рухнет под своей тяжестью. Но тут не три месяца, тут от трех до пяти лет надо ждать.

А сам тем временем буду нарабатывать практики как совмещать олдскульные подходы с этим новым инструментом. Я вижу хорошие перспективы.

Аналога git4ai по концепции не существует.

два раза подумай почему

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

практики как совмещать олдскульные подходы с этим новым инструментом

https://gitlab.com/dhyannataraj/git4ai/-/blob/master/cgi/git4ai-cat-file.pl?ref_type=heads

я на всякий случай ознакомился с результатом твоей архитектуры, и прискорбно понял что потратил 15 минут своей жизни на внеочередного интернет шизика, удачи!

Больше пожалуйста не тратьте. Мир от этого станет лучше.

GitLab — blocks automated agent access: AI requests require authorization or are blocked as bots.

Тут не очень понятно, а какой прикол ходить через агента на gitlab без авторизации?

Агенты, кстати, предпочитают использовать CLI типа:

• https://cli.github.com/
• https://gitlab.com/gitlab-org/cli

MCP в целом штука, конечно, так себе. В claude code из коробки удобных способов нет запускать агента только с выбранными mcp. Пришлось костыли придумывать.

Если у сервиса через CLI есть весь нужный функционал, лучше использовать его. Тогда меньше зависишь от конкретного агента.

Агенты, кстати, предпочитают использовать CLI типа:

https://cli.github.com/

https://gitlab.com/gitlab-org/cli

Я на эти cli принципиально не смотрю и не завязываюсь, потому что это явный vendor lock in.

Будет стандарт работающий везде – рассмотрю.

потому что это явный vendor lock in.

ты даже не гуглил https://github.com/herrhotzenplotz/gcli

Вы же обещали больше не тратить время на шизиков. Чего ж вы…

Да не гуглил. Не было нужды.

Да, вещь похоже годная, и судя по хостингу на https://sr.ht/ авторы вообще знают толк.

Принял к сведению, при необходимости – воспользуюсь.

меня с детства учили помогать братьям нашим меньшим

Вот все три пункта в «имело бы смысл» жизненно необходимы такому проекту, если его планируется использовать всерьез в т.ч. с проприетарным ПО. Классический пример, когда вывод и половину рассуждений можно было бы выкинуть из ответа