--- title: "MCP, nebo CLI? Špatná otázka. Ptejte se, kde žije stav." description: "Tobi Lütke říká, že spor MCP versus CLI se vede na špatné vrstvě: obojí funguje, jakmile stav přetrvá mezi kroky. Souhlas. U synchronizace jsou tímto stavem vlastní záznamy integrace, ne halda REPL, a proto MCP nástroje Tajo neuchovávají v relaci nic." url: https://tajo.io/cz/blog/mcp-or-cli-is-the-wrong-question/ markdown: https://tajo.io/cz/blog/mcp-or-cli-is-the-wrong-question.md lang: cs-CZ author: "Set Noa" author_url: https://tajo.io/cz/set-noa/ published: 2026-11-04 updated: 2026-11-05 alternates: {en-US: /blog/mcp-or-cli-is-the-wrong-question.md, bg-BG: /bg/blog/mcp-or-cli-is-the-wrong-question.md, de-DE: /de/blog/mcp-or-cli-is-the-wrong-question.md, da-DK: /dk/blog/mcp-or-cli-is-the-wrong-question.md, es-ES: /es/blog/mcp-or-cli-is-the-wrong-question.md, fr-FR: /fr/blog/mcp-or-cli-is-the-wrong-question.md, el-GR: /gr/blog/mcp-or-cli-is-the-wrong-question.md, hi-IN: /hi/blog/mcp-or-cli-is-the-wrong-question.md, id-ID: /in/blog/mcp-or-cli-is-the-wrong-question.md, hr-HR: /hr/blog/mcp-or-cli-is-the-wrong-question.md, hu-HU: /hu/blog/mcp-or-cli-is-the-wrong-question.md, it-IT: /it/blog/mcp-or-cli-is-the-wrong-question.md, ja-JP: /jp/blog/mcp-or-cli-is-the-wrong-question.md, ko-KR: /kr/blog/mcp-or-cli-is-the-wrong-question.md, ar-SA: /ar/blog/mcp-or-cli-is-the-wrong-question.md, nl-NL: /nl/blog/mcp-or-cli-is-the-wrong-question.md, no-NO: /no/blog/mcp-or-cli-is-the-wrong-question.md, pl-PL: /pl/blog/mcp-or-cli-is-the-wrong-question.md, pt-BR: /pt/blog/mcp-or-cli-is-the-wrong-question.md, ro-RO: /ro/blog/mcp-or-cli-is-the-wrong-question.md, ru-RU: /ru/blog/mcp-or-cli-is-the-wrong-question.md, sv-SE: /se/blog/mcp-or-cli-is-the-wrong-question.md, zh-CN: /zh-cn/blog/mcp-or-cli-is-the-wrong-question.md, sl-SI: /sl/blog/mcp-or-cli-is-the-wrong-question.md, sr-Latn-RS: /sr/blog/mcp-or-cli-is-the-wrong-question.md, th-TH: /th/blog/mcp-or-cli-is-the-wrong-question.md, tr-TR: /tr/blog/mcp-or-cli-is-the-wrong-question.md, ur-PK: /ur/blog/mcp-or-cli-is-the-wrong-question.md, vi-VN: /vi/blog/mcp-or-cli-is-the-wrong-question.md, sk-SK: /sk/blog/mcp-or-cli-is-the-wrong-question.md} --- [AI agenti](https://tajo.io/cz/blog/?category=ai-agents) # MCP, nebo CLI? Špatná otázka. Ptejte se, kde žije stav. Tobi Lütke říká, že spor MCP versus CLI se vede na špatné vrstvě: obojí funguje, jakmile stav přetrvá mezi kroky. Souhlas. U synchronizace jsou tímto stavem vlastní záznamy integrace, ne halda REPL, a proto MCP nástroje Tajo neuchovávají v relaci nic. mcp vs cli Má AI agent používat MCP, nebo CLI? Lütke má pravdu, že MCP versus CLI je špatná vrstva: obojí funguje, jakmile stav přetrvá mezi kroky, a bash vyhrává jen proto, že tím stavem je souborový systém. U synchronizace ale stav není halda REPL. Jsou to vlastní záznamy integrace: kurzor, čekající návrh, zámek (lease), plán. Proto MCP nástroje Tajo neuchovávají v relaci nic: jakýkoli agent z jakéhokoli klienta pokračuje ze záznamů. Tajo dnes nespouští žádný zákaznický kód a nemá REPL, a níže to říkáme na rovinu. [Zjistit více](https://tajo.io/cz/blog/mcp-or-cli-is-the-wrong-question/#vrstva-kterou-m%C3%A1-na-mysli) Dne 21. září 2026 v 00:33 UTC zveřejnil Tobi Lütke tohle: „MCP vs CLI pro LLM je špatná diskuse. Lidé se přou na špatné vrstvě.“ Pak [23. října](https://x.com/tobi/status/2113596638899974567) upozornil na nový repozitář [dquickts](https://github.com/stencil-hq/dquickts). Je to fork QuickJS, který dokáže pozastavit program uprostřed smyčky `for`, zapsat celou jeho haldu do bajtů a obnovit ho v jiném procesu. „Výborné prostředí pro code mode,“ napsal. Pokud jde o vrstvu, má pravdu. Chci s ním nejdřív souhlasit, jeho vlastními slovy, a pak tvrzení zúžit tak, aby říkalo něco, co může využít synchronizace. ## Vrstva, kterou má na mysli Tady je argument tak, jak ho formuloval, což je jediný férový způsob, jak citovat argument, který se chystám ohnout: > Obojí funguje neuvěřitelně dobře, pokud to běží v prostředí podobném REPL, které dokáže uchovávat stav. Na CLI je vtipné, že k nástrojům CLI se obvykle přistupuje přes BASH, který je shodou okolností REPL s perzistentním stavem (souborovým systémem), a proto CLI funguje mnohem lépe než MCP. Ale to zdaleka není vnitřní vlastnost MCP. Znamená to jen, že potřebujeme lepší běhová prostředí. To je správně a vysvětluje to pozorování, které učinila spousta lidí, aniž by ho vysvětlili. Agent, který dostane CLI, zapíše soubor, o tři kroky později ho načte zpět, prohledá ho grepem, pošle ho rourou dál. Agent, který dostane holý MCP server, dostane na každé volání jeden výsledek a vše ostatní musí nést ve svém kontextovém okně. CLI nevyhrálo protokolem. Vyhrálo proto, že bash přišel s místem, kam věci odložit. Jeho sázka z toho vyplývá. Někdo postaví vložitelný engine ve stylu SQLite, který z bashe, TypeScriptu nebo volání nástrojů udělá jeden plán, zkontrolovaný před spuštěním a postavený pro trvalé (durable) provádění. dquickts je krok tímto směrem. [Jeho README](https://github.com/stencil-hq/dquickts) popisuje REPL, „jehož funkce a proměnné přežijí restarty“. Popisuje také trvalé volání hostitele: „skript zavolá funkci hostitele, jejíž odpověď dorazí za několik hodin. Proces skript uloží a ukončí se.“ Zatím plná shoda. Teď to zúžení. ## Který stav a pro jakou práci „Uchovávat stav“ skrývá otázku: čí stav a v jaké podobě? Pro programovacího agenta je stavem repozitář a shell a REPL, který přežije restarty, je dobrá odpověď. Pro agenta, který staví synchronizaci mezi dvěma SaaS systémy, je stav, který potřebuje mezi kroky, už daný samotnou prací. Nesou ho čtyři záznamy a žádný z nich není proměnná ve skriptu. **Kurzor.** Synchronizace čte zdroj po oknech a musí vědět, kde skončilo poslední okno. V synchronizačním enginu Tajo je to [uložený kurzor](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor) pro každou synchronizaci a rozsah, zapsaný po každé dávce bez jediného neúspěšného záznamu, a další běh na něj navazuje. Plánovaný běh si uloží svůj výchozí bod dřív, než udělá cokoli jiného, takže když první běh selže, další čte ze stejného místa. Princip, na kterém to stojí, posílat rozdíl a nikdy celou tabulku, najdete ve [vysvětlení reverse ETL](https://tajo.io/cz/blog/what-is-reverse-etl/). Kurzor tam nechám. **Čekající návrh.** V MCP nástrojích konektorů Tajo je zápis dvojice volání. `brevo_propose` ověří vstup vůči deklarované akci a zaznamená návrh. Nic se neodešle. Výsledek nese id návrhu a, když musí rozhodnout člověk, stránku, kde ho schválí. `brevo_apply` provede schválené zápisy daného připojení v pořadí a zastaví se u prvního, který stále čeká na člověka. Záznam mezi tím je ten stav. Obsahuje vstup a jeho digest, takže schválený zápis nelze upravit mezi rozhodnutím a provedením. Neobsahuje hodnoty z odpovědi poskytovatele, protože záznam o schválení, do kterého se jen přidává, se nesmí změnit v úložiště osobních údajů. **Zámek (lease).** Běh synchronizace drží po celou dobu svého trvání jeden [výhradní zámek](https://tajo.io/cz/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease) s tokenem vlastníka, časovým limitem standardně patnáct minut a obnovováním. Zastaralý vlastník nemůže uvolnit novější zámek. Pokud je úložiště zámků nedostupné, běh odmítne začít, místo aby hádal. Který worker běh drží, je fakt uložený v zámku, ne v paměti nějakého procesu. **Plán.** `syncs.dryRun` načte z kurzoru další okno, pro každý záznam určí vložení, aktualizaci, smazání nebo beze změny a zapíše přesně jeden řádek: plán, uchovaný jednu hodinu. Neposune žádný kurzor a nic nezapíše do žádného z obou systémů. `syncs.apply` zapíše tento plán jednou. Odmítne, pokud se kurzor posunul, nebo pokud se mezitím změnil větší než tolerovaný podíl záznamů. Opakované volání vrátí první výsledek, místo aby zapisovalo znovu. To je stav mezi kroky: čtyři záznamy s id, čitelné pro každého agenta, který je smí vidět. ## Proč strana MCP nic nedrží v relaci Jakmile je stav v záznamech, relace už nemá co držet. Proto MCP endpointy Tajo žádnou relaci nedrží. Každý požadavek dostane nový server a transport bez id relace. Čtení je jeden požadavek na volání, s omezenou velikostí výsledků, aby jedna odpověď nemohla zahltit tah. Zápisy jsou návrh, pak provedení, a to, co nesete dál, je id návrhu. Protokol se posunul stejným směrem. [Revize specifikace MCP z 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/changelog) odstranila z transportu Streamable HTTP relace na úrovni protokolu i hlavičku `Mcp-Session-Id`. Server, který potřebuje kontinuitu, si teď vytvoří vlastní identifikátor a dostane ho zpět jako běžný argument. Přesně tím je id návrhu. [Co je MCP server](https://tajo.io/cz/blog/what-is-an-mcp-server/) popisuje tuto revizi a to, jak se volání nástroje liší od trvalé synchronizace; tento text se týká jen toho, kam patří stav. Důsledek je ten, na kterém u integrační práce záleží. Řekněme, že agent v Claude Code navrhne zápis a jeho relace skončí. Člověk ho o hodinu později schválí. Agent v jiném klientovi, nebo ten samý zítra, zavolá apply s id a zápis proběhne, jednou. Spadlý agent ztratí své kontextové okno a nic jiného. Nic nebylo pozastaveno, takže nic nebylo třeba obnovovat. ## Co nemáme a co to stojí Poctivá námitka přichází ze strany REPL a zní takto: „Dobře, vaše záznamy přežijí. Ale každé volání znovu čte to, co předchozí volání už mělo. Skript by kontakty načetl jednou, spojil je, vyfiltroval a vrátil číslo. Váš agent udělá pět volání a za každé zaplatí.“ Ta námitka má pravdu, pokud jde o mechanismus, a cenu jsme nezměřili. Vyhodnocení, které by počítalo volání na úlohu s přenášeným stavem a bez něj, není postavené. Dokud nebude, tvrzení, že režim volání stojí víc tokenů, zůstává nezodpovězené. Tři další věci je třeba říct na rovinu, protože čtenář, který dočte tento článek, by si je neměl domýšlet: - **Dnes neběží žádný kód napsaný zákazníky.** Čtení přes konektory je jeden požadavek na volání, bez sandboxu v cestě. V našem stacku existuje spouštěč kódu a je to interní nástroj. V produkci je vypnutý, pokud nejsou nastaveny dva samostatné příznaky, a odpovídá pouze administrátorům. Každé volání dostane nový kontext, vazby, které povolují jen čtení, a rozpočet dvou sekund pro synchronní kód. Jeho vlastní hlavička velkými písmeny uvádí, že je hranicí správnosti, ne bezpečnosti. - **Žádný REPL.** Nic, co agent spočítá v jednom volání, není k dispozici v dalším, pokud to nebylo zapsáno jako záznam s id. - **Žádná perzistentní relace agenta.** Klient si drží svou konverzaci. Tajo drží návrhy, plány, kurzory a zámky. Žádná třetí věc neexistuje. ## K čemu je trvalý engine Nic z toho není argument proti dquickts. Jeho README vyjmenovává, k čemu jsou snapshoty, a ten seznam je dobrý. Uspat nečinný skript a uvolnit jeho paměť. Spouštět dlouhý výpočet po částech na kterémkoli volném workeru. Teple startovat každou instanci ze snapshotu místo opakování přípravy. Odstavit skript na volání hostitele, jehož odpověď dorazí později. Pro pracovní prostor programovacího agenta nebo notebook, který má přežít restart, je to správný nástroj. Synchronizace by na něm přesto záviset neměla, ze tří důvodů, které mi dává samo README. Za prvé: „Soubor relace se načte jen do sestavení qjs, které ho zapsalo.“ Halda zapsaná jednou verzí enginu je po upgradu mrtvý soubor; kurzor je řetězec. Za druhé: „Snapshoty jsou důvěryhodný vstup, stejně jako bajtkód“ a „škodlivé snapshoty se nedetekují“. Uloženou haldu musíte chránit, zkontrolovat ji nemůžete; návrh je řádek, který si člověk přečte, než ho schválí. Za třetí, snapshot obsahuje vše, co skript přečetl, včetně záznamů zákazníků. Záznamy popsané výše jsou postavené obráceně: plán ukládá digesty, ne hodnoty, a záznam návrhu nikdy neukládá odpověď poskytovatele. Jedno z pravidel, podle kterých stavíme, říká, že deterministické vítězí nad chytrým. Halda, která pokračuje uprostřed smyčky, je chytrá. Kurzor, návrh, zámek a plán jsou nudné, dají se prohlédnout a jsou stejné na každém enginu, v každém klientovi, po každém pádu. Lütke položil správnou otázku. Kde žije stav? U synchronizace odpověď nikdy nemohla být v procesu. Vždy musela být v záznamech, protože právě tam ho musí umět přečíst člověk, který zápis schvaluje. ## Často Kladené Otázky **Je pro AI agenty lepší MCP, nebo CLI?** Samo o sobě ani jedno. Postřeh Tobiho Lütkeho z 21. září 2026 platí: obojí funguje, jakmile volání běží přes něco, co mezi kroky uchovává stav. CLI dnes působí lépe, protože bash uchovává stav v souborovém systému. Rozdíl není v protokolu, ale v běhovém prostředí. **Jaký stav potřebuje agent mezi kroky synchronizace?** Vlastní záznamy integrace: kurzor, který říká, kde skončil poslední běh, návrh čekající na schválení člověkem, zámek (lease), který říká, který worker běh drží, a plán z dry runu, kterému musí provedení odpovídat. Nic z toho není proměnná ve skriptu. Jsou to řádky s id. **Proč MCP server Tajo neuchovává v relaci nic?** Každý požadavek dostane nový server a transport bez id relace. Cokoli potřebuje další volání, je záznam: id návrhu, id plánu, kurzor. Druhý agent v jiném klientovi tak může navázat tam, kde první skončil, a spadlý agent ztratí jen své kontextové okno. **Spouští Tajo kód napsaný agenty?** Pro zákazníky ne. Čtení přes nástroje konektorů je jeden požadavek na volání, bez sandboxu. Spouštěč kódu, který existuje, je interní nástroj za dvěma příznaky, dostupný jen administrátorům, s vazbami pouze pro čtení a novým kontextem pro každé volání. Sám o sobě uvádí, že není bezpečnostní hranicí. Neexistuje žádný REPL ani perzistentní relace. **K čemu je dobrý trvalý JavaScriptový engine, jako je dquickts?** Jeho README uvádí použití: uspat nečinný skript, rozdělit dlouhý výpočet mezi workery, teple nastartovat ze snapshotu a odstavit skript na volání hostitele, jehož odpověď dorazí za několik hodin. To vše je reálné. Synchronizace by na něm přesto záviset neměla: snapshot se načte jen do sestavení enginu, které ho zapsalo, pro recenzenta je neprůhledný a obsahuje veškerá zákaznická data, která skript přečetl. ## Související články ### [Odpověď je správná. Cesta k ní je chybná.](https://tajo.io/cz/blog/the-answer-is-right-the-path-is-wrong/) 8\. 10. 2026 · 3 min čtení 3 sekce ### [Co logovat u každého volání nástroje MCP](https://tajo.io/cz/blog/what-to-log-for-every-mcp-tool-call/) 6\. 11. 2026 · 7 min čtení 6 sekcí ### [Co je MCP server? Jak fungují MCP a MCP UI v roce 2026](https://tajo.io/cz/blog/what-is-an-mcp-server/) 3\. 10. 2026 · 13 min čtení Krok 1 → Krok 6