Стендап Сьогодні
📢
Канал в Telegram @stendap_sogodni
🦣
@stendap_sogodni@shevtsov.me в Федиверсі
Пости з тегом #ПомічникШІ
15.01.2026
Розширення можливостей помічника ШІ засобами MCP
Нарешті я дістався до MCP. Довгий час вІдкладав, бо це виглядало достатньо складно. Плюс, мені більш-менш вистачало того, що агент здатний досягнути з одними лише командами оболонки. Але, підійшов вдалий момент.
Для тих, хто не знає, MCP (Model Context Protocol) - це спосіб дати агенту ШІ нові інструменти. Типовий агент з коробки вміє редагувати файли, виконувати команди оболонки та шукати в інтернеті. А шляхом MCP до нього можна додати буквально будь-які функції.
Для того нам потрібний сервер MCP. Це допоміжна програма, яка спілкується з оболонкою агента пакетами JSON. Оболонка запускає сервер, забирає з нього набір доступних дій, та робить доступними для агентів. А коли агент звертається до певної дії, передає команди сервера MCP та той їх виконує. Сервер MCP є звичайною програмою та отримує доступ до локальних ресурсів — наприклад, може прочитати файл конфігурації. Також сервер запускається надовго, а значить, може мати власний стан — чи навіть підключення до інших сервісів.
Все це звучить помірно цікаво, якщо мова йде про загальні MCP. Ну може, такий, що вміє надсилати пошту. Ще й з чужим кодом всередині.
Але ось моя головна думка тут: не обовʼязково шукати чийсь незрозумілий MCP. Ти завжди можеш згенерувати собі свій, під конкретні обставини та задачі. Так, я відразу кажу “згенерувати”, а не “написати”, бо писати власноруч сенсу мало. А агент цілком здатний згенерувати MCP за твоїми вимогами.
Мій приклад такий: хотілося мати консоль Rails на стейджингу. Тоді значно спрощується перевірка невидимих частин логіки, бо агент може це робити власноруч. (Ба більше, оскільки він знає код проєкту, то що писати в консоль, теж добре розуміє.) Отже, згенерував MCP, який і знає, як на стейджинг потрапити, і де взяти ключі. Зручно надзвичайно.
23.01.2026
Як я робив MCP для Jira
ОК, ще більше заглиблююся в переконанні, що власні, доморощені MCP підіймають роботу з агентом до наступного рівня ефективності.
Вчора треба було почистити беклог в Jira. Я вже не раз писав про свої спроби щось там оптимізувати. Найкращим поки підходом був набір збережених запитів JQL - мої відкриті задачі, задачі, що очікують тощо. Мені залишалося пройтися по нім та опрацювати.
Але навіть так, робота з Jira залишалася нудним та неприємним обовʼязком. Тому (і це починає бути патерном), відкриваю Cursor і кажу: ось в мене є acli, давай, проаналізуй все що мене стосується.
Він поколупав документацію до acli всілякими викликами acli jira --help і так далі. Потім витягнув десь ті ж самі результати, що і я раніше. Але різниця в тому, що LLM на ходу може згрупувати ці результати, оформити, та робити над ними дії. Так, перше, що я зробив — це сказав “переведи все, що в Ready for Release понад місяць, у Closed”. (Інфраструктурні задачі самі не закриваються.) І оце вже дійсно потужно!
Поробив ще трохи, а потім кажу — ми тут розібралися, як працювати з Jira через acli, збережімо інструкцію в файл. (Це дуже корисний хід, часто так роблю.) А потім думаю… ну якщо вже інструкція є — зроби з неї кілька команд. То й зробив на кшталт /jira-my-tasks і так далі.
От сиджу сьогодні з тими командами, але річ у тім, що команди (наскільки я знаю) запускаються явно мною, а не агентом в процесі інших операцій. Тож, нарешті, кажу “а тепер — роби з команд MCP!” Ну то й він зробив малесенький MCP на Python, який вміє робити ті самі виклики acli.
І тепер, нарешті, я можу писати складні запити, як-от “створи для цього чату задачу у відповідному епіку”. Та агент здатний перелічити епіки, знайти той, що найбільше має сенс, та вкласти в нього задачу. Круть! А якщо мені щось не подобається, я можу швидко внести зміни простим текстом.
Ще тут висновок. LLM найкраще розкриваються там, де багато контексту, складна послідовність дій. Поки ти робиш одиничні зміни — може так виглядати, що LLM це зайве ускладнення, та, певно, так воно і є. Тому раджу пробувати задачі вищого порядку — сміливіше!