Jaký je rozdíl mezi CLI a MCP?

Rozdíl mezi CLI a MCP není v tom, který nástroj je modernější. CLI je příkazové rozhraní konkrétního programu, MCP komunikační protokol pro AI aplikace. Ukážeme rozdíl na práci s úkoly, porovnáme spotřebu tokenů i nároky na integraci a rozebereme, kdy použít příkaz, kdy MCP server a kdy obojí propojit.

CLI ovládá program pomocí konkrétních příkazů

Command-line interface je rozhraní, kterému předáváte příkazy a argumenty. Používá ho člověk v terminálu, automatizační skript i AI agent. CLI není totéž co terminál: terminál zprostředkovává práci, zatímco konkrétní program určuje dostupné příkazy a jejich význam.

Například GitHub CLI umí vypsat úkoly, vytvořit pull request nebo spustit workflow. Část operací přitom provádí přes vzdálené API. Příkazová řádka tedy neznamená, že vše běží pouze lokálně nebo že program nepotřebuje připojení k síti.

Pro automatizaci je důležité, zda příkaz nabízí strojově čitelný výstup, předvídatelné návratové kódy a neinteraktivní režim. Parsovat barevnou tabulku určenou člověku je křehké. JSON a dokumentované argumenty dovolují sestavit spolehlivý skript, který žádný jazykový model nepotřebuje.

AI agent ale CLI použije jen tam, kde má k dispozici shell, tedy v nástrojích jako Claude Code, Codex CLI nebo Cursor. Rozšířené programy typu git nebo gh modely znají z trénovacích dat, u neznámého si přečtou výstup přepínače --help. V chatu v prohlížeči ani ve firemním asistentovi pro netechnické kolegy terminál není, takže tam CLI nepomůže.

MCP sjednocuje přístup AI aplikací k nástrojům

Model Context Protocol definuje komunikaci mezi klientem a serverem. Hostitelská AI aplikace spravuje klienta, který se připojuje k MCP serveru. Samotný jazykový model nemusí rozumět síťovému protokolu: aplikace mu zpřístupní popisy nástrojů a zprostředkuje jejich volání.

Protokol představil Anthropic 25. 11. 2024 jako otevřený standard. Od 9. 12. 2025 ho spravuje Agentic AI Foundation pod Linux Foundation, kterou spoluzaložily Anthropic, Block a OpenAI. Podle oficiálního blogu MCP k tomu datu existovalo přes 10 000 aktivních serverů.

MCP není jen vzdálené spouštění příkazů. Na straně serveru rozlišuje 3 základní primitivy, které poskytují operace, data a šablony interakcí. Konkrétní server nemusí podporovat všechny; jeho schopnosti se zjišťují během komunikace s klientem.

• Tools: volatelné operace, například vyhledání úkolu nebo vytvoření záznamu.

• Resources: dostupný kontext, například obsah dokumentu nebo aplikační data.

• Prompts: znovupoužitelné šablony zpráv a interakcí, které server nabízí klientovi.

Přínosem je společný způsob integrace, ne automaticky chytřejší model. Kompatibilní klient zjistí nabídku nástrojů a jejich vstupní schémata bez ručně psané integrace každého příkazu, a vzdálený MCP server funguje i tam, kde žádný terminál není. Klient však musí podporovat příslušný transport a funkce serveru; kompatibilita není bezpodmínečná.

Srovnání rozhraní: co skutečně rozhoduje při volbě

Rozdíl mezi CLI a MCP nejlépe vystihuje způsob obsluhy a integrace. Obě cesty mohou nakonec provést stejnou operaci nad stejnými daty. Rozhoduje, kdo operaci vyvolává, kde běží, jak zjistí její parametry a kde kontrolujete oprávnění.

Pro pevně daný export bývá hotové CLI přímočařejší cesta. U asistenta, který má podle zadání vybírat z firemních operací, dává MCP smysl jako sjednocující vrstva. Univerzální cenový ani rychlostní vítěz neexistuje: provoz serveru může přidat práci, ale sdílená integrace ji může jinde ušetřit.

Technicky: stejný seznam úkolů dvěma cestami

V CLI voláte konkrétní program. Následující příkaz potřebuje nainstalované a přihlášené GitHub CLI; spusťte ho v adresáři repozitáře propojeného s GitHubem. Vyžádá nejvýše 20 otevřených úkolů a vrátí pouze jejich čísla a názvy v JSON.

gh issue list --state open --limit 20 --json number,title

U MCP klient zjistí dostupné nástroje a jejich vstupní schémata přes tools/list a potom odešle požadavek tools/call. Níže je ilustrace pro hypotetický server: název list_issues ani jeho argumenty nejsou standardem MCP.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "list_issues",
    "arguments": {
      "repository": "firma/projekt",
      "state": "open",
      "limit": 20
    }
  }
}

Příklad ukazuje zprávu, nikoli kompletní relaci. MCP používá JSON-RPC 2.0 a aktuální revize specifikace 2026-07-28 je bezstavová: verzi protokolu a schopnosti klienta nese každý požadavek v poli _meta, které jsme pro přehlednost vynechali, a úvodní handshake initialize odpadl. Standardní transporty jsou dva, stdio a Streamable HTTP. První propojuje lokální procesy, druhý posílá každou zprávu jako HTTP POST na endpoint vzdáleného serveru.

Rozdíl tedy není „text proti JSON“. Také CLI může vracet JSON a MCP nástroj může vrátit text. Podstatné je, že MCP standardizuje obálku komunikace, objevování nástrojů a popis jejich vstupů. Význam jednotlivých operací dál určuje konkrétní server.

Spotřebuje MCP víc tokenů než CLI?

Tohle je nejčastější argument pro CLI a ještě v roce 2025 platil. MCP klienti posílali modelu definice všech nástrojů hned na začátku konverzace. Podle měření Anthropicu zabralo 58 nástrojů z pěti serverů zhruba 55 000 tokenů ještě před první zprávou; samotný GitHub přidal 35 nástrojů a asi 26 000 tokenů.

Řešení přišlo na straně klientů. Odložené načítání (tool search) pošle modelu jen názvy nástrojů a definice dohledá, až je potřebuje: ve stejném příkladu to ušetřilo 85 % kontextu. Claude Code ho zapíná ve výchozím stavu. Jiný postup nechá model napsat kód, který nástroje volá v izolovaném prostředí, takže mezivýsledky modelem vůbec neprocházejí.

Nezávislý test Checkly z července 2026 uzavírá, že mezi CLI a MCP už dnes velký rozdíl ve spotřebě není. Microsoft přesto v dokumentaci Playwright doporučuje CLI pro coding agenty a MCP pro dlouhé smyčky, které opakovaně pracují se stavem stránky. Tokeny tedy o volbě nerozhodují; rozhoduje prostředí a uživatel.

MCP server může využít existující CLI uvnitř

Obě technologie lze skládat. MCP server může nabídnout úzce vymezený nástroj a uvnitř spustit zavedené CLI. Klient nemusí znát syntaxi příkazu a vývojář nemusí znovu implementovat komunikaci s cílovou službou. Server ale přebírá odpovědnost za bezpečný překlad požadavku.

Takový obal musí hlídat verzi programu, dostupnost přihlášení, časový limit i chybové výstupy. Argumenty předávejte jako oddělené hodnoty, nikoli slepováním příkazu pro shell. Pokud podkladový nástroj čeká na interaktivní potvrzení, automatizace může zůstat viset místo vrácení chyby.

MCP zároveň není podmínkou přístupu AI k nástrojům. Agent může spouštět příkazy přes funkci hostitelské aplikace. Výhodou MCP je především standardizované propojení s dalšími klienty. Jak takový server navrhnout, ukazuje článek o vlastním MCP serveru v Laravelu, praktické scénáře nad úkoly pak využití Jira MCP ve vývoji.

Bezpečnost určuje rozsah práv, nikoli zkratka

MCP není bezpečnostní sandbox. Server s administrátorským přístupem může napáchat škodu stejně jako CLI spuštěné s příliš širokými právy. Rozhodující je, které operace zpřístupníte, pod jakou identitou běží a zda cílová služba opravdu kontroluje oprávnění.

Specifikace MCP ale řeší dvě věci, které CLI nechává na vás. Hostitel má před voláním nástroje získat souhlas uživatele a vzdálený server autorizuje přes OAuth 2.1: token musí být vydaný právě pro daný server a rozsah práv určují scopes. Příkaz v CLI naopak běží s plnými právy účtu, pod kterým agent pracuje, a s jeho lokálními přihlašovacími údaji.

Ani správné vstupní schéma nezaručuje správný záměr. Model může vybrat jiný záznam, než uživatel zamýšlel, nebo následovat škodlivé instrukce z načteného dokumentu. Obsah nástroje je nedůvěryhodný vstup, ne oprávnění rozšířit přístup či obejít potvrzení změny.

• Oddělte čtení od zápisu a přidělujte pouze nezbytná oprávnění.

• Před nevratnou operací zobrazte uživateli konkrétní cíl a rozsah změny.

• Validujte argumenty na serveru a omezte povolené příkazy i cílové systémy.

• Nastavte časové limity, limity výsledků a auditní záznamy bez tajných údajů.

• Otestujte zamítnutý přístup, neplatné vstupy a opakované doručení požadavku.

U zápisových operací řešte také idempotenci. Po výpadku nemusí klient vědět, zda se změna provedla; opakování pak může založit duplicitní úkol nebo objednávku. MCP samo tuto vlastnost obchodní operaci nepřidá a stejný problém vzniká při opakovaném spuštění CLI.

Kdy použít CLI a kdy MCP?

Nejdřív popište operaci, její vstupy a povolené následky. Rozhodující otázka pak zní, kdo bude nástroj používat a kde. Samotná přítomnost AI v projektu není důvod provozovat další server.

Pilot postavte na operaci pouze pro čtení a porovnejte správnost výsledků, obsluhu chyb a nároky na údržbu. Počítejte také s instalací klientů, správou přístupů a aktualizacemi integrace. Funkční demonstrace nestačí: provoz musí zvládnout i výpadek služby a odebraná oprávnění.

Pokud provozujete produkt, se kterým mají pracovat AI asistenti vašich zákazníků, je MCP server rozhraní, které jim dáváte, podobně jako dřív API. Takový server jsme postavili pro e-shopovou platformu SHOPZI, jejíž obchod lze řídit i z Claude nebo jiného AI asistenta.

CLI poskytuje příkazy, MCP společný protokol pro nástroje a kontext. Dobrá architektura nemusí jednu cestu zavrhnout: může zachovat osvědčené skripty a zpřístupnit vybrané operace přes MCP. Výsledkem má být méně integrační práce a kontrolovatelná automatizace, ne další vrstva bez jasného užitku.