MCP server pro malou firmu: nástroje místo kopírování

MCP server dává AI asistentovi pojmenované nástroje nad vašimi systémy. Proč začít jen čtením, OAuth, nebo bearer token, a náš MCP server Sales Desk.

Vydáno 20. října 2026 · 4 min čtení · Autor: Kamil HrbáčekMCPAI agentinástroje

MCP server je malá služba, která AI asistentovi dá sadu pojmenovaných nástrojů nad jedním z vašich systémů, třeba list_cases, get_case nebo search_mail. Asistent si pak věci vyhledá a jedná přímo, místo abyste vy kopírovali data do chatu a odpověď zase ven. MCP, Model Context Protocol, je otevřený standard, podle kterého asistenti jako Claude tyto nástroje objevují a volají. Pro malou firmu není otázka, jestli je MCP zajímavé. Otázka zní, mezi kterými systémy pořád kopírujete a jak malý přístup můžete asistentovi dát, aby vám tu práci přesto ušetřil.

Problém s kopírováním

Bez nástrojů vypadá práce s asistentem nad vlastními daty takhle: otevřít administraci, zkopírovat tabulku, vložit ji do chatu, položit otázku, zkopírovat odpověď, vložit ji zpátky. Jste kurýr a kurýři dělají chyby. Vloží včerejší export nebo půl tabulky a nikde není zapsáno, co se vlastně prohlíželo.

S MCP serverem asistent sám zavolá sales_cases_list(status: "in_review") a dostane aktuální odpověď. Server rozhoduje, co smí volání vrátit, a zaznamená, že proběhlo. Lekce naší Akademie Tools, not copy-pasted JSON (zatím anglicky) to krok za krokem staví na Cloudflare.

Náš příklad: server Sales Desk

Obchodní poptávky sledujeme na malé nástěnce, které říkáme Sales Desk: je to Cloudflare Worker a za ním databáze D1. Stejná data potřebovalo několik odběratelů: AI agent, který píše provozní standardy, programovací agenti, kteří pracují na samotné nástěnce, a v budoucnu agent, který bude pomáhat s prodejem. Napojit každého z nich na zakázkové endpointy by znamenalo pro každého jinou integraci. Nástěnka proto odpovídá i jako MCP server, přes JSON-RPC 2.0 na jediném endpointu POST /mcp.

První kolo zpřístupnilo čtyři nástroje, všechny jen pro čtení:

• sales_stats: počty podle stavu, aby agent viděl, jak fronta vypadá.
• sales_cases_list: případy filtrované podle stavu.
• sales_case_get: jeden případ s časovou osou událostí.
• sales_merge_preview: co by vzniklo sloučením dvou případů. Nic nemění.

Nástroje pro poštu přišly později: mail_search, mail_archive (vratné) a mail_draft (založí koncept ve vlákně). Nástroj pro odeslání neexistuje a ve zdrojovém kódu stojí v komentáři, že nikdy existovat nesmí. Odeslání a trvalé smazání zůstávají na člověku v přihlášené relaci.

Proč je první kolo jen pro čtení

Nástroje jen pro čtení jsou užitečné od prvního dne: odpověď na otázku „co čeká a od kdy?“ už šetří skutečný čas. A nemohou nic pokazit. Kolo jen pro čtení vám ukáže, jak asistenti nástroje doopravdy používají: které volají, jak často, s jakými argumenty a kde je popisy matou. Právě tyto informace potřebujete, než začnete navrhovat nástroje pro zápis.

Když jsme akce přidávali, přidávali jsme je podle toho, jak jdou vrátit. Archivaci zprávy jde vrátit. Napsání konceptu jde vrátit. Odeslání vrátit nejde, a proto není nástrojem. Je to stejné pravidlo, jaké uplatňujeme na agenty obecně a které popisuje článek Co je AI agent?: volně jednej nad tím, co jde vrátit, a hlídej, co vrátit nejde.

Jeden server, proměnlivá část jako parametr

Když jsme přidávali nástroje pro poštu, první nápad byl jeden server na každou schránku. Místo toho jsme zvolili jeden server se schránkou jako parametrem. Server na každý účet znamená dva tokeny, dvě konfigurace, dvě sady dokumentace a dvě místa, kde se věci rozcházejí. Účet jsou data, ne architektura. Když agent požádá o schránku, kterou server nezná, nástroj místo tichého selhání odpoví seznamem dostupných schránek.

Běh jsme také nechali tam, kde jsou přihlašovací údaje. Autorizace ke Gmailu žije v n8n a Worker je jen průčelí. MCP server nikdy nedrží heslo ani token k poště, takže únik kódu serveru by nevyzradil nic, čím se dá otevřít schránka.

OAuth, nebo bearer token

Volající jsou dvojího druhu a zaslouží si různé dveře:

• Asistenti, které používají lidé, třeba chatovací aplikace, která se k vašemu serveru připojuje jménem konkrétního člověka. Použijte OAuth: člověk schválí oprávnění s omezeným rozsahem a vy ho můžete odvolat jen jemu, aniž byste sáhli na kohokoli jiného.
• Vaši vlastní agenti a skripty. Statický bearer token posílaný v hlavičce Authorization je jednodušší a stačí, pokud je uložený v trezoru tajemství, nikdy v repozitáři, a dá se vyměnit.

Náš server Sales Desk používá bearer token, protože jeho odběrateli jsou naši vlastní agenti. Je to strojový přístupový údaj, oddělený od přihlašování PINem, které pro administraci používají lidé. Ať jsou dveře jakékoli, obě cesty by měly dojít ke stejné kontrole oprávnění. O tom je lekce Akademie Two doors, one room (zatím anglicky).

Jak navrhnout nástroje, se kterými asistenti dobře pracují

• Pojmenujte nástroje podle záměru: sales_cases_list, ne query. Asistent vybírá nástroje podle názvu a popisu.
• Uveďte omezení v popisu: „vratné“, „neodesílá“, „vrací nejvýš 50“.
• Vracejte fakta, ne závěry. „Poslední pošta tomuto zákazníkovi odešla ve 14:02“ je fakt. „Případ zodpovězen“ je odvození a odvození patří tomu, kdo podle něj jedná.
• Selhávejte užitečně: neznámá schránka vrátí seznam známých a chybějící argument řekne, který chybí.
• Ve výchozím stavu skrývejte citlivé údaje. Pokud musí existovat veřejný endpoint, vrací skutečná, ale anonymizovaná data. Rozdělení na veřejnou a soukromou část ukazuje lekce Akademie Functions as an API (zatím anglicky).

Kde začít

Vyberte jeden interní systém, ze kterého kopírujete nejčastěji. Napište pro něj tři nástroje jen pro čtení. Připojte svého asistenta a dva týdny je používejte, než přidáte cokoli, co zapisuje. Pokud vám to připadá na víc než jedno odpoledne, je to přesně ten druh práce, kterou stavíme pro klienty. A pokud se to raději chcete naučit, lekce Akademie uvedené výše vás provedou stejnými kroky.

Napsáno z našich produkčních systémů. Koncept vznikl s pomocí AI, text zkontroloval Kamil Hrbáček.