MCP server je malý kus softwaru, který zpřístupní jeden z vašich systémů — databázi, CRM, interní API, složku s dokumenty — AI asistentovi ve formátu, se kterým umí skutečně pracovat. Je to překladová vrstva, ne produkt. A je to přesně to, co z "naše AI umí psát e-maily" udělá "naše AI si najde poslední tři faktury zákazníka a teprve pak napíše e-mail".
Protokol, který za tím stojí — Model Context Protocol — zveřejnil Anthropic v listopadu 2024 a v prosinci 2025 ho předal Agentic AI Foundation pod Linux Foundation, s podporou AWS, Google, Microsoftu, OpenAI, Bloombergu a Cloudflare. To předání je důležitější, než zní: integrační standard, proti kterému stavíte, už není produktové rozhodnutí jednoho dodavatele.
Postavili jsme čtyři — pro vyhledávací analytiku, pro publikování obsahu, pro znalostní bázi a pro nástěnkový nástroj — a denně je používáme. Tohle je to, co bychom chtěli, aby technický ředitel věděl dřív, než jeden objedná.
Jaký problém MCP server vlastně řeší?
Před MCP byla každá integrace AI nástroje zakázková. Když měl asistent číst z vašeho ERP, někdo napsal lepicí kód pro tohohle asistenta a tohle ERP. Změna asistenta znamenala napsat to znovu. Obor skončil u problému M×N: každý model krát každý systém.
MCP to redukuje na M+N. Napíšete jeden server pro své ERP a může ho použít libovolný MCP klient — Claude, ChatGPT, Gemini, Copilot, vlastní agent, CLI nástroj. Počet integrací, které udržujete, se rovná počtu vašich systémů — ne počtu systémů krát počtu AI nástrojů, které možná vyzkoušíte.
To je celý argument a je dobrý. Vysvětluje i tempo rozšíření: podle zveřejněných čísel vyrostla stažení SDK z asi 2 milionů při startu na zhruba 97 milionů měsíčně během šestnácti měsíců, přičemž veřejně evidovaných serverů je přes 9 400.
Co je uvnitř MCP serveru?
Tři věci — a vyplatí se je rozlišovat, protože se v praxi chovají jinak.
Tools (nástroje) jsou akce, které může model zavolat: create_invoice, search_orders, send_reminder. Model sám rozhoduje, kdy a s jakými argumenty je zavolá. Tyhle jsou mocné — a nebezpečné.
Resources (zdroje) jsou obsah jen ke čtení, který si klient může vytáhnout: dokument, konfigurace, záznam. Pasivní. Taží je klient, ne model.
Prompts jsou znovupoužitelné šablony, které server nabízí uživateli — jako lomítkové příkazy nebo zkratky. Podceňované, a přitom nejlevnější způsob, jak server zpřístupnit netechnickým lidem.
Většina týmů postaví server, který je z 90 % tools, a zbytek vynechá. To je obvykle chyba — zrovna prompts jsou místo, kam zakódujete "správný způsob, jak se ptát", aby ho každé oddělení nevymýšlelo znovu.
Není to jen API s kroky navíc?
Není, a právě v tom je pointa.
API se píše pro programátorku, která četla dokumentaci, ví, který endpoint zavolat, a chyby ošetří v kódu. MCP server se píše pro model, který nečetl nic kromě vašich popisů nástrojů a za běhu se rozhodne, co a v jakém pořadí zavolá.
To mění zadání způsoby, které lidi překvapují:
| Klasické API | MCP server | |---|---| | Názvy mohou být strohé, dokumentace je jinde | Název a popis nástroje jsou dokumentace | | Vrať všechno, klient si vyfiltruje | Vrať minimum — každý token stojí peníze i pozornost | | Chyby jsou stavové kódy | Chyby musí být věty, které modelu řeknou, co dál | | Jemně dělené endpointy jsou dobrý design | Příliš mnoho nástrojů zhorší schopnost modelu vybrat správně | | Idempotence je příjemný bonus | Idempotence je bezpečnostní prvek |
Na posledních dvou řádcích ztroskotá většina prvních pokusů. Nasadili jsme server se čtyřiceti jednou nástroji a dívali se, jak model spolehlivě volí špatný. Konsolidace na devatenáct lépe pojmenovaných nástrojů vyřešila víc stížností na "kvalitu AI" než jakákoli změna promptu.
Co stojí postavit?
Pro jeden dobře vymezený interní systém s existujícím API: několik dní k funkčnímu serveru, jeden až dva týdny k něčemu, co pustíte netechnickému člověku bez dozoru. SDK (TypeScript, Python a další) řeší protokol; vy píšete definice nástrojů a autentizaci.
Náklad není ve stavbě. Je v těchto třech bodech — seřazených podle toho, jak často se podceňují:
- Autentizace a identita. Těžká otázka není, jestli server dosáhne na CRM, ale jako kdo. Server s jedním sdíleným servisním účtem právě dal každému uživateli práva toho nejprivilegovanějšího. Udělat to pořádně znamená OAuth na uživatele — a to je většina práce.
- Rozhodnout, co nezpřístupníte. Každá zápisová akce je něco, co může agent ve tři ráno udělat špatně. Servery jen pro čtení se řídí nesrovnatelně levněji a pokryjí víc případů, než lidé čekají.
- Údržba, zatímco se specifikace hýbe. Stabilní specifikace nese datum 25. listopadu 2025, další revize se čeká v polovině roku 2026 a mění transport a správu relací. Je to mladý standard pod aktivní správou. Počítejte s přepracováním.
Kde se to láme?
Prompt injection přes data. Pokud váš server vrací obsah z nedůvěryhodného zdroje — ticket podpory, příchozí e-mail, staženou stránku — můžou v něm být instrukce a model je může poslechnout. Server, který nabízí zároveň "číst příchozí poštu" a "odeslat platbu", je reálný bezpečnostní problém, ne teoretický. Oddělte čtení-z-nedůvěryhodných-zdrojů a zápis-s-následky do různých serverů s různými právy.
Příliš široké nástroje. run_sql_query se snadno postaví a nejde řídit. get_orders_for_customer(customer_id, since_date) je víc práce — a je to varianta, kterou můžete opravdu schválit.
Žádná auditní stopa. Když agent udělá chybu, první otázka zní: které volání, s jakými argumenty, jménem koho? Většina serverů na ni neumí odpovědět. Logujte každé volání s identitou uživatele ještě před spuštěním, ne až po incidentu.
Brát to jako AI projekt. Je to integrační projekt. Měli by ho vlastnit lidé, kteří vlastní podkladový systém — ne inovační tým.
Měla by ho vaše firma stavět?
Rozumný test, v tomto pořadí:
- Ptají se lidé ve firmě opakovaně na věci, kvůli kterým musí někdo něco najít v systému a přepsat? Pokud ne, končíme tady.
- Má ten systém API, nebo aspoň čitelné databáze? Pokud ne, MCP server není váš první problém.
- Umíte vyjmenovat deset otázek, na které má odpovídat? Pokud ne, rozsah se rozlije a počet nástrojů exploduje.
- Jste ochotni ho první měsíc provozovat jen pro čtení? Pokud ne, přiznejte si, že začínáte governance projekt, ne produktivitní.
Zveřejněné odhady kladou zavedení MCP serverů na zhruba 28 % firem z Fortune 500 na začátku roku 2026 — proti asi 80 %, které mají AI agenty v nějakém produkčním procesu. Zajímavá je ta mezera: většina organizací má agenty, kteří nedosáhnou na vlastní data. Právě to MCP server řeší — a proto je to jeden z mála pojmů v tomhle oboru, jehož hledanost stále roste, místo aby se ustalovala.
Časté dotazy
Patří MCP Anthropicu? Už ne. Anthropic ho vytvořil a v prosinci 2025 předal Agentic AI Foundation pod Linux Foundation. Správa běží komunitním procesem s více velkými podporovateli.
Potřebuju zvláštní server pro každý AI nástroj? Ne. O tom ten standard je — jeden server obslouží libovolného MCP kompatibilního klienta.
Může MCP server běžet celý uvnitř naší sítě? Ano. Servery mohou běžet lokálně nebo self-hosted; nic vás nenutí vystavovat je do veřejného internetu. U citlivých systémů to doporučujeme jako výchozí volbu.
Jaký je rozdíl mezi MCP serverem a AI agentem? Agent rozhoduje, co udělat. MCP server je to, kam dosáhne. Agent bez serverů umí jen mluvit; server bez agenta nedělá nic.
Vyplatí se stavět, když možná změníme dodavatele AI? To je jeden ze silnějších důvodů, proč ho postavit. Server přežije volbu modelu.
Zdroje: Specifikace Model Context Protocol · Statistiky adopce MCP 2026 · Analýza enterprise adopce. Čísla o rozšíření jsou odhady třetích stran a je třeba je brát jako orientační.