K čemu to reálně použít

MCP dává smysl v okamžiku, kdy Claude potřebuje vědět něco, co není v projektu. Tady jsou čtyři situace, ve kterých se to nejčastěji vyplatí.

1. Databáze při hledání chyby

Nejužitečnější použití pro člověka, který staví aplikaci.

Když se něco chová divně, otázka „jak vypadají skutečná data“ bývá klíčová. Bez přístupu k databázi musíš dotaz spustit sám a výsledek zkopírovat.

Na obrazovce [KDE] se u záznamu [KTERÝ] zobrazuje [CO ŠPATNĚ],
i když má být [CO SPRÁVNĚ].

Podívej se do databáze, jak ten záznam skutečně vypadá,
a porovnej to s tím, co dělá kód.

Zajímá mě, jestli jsou špatně data, nebo jejich zpracování.
Do databáze jen čti, nic v ní neměň.

2. Zadání z úkolovníku

Když má tvoje práce zdroj v tiketech, ušetří to přepisování.

Přečti si zadání [OZNAČENÍ] a připrav mi z něj plán práce.

1. Shrň, co se po nás chce, česky.
2. Co je v zadání nejednoznačné – na co se mám zeptat zadavatele?
3. Rozděl to na kroky po 20–40 minutách, každý s kritériem hotovosti.

Zatím nic neměň v projektu.

3. Návrhy z designového nástroje

Když ti někdo dodá návrh, obvykle z něj ručně opisuješ barvy, velikosti a odsazení. S přístupem k návrhu si je Claude přečte sám.

4. Chyby z provozu

Když máš nasazenou aplikaci a někde se sbírají chyby, dá se propojit hlášení chyby přímo s opravou.

Podívej se na nejčastější chybu za posledních 7 dní.

1. Vysvětli mi česky, co se děje a kolika uživatelů se to týká.
2. Najdi v projektu místo, kde vzniká.
3. Řekni mi, jestli je příčina v kódu, v datech, nebo v cizí službě.
4. Navrhni opravu.

Neopravuj nic, dokud to neodsouhlasím.

Kde je hranice

1. MCP nenahrazuje dobré zadání

   Přístup k tiketu neznamená, že je tiket srozumitelný.

2. Víc serverů znamená míň kontextu

   Popis nástrojů se do sezení načte vždycky, i když je nepoužiješ.

3. Akce na cizí straně jsou nevratné

   Založený tiket, odeslaná zpráva, změněný záznam. Tady si potvrzování hlídej.