Afina MCP - 7 реальних сценаріїв автоматизації

П'ятниця, 23:00. Скрипт реєстрації Bybit впав на 34 з 50 акаунтів. Логи - 800 рядків. Завтра о 9:00 відкривається Launchpad. Раніше це означало: сидіти, гортати, шукати помилку, вносити правки, перезапускати. Зараз я написав три речення в чат - і пішов спати.

Агент прочитав логи, знайшов причину (таймаут 5 секунд замість потрібних 15-ти), виправив скрипт, перевірив 4 акаунти з проблемними проксі і надіслав мені підсумок. О 23:14 вже все було готово.

Ось про це і поговоримо в статті.

Що таке MCP і як агент «бачить» Afina - 3 хвилини теорії

Перша наша стаття розповідала, що таке MCP-сервер, а детальний гайд з MCP-сервера показує, як його налаштувати. Тут - тільки те, що потрібно розуміти перед практикою.

MCP - це не плагін і не боткоманди. Це API, через який AI-агент (Claude, GPT або будь-який інший) взаємодіє з Afina так само, як ти - тільки без мишки. Він може читати списки акаунтів, створювати скрипти, запускати перевірку проксі, оновлювати модулі. Все, що ти робиш руками в інтерфейсі - агент робить через API-виклики.

Що агент реально може:

• Читати: акаунти, скрипти, логи, модулі, проксі, бази даних, змінні
• Писати: створювати і редагувати скрипти, акаунти, модулі, групи задач
• Запускати: скрипти на акаунтах, браузерні сесії, перевірку проксі
• Аналізувати: логи помилок, стан проксі, структуру скриптів
• Виправляти: параметри скриптів, код модулів, призначення проксі

Що агент не може: бачити зашифровані паролі та API-ключі. Він бачить їхні назви і метадані, але не значення. Це навмисне обмеження - твої секрети залишаються секретами навіть від агента.

Як Afina піднімає MCP-сервер і як підключити до нього агента

Що відбувається при запуску Afina

Коли ти запускаєш Afina - вона автоматично піднімає локальний HTTP REST API сервер. Нічого додатково налаштовувати не потрібно: сервер стартує разом з додатком і слухає на порту 50778. Якщо порт зайнятий - Afina автоматично займає наступний вільний у діапазоні 50778–50787.

Цей сервер і є точкою входу для агента. Доки Afina запущена - API доступний.

Що таке afina-mcp і звідки він береться

afina-mcp - це окремий npm-пакет, який не входить до Afina. Це посередник між агентом і Afina API. Ти запускаєш його через npx прямо з командного рядка - він завантажується автоматично.

Схема взаємодії:

• Claude надсилає afina-mcp JSON-RPC виклик через stdin: {"method":"tools/call","params":{"name":"list_accounts"}}
• afina-mcp транслює його в HTTP-запит до Afina з заголовком x-api-key
• Afina повертає дані → afina-mcp → Claude отримує відповідь

afina-mcp не зберігає стан і не веде логи. Він живе рівно стільки, скільки триває сесія Claude.

Що агент бачить через MCP

Коли сервер підключений, у Claude з'являється 92 інструменти. Кілька прикладів з реального підключення:

• list_accounts - повний список профілів: id, назва, проксі, теги, групи, статус isRunning
• start_browser / stop_browser - запуск і зупинка браузерної сесії для конкретного профілю
• run_script / get_run_logs - запуск скрипта і читання логів виконання
• create_module / update_module - написання і оновлення JS-модулів (файли зберігаються на диску в data/modules/{UUID}/)
• check_all_proxies - масова перевірка всіх проксі з оновленням статусів у базі
• create_task_group / start_task_group - планування і запуск груп задач

Агент не бачить зашифровані паролі і токени - лише метадані. Твої секрети захищені навіть від агента.

Майстер-промпт для підключення

Скопіюй промпт нижче, встав свій API-ключ і надішли в будь-якому Claude-клієнті (Claude Code, Claude Desktop, Cursor, Cline). Агент виконає всі кроки сам:

Налаштуй підключення до Afina MCP сервера. Мій API-ключ Afina: [ВСТАВИТИ_КЛЮЧ] Afina запущена, сервер доступний на http://localhost:50778 Зроби наступне: 1. Виконай команду: claude mcp add afina --scope project -e AFINA_API_KEY=[ВСТАВИТИ_КЛЮЧ] -e AFINA_URL=http://localhost:50778 -- npx -y afina-mcp 2. Додай рядок .mcp.json до файлу .gitignore (або створи його, якщо не існує). 3. Перевір підключення: claude mcp list Якщо бачиш "afina: npx -y afina-mcp - ✓ Connected" - підключення успішне. 4. Нагадай мені перезапустити Claude Code - MCP-інструменти завантажуються тільки при старті нової сесії. Якщо Node.js не встановлено або Afina не запущена - повідом про це окремо.

Хочеш підключити Afina до всіх своїх проектів одразу? Заміни --scope project на --scope user - і MCP стане доступним глобально.

Що потрібно перед відправкою промпту:

Сім незалежних кейсів з Afina MCP

Без хронології і без теорії. Сім реальних задач - конкретні промпти, конкретні результати. Кожен кейс - автономний.

Перевірка проксі: живі чи мертві

Пул 20 проксі. Деякі активності відпрацювали, деякі Proxy іноді «відпадають», деякі просто туплять. Перед запуском нової активності потрібно знати стан пулу проксі і прибрати нежиттєздатне без ручного перебирання.

Раніше: відкрити список проксі, запустити масову перевірку, почекати, вручну переглянути результати, знайти і видалити мертві.

Зараз - один запит:

Перевір усі проксі в Afina. Скільки живих, скільки мертвих? Покажи список мертвих - я їх видалю.

Агент відповідає:

«Перевірку завершено. Із 20 проксі: 18 живих, 2 не відповідають. Мертві: 91.211.33.62, 64.7.251.207.

Результат: точний список живих і мертвих за секунди. Видалення мертвих - два кліки вручну в Afina UI. Раз

200 профілів з гео-розбивкою і тирами - один промпт

Підготовка до нової активності. 200 акаунтів: унікальні назви, правильні проксі за гео, відповідні таймзони і мови, чотири групи по тирам.

Раніше: 200 разів відкривати форму, вводити параметри, обирати проксі, зберігати. Кілька годин роботи.

Зараз:

Створи 200 акаунтів з такими налаштуваннями: Назви: ACC1 до ACC200 Розбивка по гео і тирам: - ACC1–50: проксі з групи "pl-proxies", таймзона Europe/Warsaw, мова: English - Tier 1 - ACC51–100: проксі з групи "de-proxies", таймзона Europe/Berlin, мова: English - Tier 2 - ACC101–150: проксі з групи "ua-proxies", таймзона Europe/Kyiv, мова: Ukrainian - Tier 3 - ACC151–200: проксі з групи "ua-proxies", таймзона Europe/Kyiv, мова: Ukrainian - Tier 4 Створи чотири групи: "Tier 1", "Tier 2", "Tier 3", "Tier 4". Поклади відповідні 50 акаунтів у кожну. Перед збереженням покажи перші 5 акаунтів кожного тиру - я підтверджу.

Агент:

«Підготував 200 акаунтів. Перші 5 по тиру: Tier 1 → ACC1 (pl.x.x.1, Europe/Warsaw, en) … ACC5 Tier 2 → ACC51 (de.x.x.1, Europe/Berlin, en) … ACC55 Tier 3 → ACC101 (ua.x.x.1, Europe/Kyiv, uk) … ACC105 Tier 4 → ACC151 (ua.x.x.51, Europe/Kyiv, uk) … ACC155 Підтверджуєш?»

Ти відповідаєш «так» - і за кілька хвилин всі 200 профілів є в системі, розподілені по групах з правильними параметрами.

Запускаємо активність: групи задач

Профілі є - час запускати скрипт. Активність "Bybit promo" на першій сотні акаунтів, паралельно по 10, добове вікно 09:00–15:00, через групи задач.

Створи групу задач "Bybit promo" для акаунтів ACC1 до ACC100. Запускай по 10 акаунтів паралельно. Повторна спроба при помилці: 1 раз. Вікно запуску: 09:00–15:00 щодня. Таймаут на один скрипт: 30 хвилин. Рандомізуй порядок акаунтів при кожному запуску.

За лаштунками агент налаштовує точні параметри групи: timeFrom: "09:00", timeTo: "15:00", activeSession: 10, timeout: 30, repeatCount: 1, isRepeatable: true. Це ті самі поля, які в інтерфейсі розкидані по вкладках - агент виставляє їх за один запит, рандомізація вмикається через параметр shuffle.

Щось впало. Агент, розберися

Перша партія відпрацювала. Відкриваєш телефон - купа сповіщень про помилки. 34 з 50 акаунтів впали. Причина невідома.

Раніше: відкривати логи кожного акаунта по черзі, гортати сотні рядків, шукати патерн, вносити правки.

Зараз - три кроки:

Крок 1. Читаємо логи:

Прочитай логи групи задач "Bybit promo". Скільки задач завершились з помилкою? Що за помилки і на яких кроках? Згрупуй по типу.

Агент:

«34 задачі впали. Розбивка по типах:

• 30 акаунтів - крок "Очікування капча-кнопки", помилка: element not found (timeout 5000ms). Причина: таймаут занадто короткий для завантаження Bybit Puzzle.
• 4 акаунти - помилка мережі: proxy connection refused. Це проксі, не скрипт.»

Крок 2. Виправляємо скрипт:

Виправ таймаут у скрипті Bybit Registration з 5000 до 15000ms для кроку "Очікування капча-кнопки".

Агент знаходить потрібний блок у JSON-структурі скрипта і змінює параметр. Підтверджує: «Таймаут оновлено. 5000 → 15000ms».

Крок 3. Розбираємось з проксі:

Знайди 4 акаунти, що впали з помилкою proxy connection refused. Перевір їхні проксі.

Агент:

«Акаунти: ACC7, ACC19, ACC34, ACC41. Перевірив проксі - всі 4 не відповідають. Хочеш призначити нові з групи "pl-proxies"?»

Так, призначи нові унікальні.

Діагностика + виправлення + заміна проксі - 5 хвилин, три природніх запити. Раніше це займало годину мінімум.

Telegram-дебаг: щоб помилки більше не падали мовчки

Таймаут виправили. Але наступного разу може виникнути щось інше - і знову доведеться гортати логи. Правильне рішення: налаштувати Telegram-сповіщення на кожну червону гілку скрипта, щоб кожна помилка приходила в чат одразу.

У скрипті «Bybit Registration» 15 червоних гілок - шляхів помилки. Вручну додати Telegram-блок до кожної - це кілька годин.

Відкрий скрипт "Bybit Registration". Знайди всі червоні (error) гілки - тобто блоки, які ведуть по шляху помилки. До кожної червоної гілки додай блок відправки в Telegram з таким шаблоном повідомлення: #️⃣ | Bybit Registration ℹ️ | 🔴 Помилка 🐛 | Крок: {назва блоку} 📋 | {деталь помилки} 👤 | Акаунт: ${accountName}

Агент читає структуру скрипта, знаходить усі 15 червоних з'єднань і вставляє блоки з правильними параметрами. Кожен блок знає, на якому кроці виникла помилка - назва і деталь беруться з контексту виконання.

Тепер кожна помилка в кожному акаунті приходить у чат - зі скриптом, кроком і ім'ям акаунта. Нічого не падає мовчки.

API змінився. Оновлюємо модуль і не ламаємо підпис

Сервіс розв'язання капчі змінив ендпоінт API. Модуль GEETEST MODULE (або твій кастомний captcha_solver) перестав працювати. Всі скрипти, що його використовують, падають.

Чому модулі - це не просто JS-файли

Перш ніж розповісти, як агент це вирішує - важливий технічний нюанс, який відрізняє Afina від «просто запустити файл».

Кожен JS-модуль в Afina підписаний криптографічним алгоритмом Ed25519 на основі MD5-хешу всіх файлів модуля - index.js, package.json, settings.json. Якщо будь-який файл змінити в обхід системи - підпис стає недійсним, і виконавець скриптів видасть помилку signature_invalid. Жоден скрипт не запустить модуль без актуального підпису.

Це захист від несанкціонованих змін: навіть якщо хтось отримає доступ до диска і правитиме код напряму - підпис зламається і модуль заблокується.

Після кожного легітимного оновлення коду потрібно обов'язково зробити resign - перерахувати підпис під новий стан файлів. Без resign - модуль заблокований.

Агент знає про це і виконує resign автоматично. Це ключовий момент.

Оновіть модуль captcha_solver - 2captcha змінив ендпоінт. Старий: api.2captcha.com/in.php Новий: api.2captcha.com/createTask Після оновлення - одразу resign.

Агент:

1. Відкриває код модуля - читає index.js
2. Знаходить старий ендпоінт, замінює на новий
3. Викликає resign_module - перераховує підпис під оновлений стан файлів
4. Підтверджує: «Ендпоінт оновлено, resign виконано. Усі скрипти, що використовують цей модуль, тепер запускатимуться з новим API.»

Написати модуль з нуля - теж через агента

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

Напиши JS-модуль "2captcha_geetest_solver": - Що робить: відправляє Geetest-капчу на розв'язання через 2captcha і повертає токен - Поля налаштувань: apiKey (рядок, обов'язкове) - Вхідні параметри: imageBase64 (рядок) - Документація: 2captcha.com/api-docs Розберися з форматом запитів за документацією. Після створення - resign.

Агент читає документацію, визначає правильні ендпоінти і формат запитів, пише index.js з повною логікою, settings.json з описом параметрів, package.json із залежностями - потім create_module і resign_module. Модуль з'являється в бібліотеці і його можна підключати до будь-якого скрипта через блок executeModule.

Аудит бібліотеки модулів

Якщо модулів накопичилося багато - агент допомагає навести порядок:

Покажи всі модулі. Є серед них застарілі версії або ті, що не використовуються в жодному скрипті?

Агент переглядає список і порівнює хеші модулів з їхніми викликами у скриптах. Знаходить «мертві» версії - ті, що залишились після оновлень.

WebRTC не працює. Розбираємось через агента

Клієнт скаржиться: «У мене WebRTC не вмикається в Afina». Проксі начебто SOCKS5 з UDP від DataImpulse - але на browserleaks.com/webrtc показує проблему.

Як насправді працює WebRTC в Afina

WebRTC, QUIC і WebTransport вмикаються автоматично, якщо SOCKS5-проксі реально підтримує UDP-тунелювання. Жодного ручного перемикача немає - система сама визначає можливості проксі.

Проблема в іншому: багато провайдерів жилих проксі заявляють підтримку UDP, але реально UDP-трафік не тунелюється коректно. Ознака: на browserleaks.com/webrtc WebRTC Public IP не збігається з Remote IP - це leak.

Перевірити це вручну для 200 акаунтів нереально. З MCP - один запит:

Перевір усі проксі в групі "Main". Для кожного вкажи: статус (живий/мертвий), підтримка UDP, країна, затримка. Покажи окремо ті, де UDP не підтверджений.

Агент викликає check_all_proxies і повертає структурований звіт:

«Із 60 проксі в групі "Main": 58 живих. З них UDP підтверджено у 38, не підтверджено у 20. Список без UDP: [87.x.x.x, 91.x.x.x, …]»

Акаунти з групи "Main", що мають проксі без UDP - перемісти в групу "no-udp-proxies". Призначи їм проксі зі списку "datacenter-udp".

Агент перебирає акаунти, перевіряє їхні поточні проксі, переміщає тих, кому потрібна заміна, і призначає нові без дублювань.

Практичний висновок: жилі UDP-проксі (зокрема DataImpulse) часто не дають справжнього UDP-тунелювання. Датацентрові SOCKS5+UDP (наприклад, ProxyWing) стабільніші для WebRTC/QUIC. Twilio Network Test буває ненадійний - може показувати помилку UDP там, де ProxyWing-тест проходить чисто.

RabbyWallet: перевірка балансу на п'яти акаунтах без скрипта

Потрібно швидко перевірити баланс RabbyWallet на 5 акаунтах. Одноразово, без написання скрипта.

Вирішення - AI-сесія в браузері:

Відкрий по черзі акаунти ACC1, ACC2, ACC3, ACC4, ACC5. Для кожного: 1. Запусти браузер 2. Відкрий розширення RabbyWallet 3. Розблокуй гаманець - використай змінну пароля rabby_pass 4. Прочитай загальний баланс у доларах і зафіксуй 5. Закрий браузер Після всіх п'яти - виведи підсумкову таблицю: акаунт → баланс.

Агент виконує:

1. start_browser - запускає ACC1 з його fingerprint, проксі, cookie
2. Відкриває RabbyWallet через розширення
3. Використовує значення змінної rabby_pass для розблокування гаманця
4. get_page_text - читає текст панелі гаманця
5. Знаходить баланс і зберігає
6. stop_browser - закриває сесію
7. Повторює для ACC2–5

Агент:

«Готово. Баланси: ACC1 - $34.76 браузер закрито.»

Жодного скрипта, жодного коду. Просто розмова.

OKX Boost: перевірити поточні активності

Аналогічний сценарій - але тепер потрібно не баланс, а список активностей на платформі:

Відкрий профіль ACC101. Зайди на okx.com/boost. Знайди всі активні завдання та активності на сторінці. Зроби скріншот і поверни мені список: назва активності, умова, термін дії. Закрий браузер.

Агент запускає браузер, завантажує сторінку OKX Boost, читає її вміст через get_page_text, робить take_screenshot - і повертає структурований список:

«На OKX Boost зараз активні:

1. Web3 Task Marathon - 3 завдання, нагорода: 10 OKB за кожне, до 20 червня
2. Invitation Bonus - за реферала +20 OKB, безстроково
3. Liquidity Mining Campaign - мінімальний депозит $100, APY до 18%, до 30 червня Скріншот додано.»

Якщо щось пішло не так - агент не мовчить: «З'явилось модальне вікно верифікації - ось що побачив браузер», і передає скріншот для аналізу.

Бонус: міграція профілів за 5 хвилин

Якщо ти переходиш в Afina з іншого антидетект-браузера - агент переносить усі профілі автоматично.

Імпортуй усі профілі з Dolphin Anty в Afina. Поклади в групу "migrated-dolphin-june". Після міграції - перевір проксі кожного профілю і відзнач ті, що не проходять перевірку.

Агент підключається до Dolphin API, отримує повний список профілів, переносить по одному, запускає перевірку проксі і повертає звіт:

«148 профілів перенесено успішно. 2 - помилка парсингу cookie (файл пошкоджений). 12 мають непрацюючі проксі - їх я позначив тегом "proxy-error". Показати список?»

Підтримується міграція з:

• AdsPower - через adspower_import_profiles
• Dolphin Anty - через dolphin_import_profiles
• Vision - через vision_import_profiles

А якщо треба перенести авторизовану сесію - без повторного логіну:

Експортуй куки з поточної вкладки Chrome і встанови їх для акаунта ACC101.

Профіль відкривається вже авторизованим.

Порівняння: як це було і як стало

З чого почати прямо зараз - 5 дій на 5 хвилин

Якщо MCP-сервер вже підключений і ти ще не пробував нічого з цього - ось найшвидший старт:

1. Перевір проксі - напиши в чат: «Перевір усі проксі в Afina і скажи, скільки живих і мертвих». Це безпечно і відразу показує, як це працює.

2. Прочитай логи - знайди будь-яку групу задач і напиши: «Прочитай логи останнього запуску і скажи, що пішло не так».

3. Подивись на скрипт - напиши: «Покажи список скриптів і для одного з них поясни, що він робить». Агент читає структуру і пояснює логіку.

4. Аудит модулів - напиши: «Покажи всі модулі. Є серед них дублікати?».

5. Разова AI-сесія - запусти профіль і попроси агента щось знайти на сторінці. Без скрипта, без коду - просто розмова.