MCP vysvětleno: Jak funguje Model Context Protocol

LLM už nějakou dobu umí volat nástroje, ale Model Context Protocol (MCP) přináší strukturovaný, standardizovaný způsob, jak to dělat.

Stále ale není jasné, co MCP ve skutečnosti je.

Mnoho lidí předpokládá, že MCP je aplikace, API nebo nějaký nástroj, ale není to ani jedno z toho. Je to protokol, a to znamená něco velmi konkrétního.

Pojďme si to rozebrat.

Pokud chceš jen vidět, co MCP umožňuje v praxi, podívej se na toto krátké video:

Co je protokol?

Protokol je jednoduše sada pravidel, která určují, jak spolu komunikují dva nebo více systémů.

Sám o sobě nic nedělá. Jen definuje strukturu a očekávání konverzace mezi dvěma entitami. Můžeš si ho představit jako sdílený jazyk s přísnými gramatickými pravidly, který počítače dodržují při výměně informací.

Podobně fungují poštovní systémy. Všechny pošty v dané zemi používají standardizovaný formát adresy pro posílání dopisů.

Nebo si ho představ jako USB-C pro AI nástroje. Před dvaceti lety byl trh zaplaven různými typy nabíjecích a datových kabelů. Podobně měly AI ekosystémy několik způsobů, jak předávat nástroje jazykovým modelům. Frameworky jako LangChain, Haystack a Pydantic AI si všechny definovaly vlastní formáty pro integraci nástrojů, což znamenalo, že pokud chtěl vývojář napsat sadu nástrojů pro Google Maps, musel to udělat pro každou konkrétní technologii.

Aby to bylo konkrétnější, podívejme se na nejpopulárnější protokol, HTTP (Hypertext Transfer Protocol), který pohání weby. HTTP mimo jiné definuje, jak prohlížeč (klient) žádá webový server o stránku a jak má server odpovědět.

Tady je příklad cyklu HTTP požadavek-odpověď:

1. Prohlížeč odešle HTTP požadavek

Když do prohlížeče zadáš https://example.com, prohlížeč odešle webovému serveru strukturovaný HTTP požadavek:

Tady jsou HTTP parametry a hodnoty použité v našem příkladu:

"GET" – Toto je akce (požadavek na webovou stránku).
"/index.html" – Konkrétní webová stránka, která je požadována.
"HTTP/1.1" – Verze používaného protokolu.
"Host: example.com" – Doménové jméno webu.
"User-Agent: Mozilla/5.0" – Informace o prohlížeči, který požadavek odesílá.

Webový server ví, jak tento požadavek interpretovat, protože HTTP tento formát standardizuje. Rozumí tomuto „jazyku“.

2. Server odpoví pomocí protokolu HTTP

Server požadavek zpracuje a odešle zpět strukturovanou HTTP odpověď:

"HTTP/1.1 200 OK" – Kód odpovědi (200 znamená úspěch).
"Content-Type: text/html" – Typ obsahu, který se odesílá zpět.
"Content-Length: 512" – Velikost odpovědi.
HTML Content – Skutečný obsah webové stránky (je tam jen nadpis „Welcome to Example.com“)

Důležité: HTTP samo o sobě webové stránky neukládá ani je nezobrazuje. Jen definuje pravidla pro to, jak spolu mohou webové prohlížeče a webové servery komunikovat. Jakýkoli systém, který tato pravidla dodržuje, může komunikovat přes internet definovaný protokolem HTTP.

Jak MCP funguje jako protokol

Teď stejný způsob uvažování použijme na MCP (Model Context Protocol).

MCP je protokol, který umožňuje AI agentům komunikovat s externími nástroji a datovými zdroji. Stejně jako HTTP neukládá data ani sám nespouští úlohy. Jednoduše definuje standardizovaný způsob, jak může AI žádat nástroje o informace a získávat je.

Možná se ptáš, co jsou tyto „nástroje“.

V kontextu LLM jsou nástroje externí systémy, API nebo služby, se kterými může AI interagovat a rozšířit tak své možnosti nad rámec pouhého generování textu. Umožňují AI agentům získávat data v reálném čase, rezervovat schůzky nebo posílat zprávy tvým přátelům, což je dělá mnohem užitečnějšími pro potřeby v reálném světě.

Řekněme, že se AI agenta zeptáš:

„Kolik je teď hodin v Londýně?“

Protože samotná AI správnou odpověď nezná, protože AI modely mají datum omezení znalostí (říjen 2023 u modelů OpenAI), potřebuje získat aktuální data z časové služby. Místo aby pomocí HTTP žádala o webovou stránku, použije AI MCP k vyžádání časových údajů.

Proběhne toto:

1. AI agent odešle MCP požadavek časové službě (příklad)

"method": "tools.call" → AI volá externí nástroj.
"tool": "get_time" → Název nástroje, který chce použít.
"args": { "location": "London" } → Konkrétní vstupní parametry.

Stejně jako u HTTP tento požadavek dodržuje přísný formát, takže každý nástroj kompatibilní s MCP přesně ví, jak ho interpretovat.

2. Časový server MCP odpoví

Externí nástroj (časový server) dodrží pravidla odpovědi MCP a odešle zpět:

"status": "success" → Potvrzuje, že požadavek byl správně zpracován.
"result" → Obsahuje skutečná časová data.

AI agent teď může tato data vzít a sestavit skutečnou odpověď uživateli:

„Aktuální čas v Londýně je 12:20 PM (GMT).“

Shrnutí a vyjasnění nejasností:

„MCP je aplikace.“ → Ne, MCP je sada pravidel. Aby se dalo skutečně používat, potřebuješ AI software a nástroje, které MCP implementují, podobně jako aplikace Instagram potřebuje živé servery Instagramu, aby odpovídaly na HTTP požadavky a doručovaly data.

„MCP je databáze.“ → Ne, MCP neukládá data. Pomáhá AI agentům komunikovat s databázemi nebo API.

„MCP je jako API.“ → Ne tak úplně. API je konkrétní způsob interakce s jedním systémem, zatímco protokol (jako MCP nebo HTTP) definuje univerzální způsob, jak může komunikovat mnoho různých systémů. MCP je jazyk, který může AI systém použít k interakci s mnoha skutečnými API (čas, databáze, Stripe, Slack atd.).

Proč je MCP zajímavé

Teď, když víme, že MCP je standardizovaný způsob, jak AI software interaguje s externími nástroji a aplikacemi, a že MCP není API, pojďme pochopit, proč se z něj komunita AI vývojářů (včetně nás) začala těšit.

Protože MCP není API, ale umožňuje AI aplikacím pracovat se skutečnými API ve velkém měřítku, pomáhá rychleji rozjet projekty, které vyžadují připojení k mnoha externím systémům. Nástroje také dávají modelu dosah, a to, co se stalo v incidentu OpenAI Hugging Face, ukazuje, jak takový dosah vypadá, když přesáhne rámec úlohy. Aby to vývojáři dokázali, někdy museli projít celým vývojovým cyklem API integrace, ale dnes obvykle používají existující knihovny nebo open-source projekty (například dostupné na GitHubu), které poskytují potřebnou funkčnost.

Použití těchto knihoven urychlí vývoj, ale jejich správná integrace s tvým systémem (pokud není kompatibilní s implementací, kterou jsi našel na GitHubu) stále vyžaduje práci, aby nástroj fungoval s AI.

S MCP, jakmile je framework připravený, může být přidání nové integrace (řekněme integrace Google Drive) otázkou připojení k MCP serveru Google Drive pomocí několika řádků kódu. Nenarazíš na problémy s kompatibilitou, protože oba používáte stejný protokol: MCP.

Porovnejme oba přístupy, aby byly rozdíly jasnější.

Standardní integrace vs. použití Model Context Protocol (MCP)

Aby bylo srovnání konkrétní, projdeme si přidání přístupu k souborům Google Drive do AI Agenta, nejprve ručně a potom pomocí nástroje kompatibilního s MCP.

Standardní integrace

1. Najdi a přizpůsob knihovnu: Vyhledáš klienta pro Google Drive API nebo open-source projekt. Google poskytuje klientské knihovny (např. Google Drive API for Python), ty ji zahrneš do svého projektu. Stále ale musíš ověřit, že funguje v prostředí tvé AI.

2. Implementuj logiku: Napíšeš funkce například pro vyhledávání souborů nebo načtení dokumentu z Drive. Když AI něco potřebuje, musí tyto funkce zavolat. Požadavek AI převedeš do volání specifických pro Google Drive API. Po získání odpovědi od Googlu extrahuješ obsah, který předáš zpět do kontextu AI.

3. Ošetři chyby a hraniční případy: Přidáš kód pro případy jako „soubor nenalezen“, chyby oprávnění nebo limity počtu API volání. Pokud Google API vrátí chybu, zachytíš ji a možná odpovíš omluvnou zprávou nebo požádáš AI o přeformulování. Musíš také zabránit tomu, aby tvoje AI posílala příliš mnoho požadavků příliš rychle.

4. Udržuj: Pokud Google časem aktualizuje své API nebo knihovnu, musíš aktualizovat svůj kód. Pokud v knihovně najdeš chybu, možná ji budeš muset opravit nebo najít jiný zdroj. V podstatě se staneš správcem této integrace Google Drive uvnitř své AI aplikace.

Tento proces platí i pro další nástroje: chceš do své AI přidat Slack nebo databázi? Musíš celý proces zopakovat pro každý z nich.

Integrace MCP

Teď se podívejme, jak by tento proces vypadal při použití MCP.

Nejprve si definujme klíčové pojmy:

Klient – AI aplikace (ChatGPT, aplikace Claude, Quickchat AI), která navazuje spojení s jedním nebo více servery a žádá o informace nebo akce potřebné k provedení úloh zadaných uživatelem.

Server – Každý server se může připojovat k něčemu jako databáze, API (Google Drive) a definovat sadu „nástrojů“ nebo dat, které může poskytovat. V tomto případě je server program, který tyto nástroje a schopnosti zpřístupňuje klientovi (AI aplikaci).

Vývojáři, podle toho, co chtějí dělat, si mohou vybrat jednu ze stran: postavit server, který zpřístupňuje data, nebo postavit AI klienta, který umí komunikovat s libovolnými servery. Většina chce druhou možnost, ale i tak začněme serverovou stranou, abychom krok za krokem pochopili, jak MCP funguje:

• Inicializace MCP serveru. Vývojář nebo správce systému nastaví MCP server pro daný nástroj nebo datový zdroj. MCP server je obvykle jen malý program, který implementuje specifikaci MCP. Například je dostupný předpřipravený Google Drive MCP server, který umí vyhledávat a načítat dokumenty.

  Při inicializaci serveru mu dáš přístup k cílovému systému (Google Drive). Server pak zpřístupní sadu nástrojů odpovídajících akcím nebo dotazům, které umí zpracovat. V podstatě jde o API adaptér, který na jedné straně mluví MCP a na druhé straně nativní službou.

  Jakmile server běží, čeká na požadavky.

• Připojení LLM (klienta) k MCP serveru. Dále se AI aplikace (strana „klienta“) musí k tomuto serveru připojit. V praxi, pokud používáš AI platformu, která podporuje MCP (například Claude Desktop), nakonfiguruješ ji adresou nebo příkazem pro spuštění serveru. Po připojení klient naváže se serverem relaci podle MCP handshaku. Pokud používáš rozhraní Claude, uvidíš, že Claude je „connected“ k určitým MCP serverům (UI může zobrazovat dostupné konektory).

Takto to vypadá v Claude UI

• Zjištění dostupných nástrojů. Po navázání spojení je první krok zjistit, co server nabízí (někdy se to stane automaticky po připojení k serveru). MCP klient odešle na server požadavek tools/list (to je definováno v protokolu). Server odpoví seznamem svých dostupných nástrojů, u každého s detaily jako název, popis a vstupní schéma.

  Server může například odpovědět, že má k dispozici nástroje create_file(path, content), read_file(path) a search_files(query). Klient pak tyto informace zpřístupní LLM. V mnoha implementacích klient tyto popisy nástrojů naformátuje a zahrne je do kontextu modelu (například je přidá do systémového promptu: „Máš přístup k následujícím nástrojům… [seznam nástrojů]“).

Tady je systémový prompt AI spolu se zprávou uživatele, který žádá o aktuální čas

S implementovanými MCP nástroji je integrován nástroj nazvaný „get_current_time“, který AI umožňuje přístup k externímu zdroji a získání přesného času v Londýně

To znamená, že nemusíš předem promýšlet a programovat všechny potenciální akce, které by tvoje AI aplikace mohla potřebovat k dokončení nějaké úlohy. S MCP může AI za běhu zjistit všechny možné akce dotazem na MCP server a vybrat si, co je potřeba.

• Použití nástroje přes MCP. Když AI potřebuje provést akci nebo získat data, vyvolá nástroj přes MCP. Z pohledu AI (zejména u modelů jako Claude, které nativně podporují používání nástrojů) se ve svém uvažování rozhodne: „Měl bych zavolat nástroj X s těmito parametry.“ MCP klient tento záměr zachytí a odešle požadavek tools/call ve formátu MCP příslušnému serveru (MCP serveru Google Drive).

• MCP server funguje jako most. Přijme strukturovaný požadavek od AI agenta, který odpovídá MCP, namapuje ho na správný endpoint Google Drive API, přepíše požadavek na skutečné volání Google Drive API, požadavek provede, zpracuje odpověď a znovu ji přeformátuje do odpovědi odpovídající MCP, než ji odešle zpět AI agentovi.

  Stojí za zmínku, že MCP servery používají strukturovaný přístup ke zpracování chyb, což zajišťuje, že je AI Agents dokážou efektivně interpretovat a jednat podle nich.

  Řekněme, že AI Agent používá MCP nástroj k nalezení souboru v Google Drive. Pokud požadavek obsahuje neplatné ID souboru (např. řetězec o pěti znacích místo očekávaného formátu), MCP server vrátí chybovou zprávu:

  Místo toho, aby AI Agent jednoduše selhal, může tuto strukturovanou odpověď převzít a přeformulovat ji do srozumitelné zpětné vazby pro uživatele:

  “Vypadá to, že ID souboru, které jsi zadal, je příliš krátké. ID souborů Google Drive mají obvykle 28 znaků. Můžeš ho zkontrolovat a zkusit to znovu?”

  Tento přístup zajišťuje, že chyby nevedou do slepé uličky, ale stanou se příležitostí, jak AI Agent navede uživatele k úspěšnému vyřešení.

• Odpověď na otázku/požadavek uživatele. Jakmile MCP server vrátí výsledek, MCP klient předá tato data zpět AI aplikaci. Model pak výsledek zahrne do svého uvažování nebo přímo do výstupu, který generuje pro uživatele.

  Pokud uživatel požádá o vytvoření nového souboru Google Sheets, odpověď serveru (obsahující ID souboru a vygenerovaný odkaz) se předá modelu. Model pak uživateli odpoví: „Dobrá zpráva! Tvůj nový soubor Google Sheets je připravený. Najdeš ho tady: [odkaz].“

V celém tomto procesu zůstává AI pod kontrolou toku: rozhoduje, kdy zavolat nástroj a jak použít výsledek při tvorbě odpovědi. Vývojář mezitím nemusí tyto kroky ručně orchestrovat, postará se o ně MCP framework a AI model. Konečný výsledek je, že uživatel může AI položit složité otázky nebo zadat úlohy, které vyžadují externí informace či akce, a AI je může přes MCP autonomně provést a vrátit výsledek.

Výhody používání MCP

Všimni si, jak tento přístup abstrahuje mnoho detailů: klient neřešil API klíče ani stavové kódy HTTP, ty řeší MCP server.

Hlavní pointa je jednoduchost v integračním bodě: „požádáme“ o zákazníky a dostaneme je. Logika toho, jak je získat, je zapouzdřena jinde. To znamená, že vývojář pracující na straně AI nemusí psát nová HTTP volání pro každou novou akci, jen vyvolá nástroje podle názvu. Těžkou práci (autentizace, volání endpointů Google Drive, formátování odpovědi) provádí kód MCP serveru, který je znovupoužitelný a standardizovaný.

Tady je shrnutí hlavních výhod:

• Snižuje množství propojovacího kódu specifického pro API. Před MCP obvykle vyžadovalo použití externí služby AI napsání spousty „glue“ kódu: zavolání API, transformaci odpovědi do textu, který model dokáže zpracovat, následné parsování výstupu modelu, aby se případně zavolalo další API atd. S MCP velká část tohoto propojovacího kódu odpadá. Klient modelu a server řeší výměnu dat strukturovaným způsobem, takže nemusíš ručně převádět jiné formáty (jako JSON) na text nebo naopak, protokol to udělá. Také nemusíš psát logiku, která rozhoduje, kdy co zavolat. Udělá to AI (vedená popisy nástrojů a vlastním uvažováním nebo promptem).

• Znovupoužitelné, sdílené konektory místo jednorázových API wrapperů. S MCP napíšeš integraci jednou a můžeš ji znovu používat napříč mnoha projekty a AI systémy. Například můžeš vytvořit MCP server pro interní wiki své firmy. Jakákoli AI aplikace, která podporuje MCP, se může připojit k tomuto jednomu serveru a dotazovat se wiki. Nemusíš znovu implementovat „vyhledávání ve wiki“ pro každý nový AI chatbot nebo každého jiného dodavatele LLM. Tato znovupoužitelnost je posun oproti minulosti, kdy si každý tým mohl psát vlastní, mírně odlišnou integraci pro stejné API. MCP podporuje knihovnu konektorů, které lze sdílet a společně vylepšovat.

• Plug-and-play integrace s různými LLM. MCP je nezávislé na modelu. Protokol nezajímá, jestli je klient Claude, GPT-4, DeepSeek nebo jakýkoli budoucí model, pokud klient dokáže obsloužit rozhraní MCP. Pokud budeš chtít v budoucnu přejít na jiný model, můžeš to udělat bez přepisování všech integrací.

• Snazší údržba. Protože jde o otevřený standard, roste komunita, která přispívá předpřipravenými servery (pro databáze, populární API atd.), které můžeš využít místo budování od nuly. Jak integruješ více systémů, MCP pomáhá vyhnout se „špagetám“ mnoha point-to-point integrací. A nemusíš sledovat všechny aktualizace API od jiných poskytovatelů.

Stanou se API integrace zastaralými?

Tradiční API integrace i MCP mají své místo. Nejlepší přístup může záviset na povaze projektu, zkušenostech týmu a dlouhodobých cílech.

Pokud potřebuješ integrovat jen jednu nebo dvě externí služby a interakce jsou poměrně přímočaré, přímá API integrace je často nejrychlejší řešení. Pokud tvoje webová aplikace potřebuje při checkoutu jen ověřit platební token Stripe, přímé volání Stripe API je jednoduché a efektivní. Zavádět v tomto scénáři MCP by mohlo být zbytečné. Můžeš připojit AI Agenta k libovolnému zdokumentovanému REST API pomocí jedné zkontrolované HTTP Action, nebo použít integraci na jedno kliknutí, například Google Sheets pro logování leadů a požadavků na demo, bez provozování MCP serveru.

V případech, kdy potřebuješ velmi těsnou kontrolu nad požadavkem/odpovědí (kvůli ladění výkonu, speciálnímu zpracování dat nebo proprietárním protokolům), může být lepší psát přímo proti API. Tradiční integrace ti umožní použít všechny pokročilé funkce API a přesně přizpůsobit volání. Pokud má API neobvyklé požadavky nebo se chceš vyhnout jakékoli abstrakční vrstvě kvůli maximální jasnosti a kontrole, tradiční přístup je vhodný.

Konkrétní příklad toho, jak jsou MCP nástroje zpřístupněny produkčnímu AI Agentovi vedle vlastních API akcí, najdeš v tom, jak Quickchat AI Agents kombinují oba přístupy. Hlubší diskuse o tom, kdy použít MCP, jednotlivé AI Actions nebo „Generate from Text“, je v článku API pro AI Agenty: Od MCP po vlastní endpointy. Pokud si to chceš vyzkoušet sám, postupuj podle průvodce krok za krokem, jak připojit svého AI Agenta ke vzdálenému MCP serveru, aby mohl během konverzace volat živý nástroj.

Seznam dostupných MCP serverů

Pokud chceš s MCP začít, podívej se na níže uvedené adresáře MCP serverů:

• https://github.com/modelcontextprotocol/servers
• https://smithery.ai

Jeden můžeš spustit i bez psaní kódu: každý Quickchat AI Agent lze proměnit v MCP server s hostovanou URL, kterou Claude, ChatGPT a Cursor volají jako nástroj. Spojení funguje i opačným směrem: Quickchat AI Agent může jako své nástroje volat hostovaný MCP server dodavatele. Takto AI asistent pro plánování postavený na MCP serveru Calendly kontroluje skutečnou dostupnost a rezervuje schůzky z chatu, a takto Notion AI chatbot odpovídá z živého centra nápovědy a zapisuje požadavky podpory zpět do databáze Notion.

Quickchat AI také provozuje vzdálený MCP server pro tvůj vlastní účet. Připoj ho k ChatGPT, Claude, Cursor nebo Codex a můžeš odtud spravovat své AI Agents: analytiku, přepisy konverzací, aktualizace knowledge base a vytváření nových Agentů, za jediným přihlášením přes OAuth. Průvodce nastavením pro každého klienta najdeš v článku Spravuj svého AI Agenta z ChatGPT, Claude a Codex pomocí MCP.

FAQ

Funguje to jen s Claude?

MCP je nezávislé na modelu. Protokol nezajímá, jestli je klient Claude, GPT-4, lokální derivát LLaMA nebo jakýkoli budoucí model, pokud klient dokáže obsloužit rozhraní MCP. To znamená, že při vytváření integrací nástrojů nejsi uzamčený u jednoho poskytovatele AI.

Jak se MCP liší od toho, že modelu prostě předem dáme všechny informace, které potřebuje? Proč místo toho nenacpat data do promptu?

MCP se zásadně liší od naplnění promptu modelu daty, protože modelu umožňuje dynamicky získávat informace, když je potřebuje, místo aby pracoval se statickým, předem načteným promptem. Vkládání textu do promptu naráží na limity, protože AI modely mají pevné kontextové okno, což znamená, že příliš mnoho dat může způsobit ztrátu důležitých detailů, zpomalit odpovědi a zvýšit náklady na API (kvůli cenovým modelům podle tokenů, které používají dodavatelé LLM). Také poskytuje znalosti jen k jednomu okamžiku, zatímco MCP umožňuje přístup k živým externím datům v reálném čase a nechává AI provádět akce, nejen číst informace. AI s přeplněným promptem může znát detaily zákazníka, ale nebude schopná aktualizovat záznamy ani zpracovat transakce.

Co když k AI připojíme desítky nástrojů? Nepřetíží to model nebo nezpůsobí, že je bude používat špatně?

Záleží na implementaci, ale je pravda, že současné LLM mají omezení v tom, jak dobře rozlišují a vybírají z mnoha možností. Pokud modelu předložíš třeba 50 možných nástrojů, existuje riziko, že vybere nesprávný. Samotný přístup MCP tě nenutí načíst všechno najednou. Měl bys připojovat relevantní nástroje podle kontextu. Osvědčený postup je připojit jen nástroje, které jsou potřeba pro danou úlohu/doménu, a využít multiagent collaboration, tedy určitý druh směrování nástrojů nebo agenta, který nejprve rozhodne, kterou podmnožinu nástrojů zvažovat.

MCP vs Function Calling

Tradiční function calling (jak ho známe z API OpenAI nebo jiných LLM) umožňuje vývojáři definovat sadu funkcí, dát jejich definice modelu a nechat model je „volat“ podle názvu s argumenty. Byl to velký krok pro integraci AI, ale má omezení. Jeden zásadní rozdíl je v tom, kdy a jak jsou nástroje definovány. U klasického function calling musí být všechny možné funkce deklarovány předem (v době návrhu) v promptu nebo přes API. Model může volat jen tyto pevně dané funkce. V MCP jsou nástroje zjistitelné za běhu, AI se může zeptat, co je k dispozici, a dokonce získat nové nástroje uprostřed relace.

MCP vs GPT Actions & Plugins

GPT Actions/Plugins označují ekosystém OpenAI, kde jsi mohl pro ChatGPT povolit pluginy (například webový prohlížeč nebo čtečku PDF), nebo „GPTs“ (vlastní ChatGPT agenty), kteří mohou používat nástroje. Bylo to zajímavé, ale vyžadovalo to vlastní vývoj pro každý plugin a bylo to omezené na platformy OpenAI. Pokud jsi chtěl ChatGPT plugin pro nějakou úlohu, musel jsi vytvořit API a manifest a projít schválením OpenAI nebo ho alespoň ručně povolit. Každý plugin byl v podstatě silo, plugin pro počasí, plugin pro cestování atd., každý s vlastními endpointy a logikou. MCP tento koncept vylepšuje tím, že ho sjednocuje a otevírá.

MCP vs RAG (Retrieval-Augmented Generation)

Retrieval-Augmented Generation (RAG) je technika, při které je LLM doplněn externí knowledge base. RAG typicky zahrnuje vektorovou databázi nebo vyhledávací index: dotaz uživatele se použije k získání relevantních dokumentů nebo dat (pomocí sémantického vyhledávání nebo jiných metod) a tyto dokumenty jsou poskytnuty modelu jako dodatečný kontext ke „čtení“ při tvorbě odpovědi. RAG slouží k tomu, aby model dostal znalosti, které původně neměl, a je obzvlášť užitečný pro faktické otázky a odpovědi nebo doménově specifické informace. RAG je však jen pro čtení, model získává textové pasáže, ale kromě vyhledání neprovádí žádné akce.

MCP je naopak o provádění akcí nebo libovolných operací, nejen o získávání informačního kontextu. S MCP může AI dělat věci: zapisovat do databáze, poslat e-mail, spustit kód atd. Neomezuje se na získávání znalostí, může spouštět změny v externích systémech. RAG a MCP tedy v mnoha ohledech slouží různým účelům.