GitHub за останній рік перетворився на один із найважливіших майданчиків для експериментів з Model Context Protocol (MCP) — інтерфейсом, через який агенти LLM отримують доступ до зовнішніх сервісів і даних. Компанія відкрила локальний MCP‑сервер у квітні 2024 року, а нещодавно проєкт відсвяткував перший рік існування. Сам Морроу, який очолює розробку MCP‑сервера GitHub, на конференції AI Engineer Europe у Лондоні розповів, як команда пройшла шлях від «інструментального перегріву» до значно більш ощадливого та передбачуваного інтерфейсу для агентів.
Ця історія — не про архітектуру чи безпеку (їм присвячені інші розмови), а про дизайн «поверхні інструментів» GitHub MCP: як кількість, структура та вербальне оформлення тулів безпосередньо впливають на якість роботи агентів і вартість токенів. І як, крок за кроком, GitHub змушений був відмовлятися від інтуїтивного «давайте дамо все» на користь обмеженого, але добре продуманого набору можливостей.
Коли «більше інструментів» робить агентів гіршими
Публічний MCP‑шлях GitHub стартував із гучного запуску: репозиторій локального сервера швидко став одним із найзірковіших на GitHub за тиждень, а спільнота почала масово додавати нові інструменти. Платформа GitHub за своєю природою величезна, тож MCP‑поверхня швидко розрослася: репозиторії, issues, pull requests, GitHub Actions, проєкти та інші сутності — для всього з’являлися окремі тули.
У результаті MCP‑сервер GitHub на певному етапі експонував понад 100 інструментів. Формально це виглядало як перемога: покриття платформи зростало, користувачі отримували доступ до дедалі більшої кількості операцій. Але поведінка агентів показала протилежне: після першого місяця активної розробки вони стали гірше працювати з GitHub, а контекстні вікна моделей «згорали» значно швидше.
Це співпало з уже опублікованими дослідженнями, зокрема роботою LangChain, яка вийшла ще в лютому того ж року: збільшення кількості інструментів, особливо коли їхні описи безпосередньо зашиваються в контекст, не робить агентів розумнішими. Навпаки, агенти починають плутатися, забувати, що саме їм доступно, і частіше обирають не ті тули або викликають їх у невдалих комбінаціях.
Проблема виявилася подвійною. З одного боку, GitHub не хотів забирати в користувачів можливість працювати з рідкісними чи спеціалізованими можливостями платформи. З іншого — «плоский» список зі 100+ інструментів виявився непридатним для ефективної роботи агентів і надто дорогим з точки зору токенів. Потрібен був спосіб зберегти широту платформи, але зробити її керованою.
«Tool sets» і динамічний вибір: елегантні рішення, якими майже ніхто не користується
Першою відповіддю GitHub на вибух інструментів стала поява «tool sets» — механізму логічного групування MCP‑тулів за продуктами або сценаріями. Ідея була простою: замість того, щоб завжди показувати агенту всі можливості, сервер пропонує набір тематичних груп, а користувач може обрати лише ті, що відповідають його робочому процесу.
Наприклад, окремий набір для роботи з pull requests, інший — для issues, ще один — для GitHub Actions. Користувачі могли конфігурувати ці групи у JSON‑налаштуваннях, вмикаючи тільки потрібні. Це мало зменшити обсяг початкового контексту, який отримує модель, і водночас зберегти доступ до повного спектра можливостей для тих, хто готовий їх явно вмикати.
Другим кроком стала динамічна селекція інструментів. Замість того, щоб одразу завантажувати всі tool sets, GitHub реалізував механізм, за якого агент може «відкривати» групи інструментів порціями. Спочатку агент бачить лише базовий набір, а потім, за потреби, може «відкрити» додаткові групи. Це дозволяє уникнути ситуації, коли весь опис 100+ тулів опиняється в контексті ще до того, як агент зрозумів, що йому взагалі потрібно робити.
Внутрішньо команда навіть експериментувала з RAG‑подібним підходом до пошуку інструментів — семантичним пошуком по описах тулів, щоб агент міг знаходити релевантні можливості за змістом запиту, а не за жорстко заданими групами. Цей експеримент так і не дійшов до релізу, але він демонструє напрямок мислення: зробити поверхню інструментів не статичним списком, а динамічним простором, у якому агент орієнтується за змістом задачі.
Однак на практиці всі ці елегантні рішення вперлися в людський фактор. Переважна більшість користувачів GitHub MCP продовжила користуватися дефолтними налаштуваннями, не витрачаючи час на ручну конфігурацію tool sets. Формально можливість тонкого налаштування існувала, але реальна поведінка користувачів показала: якщо щось вимагає редагування JSON, цим скористається лише невелика меншість.
Це поставило під сумнів саму ідею перекладати оптимізацію контексту на кінцевих користувачів. Навіть коли інструменти для цього є, більшість людей не хоче або не встигає ними користуватися. Відповідальність за ефективність довелося повернути на бік сервера.
Як GitHub скоротив початковий контекст майже вдвічі
Усвідомивши, що конфігурованість сама по собі не рятує, команда GitHub перейшла до системної оптимізації MCP‑поверхні з боку сервера. Ключовою метою стало зменшення кількості токенів, які витрачаються на початкове завантаження описів інструментів, без радикального урізання функціональності.
Перший етап полягав у фокусуванні тулів на «загальний випадок». Команда проаналізувала реальні патерни використання віддаленого MCP‑сервера й на основі цих даних переформатувала набір інструментів так, щоб дефолтний поверхневий шар краще відповідав типовим сценаріям. Це дозволило зменшити обсяг початкового контексту приблизно на 49 відсотків.
Тобто майже половина токенів, які раніше витрачалися на опис інструментів, виявилася зайвою для більшості користувачів. Це не означає, що рідкісні можливості зникли, але вони перестали бути частиною «обов’язкового» багажу, який агент тягне з собою з першого кроку.
Другим важливим кроком стало групування CRUD‑інструментів. У багатьох API‑поверхнях для кожної сутності існує кілька базових операцій: створення, читання, оновлення, видалення. Якщо кожну з них оформити як окремий MCP‑тул із повним описом, контекст швидко роздувається. GitHub переглянув цей підхід, згрупувавши CRUD‑операції таким чином, щоб зменшити кількість окремих тулів і дублювання тексту в їхніх описах.
У результаті дефолтний набір увімкнених інструментів звузили приблизно до 40. Це все ще суттєвий функціональний обсяг, але вже не сотня плюс. Користувачі, яким потрібно більше, можуть розширювати цей набір, але базовий сценарій став значно дешевшим з точки зору токенів і простішим для агентів.
Важливо, що GitHub не пожертвував гнучкістю: MCP‑поверхня залишилася легко кастомізованою. Але тепер навіть ті, хто ніколи не відкриє конфігураційний файл, отримують більш оптимізований досвід «із коробки». Це критично в екосистемі, де більшість користувачів не хоче бути системними адміністраторами власних агентів.
Від економії на описах до економії на вихідних токенах
Оптимізація MCP‑поверхні не обмежилася лише тим, що потрапляє в контекст як опис інструментів. Наступним фронтом стала економія на вихідних токенах — тобто на тому, що самі тули повертають у відповідь на виклики.
GitHub провів «масовану атаку» на багатослівні відповіді MCP‑інструментів, переглядаючи, яка саме інформація насправді потрібна агенту для подальших кроків. Один із показових прикладів — інструмент для переліку pull requests. Раніше він повертав значно більше даних, ніж було необхідно для більшості сценаріїв, що призводило до великої кількості вихідних токенів.
Після таргетованого перегляду структури відповіді й того, які поля дійсно потрібні агенту, GitHub зміг скоротити кількість токенів, які використовує цей інструмент, більш ніж на 75 відсотків. Тобто вихід став у чотири рази компактнішим, не втративши при цьому корисності для типових задач.
Цей підхід масштабували й на інші тули. Логіка проста: кожен зайвий фрагмент тексту у відповіді MCP‑інструмента — це не лише додаткові витрати, а й додатковий шум для моделі. Чим компактніше й структурованіше повертаються дані, тим легше агенту приймати наступні рішення й тим дешевше обходяться сесії.
У сукупності з оптимізацією описів інструментів це означає, що «токенова прожерливість» MCP‑сервера GitHub — рухома ціль. Команда постійно змінює й покращує поверхню, тож досвід користувача кількамісячної давнини може суттєво відрізнятися від поточного.
Як підвищити успішність викликів: інтенція агента і серверні багатокрокові операції
Оптимізація контексту — лише одна сторона задачі. Інша — зробити так, щоб агенти рідше помилялися у виборі й використанні інструментів. GitHub окремо сфокусувався на зменшенні кількості невдалих викликів MCP‑тулів, і нині успішність викликів перевищує 95 відсотків.
Повністю уникнути помилок неможливо: агенти можуть не знати, до яких репозиторіїв у користувача є права на запис, продовжують галюцинувати й часом намагаються виконувати операції там, де це неможливо. Але значну частину проблем вдалося зняти завдяки тому, що GitHub почав явно кодувати «інтенцію агента» в поверхню інструментів.
Йдеться про те, що один виклик MCP‑тулу насправді може приховувати за собою кілька API‑запитів до GitHub. Замість того, щоб змушувати агента поетапно викликати кілька інструментів (наприклад, спочатку знайти репозиторій, потім перевірити права, потім виконати дію), сервер бере на себе цю багатокрокову логіку. Якщо для надійного виконання операції потрібно зробити п’ять API‑запитів, GitHub робить їх на сервері, а не делегує це агенту.
Це дає одразу кілька вигод. По‑перше, зменшується кількість «раундів» між агентом і MCP‑сервером, а отже — і обсяг контексту, який потрібно тримати в пам’яті моделі. По‑друге, зростає надійність: сервер краще знає особливості API й може обробляти помилки й крайові випадки централізовано. По‑третє, користувач отримує більш передбачуваний досвід: один виклик інструмента робить «правильну річ» замість того, щоб вимагати від агента складної послідовності дій.
Ще один важливий інструмент — регулярні eval‑тести MCP‑поверхні. GitHub використовує їх не для мікрооптимізації описів окремих тулів, а для перевірки того, як інструменти працюють у сукупності. Завдання полягає в тому, щоб інструменти викликалися «вчасно» й «у правильному порядку»: щоб жоден тул не був настільки привабливо описаний, що агент починає викликати його завжди, і щоб корисні, але менш очевидні інструменти не ігнорувалися.
Це тонкий баланс. Ідеальний опис інструмента, який змушує модель викликати його за кожної нагоди, на практиці виявляється катастрофою. Так само погано, коли тул настільки «скромний», що агент його ніколи не обирає. Evals дозволяють виявляти такі перекоси й коригувати поверхню інструментів як цілісну систему, а не набір ізольованих елементів.
Чому навіть «простий» режим read‑only вимагає підтримки на рівні клієнтів
Окремий пласт дискусії навколо MCP‑поверхні GitHub — це режими доступу й те, як вони відображаються в інтерфейсі інструментів. Команда додала до сервера режим read‑only, який напряму мапиться на анотацію read‑only hint у специфікації MCP. Приблизно 17 відсотків користувачів GitHub MCP сьогодні використовують цей режим.
Для багатьох організацій це очевидний варіант: дозволити агентам читати дані з GitHub, але не давати їм можливості змінювати репозиторії, issues чи pull requests. З точки зору MCP‑поверхні це означає, що набір доступних інструментів і їхня семантика змінюються залежно від режиму.
Втім, навіть тут виявилася проблема інтеграції: хоча MCP‑специфікація передбачає read‑only hint, більшість клієнтів не надають користувачам простого способу фільтрувати сервери за цим параметром. Деякі шлюзи починають це робити, але загалом екосистема відстає від можливостей, які вже є в протоколі й реалізовані на сервері GitHub.
Це ще раз підкреслює загальну тенденцію: навіть коли сервер надає багатий набір режимів і конфігурацій, реальний вплив на користувацький досвід залежить від того, наскільки клієнти ці можливості підхоплюють і виносять на поверхню. І поки цього не відбувається масово, GitHub змушений проєктувати MCP‑поверхню так, щоб дефолтні налаштування були максимально безпечними й ефективними самі по собі.
Висновок: дизайн MCP‑поверхні як окрема інженерна дисципліна
Досвід GitHub із MCP‑сервером за перший рік показує, що дизайн «поверхні інструментів» для агентів — це окрема інженерна дисципліна, яка вимагає постійного балансування між широтою можливостей, простотою використання й вартістю токенів.
Початковий підхід «експонуємо все, що можемо» швидко привів до перевантаження агентів і неефективного використання контексту. Спроба перекласти оптимізацію на користувачів через tool sets і динамічний вибір інструментів виявилася надто оптимістичною: більшість людей залишилася на дефолтних налаштуваннях. У відповідь GitHub почав агресивно оптимізувати MCP‑поверхню на боці сервера: скоротив початковий контекст майже вдвічі, згрупував CRUD‑операції, звузив дефолтний набір до приблизно 40 тулів і радикально урізав вихідні токени для окремих інструментів, зокрема для переліку pull requests.
Паралельно команда підвищила успішність викликів до понад 95 відсотків, кодує інтенцію агента в інтерфейс інструментів, виконує багатокрокові API‑послідовності на сервері й запускає eval‑тести, щоб інструменти не «конкурували» між собою за увагу моделі. Режим read‑only і його помірне, але відчутне використання (близько 17 відсотків користувачів) показують, що навіть прості режими доступу можуть стати важливими для підприємств — за умови, що клієнти навчаться їх коректно відображати.
Усе це разом формує практичний урок для всіх, хто будує власні MCP‑сервери або інші інтерфейси для агентів: кількість інструментів, їхня структура, обсяг описів і відповідей, а також те, де саме реалізується складна логіка — у моделі чи на сервері — безпосередньо визначають якість і вартість системи. MCP‑поверхня — це не просто список API‑ендпойнтів, а ретельно спроєктований шар взаємодії між людиною, агентом і платформою.
Джерело
Lessons from Scaling GitHub’s Remote MCP Server — Sam Morrow, GitHub