MCP servery a Claude: pět otázek, na které si odpovídáme před řádkem kódu

MCP (Model Context Protocol) je v AI newsletterech každé pondělí. Důvod je férový — Anthropic dodal standard pro věc, kterou stejně každý tým nějak lepil dohromady: kontrolovanou cestu mezi modelem a daty nebo akcemi v cizím systému. Jakmile je standard, vznikají knihovny, tutoriály, a kdokoli s Claude API klíčem staví proof of concept.

Co vidíme opakovaně: 80 % těch prototypů zaměňuje „Claude vidí mou databázi“ za „Claude s mou databází dělá něco užitečného“. Mezi tím je propast. Propojení je triviální. Užitečnost ne.

Za poslední tři měsíce jsme v Codedocku postavili několik interních MCP prototypů — pro práci s daty našich projektů, pro vlastní provozní systémy a jeden proof of concept s konkrétním klientem. První produkční nasazení rozjíždíme během několika týdnů. Z těch prototypů nám vykrystalizovala metodika o pěti otázkách, na které máme odpověď dřív, než napíšeme řádek MCP kódu.

1. Pro koho přesně to děláme?

„Pro naše uživatele“ je nepoužitelná odpověď. MCP server bez konkrétního workflow se sám nenavrhne — Claude dostane sto nástrojů a neví, který z nich kdy použít.

První otázka je vždy: vyjmenujte tři konkrétní úkoly, které má AI řešit. Ne „asistent pro náš produkt“, ale „shrne zákaznickou konverzaci a navrhne followup“ nebo „z CRM záznamu vytvoří draft nabídky v šabloně X“. Čím konkrétnější use case, tím víc se nástroje navrhnou samy.

Heuristika, na kterou jsme přišli: pokud nedokážete napsat příkladový dialog v délce tří turnů, neznáte použití dost na to, abyste uměli dobrý MCP server navrhnout. Nejdřív dialog. Teprve pak schéma.

2. Čtení první, psaní naposled

MCP protokol rozlišuje resources (věci ke čtení) a tools (akce, typicky včetně zápisu). Pokušení je namapovat oboje najednou. Nenechte se.

Pravidlo: na začátku vystavte jen resources. Nechte Claude, ať si s nimi hraje. Sledujte, co hledá, co mu chybí, kde tápe. Teprve pak přidávejte tools — a i ty jen v režimu, kde je human-in-the-loop schválení povinné.

Důvod je triviální: guardraily u LLM selhávají. Prompt injection, zmatená instrukce, halucinovaná konverzační odbočka — kterýkoli z nich přiměje model zavolat destruktivní tool v nesprávný moment. Read-only surface nemá horší dopad, než že model přečte něco, co neměl. Write surface znamená e-mail odešle špatnému člověku, fakturu vystaví nesmyslně, případně vám v databázi smaže záznam.

3. Granularita nástrojů

Tuhle otázku si lidi nekladou a pak narazí. Máte dvě krajnosti:

• Moc drobná zrna: sto tools jako getUser, getUserOrders, getOrderLineItems, … — model se ztrácí v rozhodování, schema prompt nafoukne kontextové okno a latence roste s každým tool hopem.
• Moc velká zrna: jeden tool runQuery(sql) — model má veškerou moc a nulovou kontrolu, protože SQL je Turing-complete.

Funkční střed je tematický: tool per user intent, ne per databázová tabulka. getCustomerProfileForSupport je lepší než čtyři tools, které support agent musí zřetězit. searchOrders(filters) je lepší než pět variant per filtr.

Pracovní heuristika: pokud váš nejlepší agent dělá stejnou sekvenci tří calls pětkrát za den, schovává se v ní jeden tool, který čeká na pojmenování. Slučte je.

4. Trust boundary a scope

Každý MCP server je nová autentifikační hranice. Zní to samozřejmě, v praxi se to dělá špatně. Typické selhání: MCP server běží se servisním účtem, který má admin scope. Claude zavolá tool „jménem uživatele X“, ale scope je fakticky celý systém.

Správná otázka: jakého uživatele MCP server impersonuje a jaký scope v daném okamžiku nese? V produkci musí MCP server přebírat identitu volajícího — OAuth flow, session token, per-tenant API klíč — a tool calls validují proti téhle identitě, ne proti servisnímu účtu.

Druhá věc, kterou lidi přehlíží: audit trail. Každé tool call musí mít v logu kdo-kdy-co-proč (tool name, argumenty, identita volajícího, ID konverzace). Když za půl roku přijde otázka „kdo smazal fakturu #12345“, máte na ni odpovědět rychleji než za dva dny.

5. Jak poznáme, že to funguje?

Poslední otázka — a paradoxně ta nejvíc podceňovaná. MCP server není REST API s deterministickou sémantikou. Každé tool call závisí na tom, jak model interpretoval uživatelskou zprávu. „Funguje“ tedy nelze odečíst z unit testů.

Co měříme (nebo aspoň plánujeme měřit, než se to pustí do produkce):

• Tool selection accuracy: sledovaná sada user promptů, u kterých víme, který tool byl správně zavolán. % správných volání napříč verzemi promptů a modelů.
• Latency per turn: tokeny nejsou zadarmo a každý tool hop prodlužuje odezvu. Rozpočet per-conversation se dá nastavit a hlídat.
• Bezpečné selhání: co se stane, když model dostane nesmyslný input? Vrátí chybovou zprávu, nebo začne halucinovat tool calls? Druhé je bug.
• Lidská kontrola: kolik % write operací bylo schváleno vs. zamítnuto? Pokud 100 % schváleno, human-in-the-loop je nejspíš divadlo.

Bez evals sady se MCP server neliší od každého AI dema, co někde předvedli a rok od toho mlčí.

Precedens do budoucna: budeme vůbec stavět admin UI?

Jedna otázka, kterou tahle práce vynáší nahoru: pokud MCP server dobře pokryje workflows, které by jinak v aplikaci obstarával admin dashboard, má vůbec smysl admin UI pro lidi ještě stavět?

Poctivá odpověď: pro každý projekt se ptáme znovu. Admin UI je ergonomicky silné v úkolech, které člověk dělá stokrát týdně — hromadné operace, vizuální tabulky, rychlé filtrování za chodu. LLM tuhle ergonomii prohrává. Zato exceluje tam, kde je úkol méně častý, ale vyžaduje široký kontext (sepiš souhrn, připrav draft, propoj tři systémy, vysvětli neobvyklý stav).

V praxi nám vychází: pro některé kategorie interního provozu — reporting, onboarding nového zákazníka, incident response, analýza dat per-ticket — je MCP + chat lepší volba než custom admin v Reactu. Pro jiné (daily ops, hromadné kroky, nástěnka s metrikami) to platí obráceně. Rozhodujeme podle frekvence a ergonomie úkolu, ne podle toho, co je teď trendy.

Pozor ale na jednu věc: chat rozhraní ruší přímou viditelnost stavu systému. Tradiční admin UI ukazuje „tohle existuje“. Chat ukazuje jen to, na co se zeptáte. Pokud je chat jediná cesta dovnitř, roste riziko, že část stavu systému vypadne z provozního vědomí, dokud na ni někdo neupozorní. V designu pak chcete, aby MCP server vystavoval i „přehledové“ resources, které Claude pravidelně probírá jako součást denního rutinního promptu — a anomálie na nich sám hlásí ven.

Kam s tím dál

V Codedocku na tom stojí aktuální pipeline — prototypy běží interně, metodika se usazuje z konkrétních poznatků a první produkční projekt pro klienta se rozjíždí v nejbližších týdnech. Je to doménově specifické (detaily teď nechám stranou), ale všech pět otázek jsme měli zodpovězených dřív, než jsme začali psát server.

Pokud zvažujete MCP v enterprise kontextu, jedna věc stojí za zapamatování: v 80 % případů vyhraje jednoduchý nástroj postavený kolem jednoho workflow nad generickým „AI vidí všechno“ serverem. Druhá kategorie je impozantní v demu a k nepoužití v produkci.