A2A Inspector у моєму application і MCP до нього¶
Коли вперше виникає потреба у дебагу A2A взаємодії, зазвичай у пошуку спливає офіційний інспектор від a2aproject: ставиш, вводиш URL, дивишся картку агента, пишеш у чат і підглядаєш сирий JSON-RPC збоку. Це нормальний інструмент. Він не знає нічого про твій репозиторій, і це фіча: підключився до будь-якого хоста в інтернеті й клацаєш.
Навіщо потрібен інспектор¶
A2A не просто «ще один REST». Є Agent Card (хто я, які skills, куди стукатися), і є JSON-RPC на кшталт tasks/submit / tasks/status. Помилка в картці, дубль skill id, битий URL, не той agent у skill, і зовнішній клієнт або IDE вже не розуміють, що відбувається. Помилка в тілі запиту, 400, порожня відповідь, таск завис «десь там», а ти гадаєш, це мережа, auth чи роутинг на не той graph.
Інспектор скорочує цей цикл: подивився картку так, як її реально віддає сервер, а не як ти пам’ятаєш з вчорашнього коміту; кинув тестовий виклик і одразу бачиш сирий JSON, без п’яти шарів абстракції в коді додатку. Це зручно, коли підключаєш новий skill, міняєш бекенд, порівнюєш staging і локалхост, або пояснюєш колезі «ось який контракт зараз живе». Інспектор не «красивий дашборд заради дашборду». Це інструмент зворотного зв’язку по протоколу: швидко з’ясувати, де зламалося, на оголошенні можливостей чи на виконанні таску.
У Expert Memory Machine я пішов іншим шляхом не тому, що «мій крутіший», а тому що вже сиджу всередині одного бекенду з купою LangGraph-агентів і своїх MCP. Окремий додаток з іншого репо постійно роз’їжджався б з тим, що реально крутиться у application. Тому інспектор у мене зібраний як шматок інтерфейсу плюс stdio-сервер для Cursor. MCP я тримаю не для того, щоб «розмовляти з агентом по A2A як у чаті», а щоб тестувати A2A з IDE: картка, submit, status, валідація, без ручного curl і з можливістю підключити асистента до цих кроків. А в інтерфейсі application дивись, яка штука: ти не стрибаєш між «продукт» і «тул для протоколу», а бачиш на одному екрані, хто взагалі існує в langgraph.json, хто висить на A2A, а хто живе через threads.
Як це працює у браузері для людини¶
У центрі карта на React Flow. Зліва умовний браузер, посередині вузол «A2A JSON-RPC», праворуч твої graphs. Якщо агент реально винесений у A2A, стрілка йде з центру на нього і ще анімується. Якщо ні, пунктир «threads» з клієнта напряму, і це одразу видно, без читання конфігів. Клік по вузлу вибирає агента в списку. Коли жмеш tasks/submit і все відпрацювало, ребро до відповідного graph на пару секунд підсвічується, якщо skillId вдалося зіставити з відомим id. Це не частина специфікації A2A, це просто підказка очима: «ось сюди пішов запит».
Нижче картки skills з Agent Card і блок «Spec check». Він чесно мінімальний: обов’язкові поля, унікальність id у skills. Повної JSON Schema під кожну версію протоколу там немає, і не варто видавати це за гарантію. Якщо spec розшириться, правила треба буде підтягнути руками.
Є ще маленький playground: taskId, skillId, текст повідомлення (у мене часто це просто JSON-рядок для task manager). Дві кнопки, submit і status, б’ють у POST /api/a2a/tasks. Зручно перевірити «чи бекенд взагалі відповідає», не відкриваючи Postman. Debug console збирає сирі рядки (що пішло, що прийшло, помилки); Journal, те саме, тільки відповіді інколи ріжуться по довжині, щоб екран не перетворився на стіну JSON. Для важкого дебагу все одно доведеться дивитися логи сервера або знову взяти офіційний інспектор проти зовнішнього URL, тут я б не брехав.
Скріншоти¶
MCP, коли вже сидиш у IDE, чи тестуєш сценарій через агента який не "вміє" a2a¶
Тут головний сценарій простий: через MCP ганяєш A2A як тести й швидкі перевірки, локально, на staging, після зміни картки чи роутера. Це не заміна продуктового чату з агентом; це шар «подзвонити в endpoint і подивитися відповідь».
П’ять tools, по суті: забрати картку з /.well-known/agent.json, відправити tasks/submit, запитати tasks/status, прогнати валідацію по сирому JSON картки, зібрати короткий Markdown-звіт (картка + валідація). Для регресій і дебагу інтеграції цього зазвичай достатньо; агент у Cursor може сам пройти ланцюжок «картка → submit → status», якби ти диктував кроки колезі. Але тут є проблема: це звичайний HTTP-клієнт. Довгий SSE-стрим або вся магія сокетів у реальному runtime цими tools не показуються, для того лишаються логи бекенду, playground у application або офіційний інспектор.
Порівняння з офіційним інспектором¶
Офіційний інспектор заточений під людину: ввів URL чужого сервера, поговорив, подивився консоль. Мій заточений під людину вже всередині EMM і під LLM через MCP. Тому «краще» залежить від задачі.
Не потрібно тримати в голові мапу skill → graph. Той самий X-API-Key, ті самі роутери, що й в application, менше сюрпризів типу «в інспекторі працює, у додатку ні». Діаграма client → A2A → agents у офіційного UI просто не про це, там немає твого langgraph.json у полі зору.
Якщо ж треба швидко підключитися до чужого A2A в хмарі, репозиторій a2a-inspector з docker run і портом 8080 часто простіше. Не треба збирати весь frontend. Чат і бокова консоль у тому ж інструменті можуть бути зручнішими для «чистого» протокольного експерименту, коли тобі байдуже на graphs.
Офіційний інспектор є універсальним браузерним клієнтом до будь-якого URL; мій є частиною application і MCP під мою монорепу. Вони не обов’язково конкурують; інколи варто тримати обидва.
Що не варто очікувати¶
Валідація картки лишається легкою. Playground шле один тип повідомлення, усі кутові випадки протоколу ти все одно ловиш тестами або зовнішнім клієнтом.