Asynchronní vstup od člověka pro kódovací agenty

Aktualizováno: 15. 9. 2026

MCP elicitation se ptá toho, kdo agenta právě řídí, ve stejné session. Odpověď od klienta, který u toho není, potřebuje místo toho asynchronní kanál.

Mezera: elicitation je synchronní a jen v rámci session

MCP požadavek elicitation/create (součást stabilní specifikace 2025-06-18) umožňuje serveru požádat připojeného klienta o strukturovanou informaci uprostřed volání, zanořeně do právě běžícího nástroje. Klient musí při inicializaci deklarovat capability elicitation a odpověď se vrací jako jedna ze tří akcí — accept s odeslanými daty, decline, nebo cancel. Průběh zpráv ve specifikaci je jeden okruh tam a zpět: server se zeptá, klient ukáže rozhraní člověku, který je před ním, ten člověk odpoví, klient odpoví serveru a původní volání pokračuje.

Tenhle tvar je přesně správný na „potvrď mi tohle, než budu pokračovat" nebo „kterou ze tří možností chceš" — otázky, na které člověk řídící agenta odpoví během pár vteřin, aniž by opustil terminál. Je to špatný tvar pro otázku mířenou na někoho, kdo v session vůbec není. Workflow na sběr podkladů od klienta — „než budeš pokračovat ve stavbě, potřebuješ klientovo logo, úvodní text a přihlášení do CMS" — potřebuje odpověď od majitele firmy, který nikdy neotevřel Claude Code a žádné rozhraní, které MCP klient vykreslí, neuvidí. Elicitation k téhle osobě nemá žádnou cestu — dosáhne jen na toho, kdo je na druhém konci aktuálního spojení.

Specifikace k tomu přidává ještě druhou, ostřejší hranici: „Servers MUST NOT use elicitation to request sensitive information" (servery NESMÍ elicitation použít k žádosti o citlivé informace). To vylučuje žádat o heslo nebo API klíč přes elicitation i ve chvíli, kdy je v session správný člověk — další důvod, proč sběr přihlašovacích údajů potřebuje vlastní mechanismus, ne jen větší elicitation prompt.

Tasks: trvanlivé a pollovatelné, ale pořád stejný klient

Rozšíření Tasks stojí za přesné pojmenování: je to experimentální, opt-in rozšíření jádra MCP (dokumentované v repozitáři ext-tasks), ne ratifikovaná součást základní specifikace, a vyžaduje, aby si klient i server podporu explicitně vyjednali — skutečná podpora se liší klient od klienta. Tam, kde se použije, řeší reálný kus skládačky: místo blokování spojení po dobu dlouho běžící operace server vrátí rovnou trvanlivé taskId, volající pak polluje tasks/get (nebo se přihlásí k odběru notifications/tasks), a pokud úloha uprostřed potřebuje vstup, přejde do stavu input_required, který se vyřeší přes tasks/update.

Tím získáte dvě věci, které samotná elicitation nedává: handle, který přežije výpadek spojení, a úlohu, která může ve stavu input_required čekat tak dlouho, jak potřebuje, místo aby držela spojení otevřené. Co tím nezískáte, je způsob, jak oslovit někoho mimo MCP session. Stav input_required pořád řeší ten, kdo obsluhuje stejný připojený klient — člověk schvalující deployment v nástroji, který už používá. Klient, který nikdy MCP klienta nenainstaloval a nenainstaluje, přes tasks/update pořád není dosažitelný, ze stejného důvodu, proč ho nedosáhne ani elicitation: oba mechanismy se vyřeší uvnitř spojení klient-server, ne mimo něj.

Co je opravdu potřeba k oslovení třetí strany

Získat odpověď od někoho, kdo v session není, vyžaduje tři věci, které samotná elicitation ani Tasks nedávají:

Kanál, který funguje bez MCP klienta — e-mail, odkaz, webový formulář. Člověka je potřeba oslovit způsobem, jakým je dosažitelný už teď, ne způsobem, jakým je dosažitelný váš agent.
Stav, který přežije jeden požadavek — něco, co si agent může zkontrolovat znovu za minuty, hodiny nebo dny, protože odpověď nepřijde v příštích pár vteřinách.
Urgování — způsob, jak člověka připomenout znovu, pokud neodpoví, protože jeden e-mail poslaný jednou se snadno přehlédne nebo zapomene.

Tohle je otázka na úrovni produktu, ne protokolu — MCP definuje, jak server mluví s klientem, ne jak se operátor klienta dostane k třetí straně, která žádného klienta vůbec nemá.

Vzor s BriefGate

Nástroje BriefGate přes MCP jsou postavené přesně na tuhle mezeru. Postup:

define_intake vytvoří požadavek — seznam položek (text, soubory, nebo type: "secret" pro přihlašovací údaje) — a klientovi pošle e-mailem odkaz na portál. Klient ho vyplní z telefonu nebo notebooku; žádný účet, žádný MCP klient, žádný software k instalaci.
get_intake_status je levná, synchronní kontrola: kolik položek už dorazilo, které ještě čekají, kdy klient naposledy otevřel portál. Zavolat ho je normální krok ve smyčce agenta, ne chybová cesta.
manage_webhook zaregistruje HTTPS endpoint, takže proces agenta dostane notifikaci ve chvíli, kdy se něco změní (item.submitted, intake.completed, intake.stalled a další), místo aby polloval na základě odhadu.
get_intake_results vyzvedne typovaná, odeslaná data, jakmile dorazí — včetně jednorázového odhalení u položek typu secret, protože přihlašovací údaje v žádném z předchozích kroků neputují v čitelné podobě.

Odpověď na define_intake obsahuje blok follow_up, který pojmenuje, která ze dvou strategií kontroly se hodí: "recommended": "webhook", pokud už aktivní endpoint pokrývá relevantní eventy, nebo "schedule" s konkrétním every_hours a until časovým razítkem, když ne. Agent nemusí hádat, jak často se má vracet — API to řekne přímo.

Urgování je vyřešené stejně, jako by to dělal člověk, jen bez té části, kde člověk zapomene: chase_schedule na define_intake (gentle, default, aggressive, nebo vlastní interval) posílá připomínkové e-maily automaticky, dokud klient nedokončí, nebo dokud intake nezůstane trčet — v tu chvíli se spustí intake.stalled s konkrétním seznamem missing_items, které ještě chybí.

Jak by se měl agent chovat, zatímco čeká

Chování, které stojí za osvojení: stav „čeká se" je normální odpověď, ne selhání. Agent, který zavolá get_intake_status a dostane {"status": "in_progress", "progress": {"submitted": 2, "total": 5}}, se dozvěděl něco užitečného — tři položky ještě chybí — a měl by to prostě nahlásit a pokračovat v čemkoliv jiném, co může dělat, místo aby to zkoušel dokola v těsné smyčce nebo bral nedokončený stav jako chybu.

Konkrétně:

Pokud je zaregistrovaný webhook, vůbec nepollujte — pokračujte ve stavbě (nebo v jiné práci), dokud nepřijde notifikace, a pak na ni zareagujte.
Pokud webhook zaregistrovaný není, řiďte se intervalem z follow_up.schedule, ne vlastní vymyšlenou frekvencí.
Nikdy nenahrazujte elicitation prompt otázkou mířenou na klienta. Pokud odpověď nemá dát ten, kdo agenta řídí, patří ta otázka do define_intake, ne do elicitation/create.
Nikdy nežádejte o přihlašovací údaje přes elicitation nebo chatovou zprávu — trezor na secrets existuje přesně proto, že první specifikace zakazuje a druhé v e-mailu zanechá trvalou kopii.
Při intake.stalled nepokračujte v tichém pollování — dejte to najevo, protože chase engine už vyčerpal vlastní pokusy a teď je potřeba, aby zasáhl člověk jiným kanálem.

Zkráceně: elicitation odpovídá na „co chce člověk přede mnou právě teď" a — tam, kde ho podporuje klient i server — Tasks odpovídá na „jak nedržet spojení blokované, zatímco ten samý člověk přemýšlí." Ani jedno neodpovídá na „co chce klient, který tu není" — a to je záměrně samostatný, asynchronní kanál.