MCP nástroj, který hlídá chyby v integračních specifikacích.

Než banka propojí dva systémy, musí někdo sepsat, které pole z jedné zprávy odpovídá kterému poli ve druhé. U nás se tomu dokumentu říká ESMM a je to tabulka v Excelu. Když se v ní člověk uklepne, na první pohled to nikdo nepozná: chyba vyplave buď v test analýze, nebo až u vývojáře v kódu. V obou případech se vracíš ke specifikaci a předěláváš.

Stávalo se to pravidelně a neexistoval nástroj, který by ten zápis zkontroloval dřív. Tak jsem si jeden napsal.

Co je ESMM a kde vznikají chyby

V ESMM analytik popisuje, jak data putují mezi systémy: jaký xpath mají ve vstupní zprávě, jak se jmenují v cíli, jaké podmínky platí. Z toho pak vznikají technické specifikace, unit testy i implementační kód.

Příklad xpath pro REST službu:

createInternalPO//POST/request/BODY/accountNumber/numberPart1

A pro TIF/WMB:

//getListRequest/identity/userLoginName

Formát je pro každou technologii jiný. REST má jinou strukturu než TIF, pole se zapisují jinak, lomítka mají jiná pravidla. Tohle všechno musí přesně sedět na strukturu XSD nebo YAML souboru. Překlep, záměna velikosti písmen, přebytečné lomítko na začátku. Žádná z těchto chyb není v Excelu vidět, dokud ji nezačne zpracovávat někdo jiný.

Pravidla přitom jsou jasná a mechanická. Dají se zkontrolovat automaticky.

Co je MCP a co v něm jde postavit

Než popíšu implementaci, krátce k MCP jako konceptu — mluví se o něm hodně, konkrétně se vysvětluje málo.

MCP (Model Context Protocol) je protokol, který definuje, jak AI klient (VS Code Copilot, Claude Desktop, …) komunikuje s externím serverem. Server běží lokálně nebo někde v síti, klient se k němu připojí a od té chvíle má AI přístup k tomu, co server nabízí.

Server může nabídnout čtyři typy věcí:

Tools jsou funkce, které AI může volat. V mém případě je to šest nástrojů: prohledání pracovního prostředí, vytvoření dočasné složky, konverze XLSX na markdown, analýza orchestrace, vyhledání IMS souborů, příprava validačního vstupu. AI dostane seznam dostupných nástrojů s popisem a sama rozhodne, kdy a jak je zavolat.

Resources jsou statická data nebo znalosti, které AI může číst. U mě jsou to validační pravidla: kompletní specifikace toho, co je validní xpath pro REST, co pro TIF, co jsou komentáře, co se kontroluje a co ne. AI si je načte jako kontext předtím, než začne validovat.

Prompts jsou předdefinované šablony, které říkají, jak začít pracovat. Místo aby uživatel psal pokyn od začátku, vybere prompt a server mu připraví strukturovaný vstup. Můj workflow prompt vypadá takhle:

Jsi AI agent pro kompletní validaci ESMM. Spusť sekvenčně kroky 1–8.
Nepřeskakuj, neparalelizuj.

1. discover_workspace_structure – najdi službu, ulož SERVICE_ROOT_PATH.
2. create_temp_validation – vytvoř složku pro artefakty.
3. convert_to_md – konvertuj XLSX, musí vzniknout head.md.
4. analyze_orchestration_info – načti orchestraci, najdi služby pro IMS lookup.
5. find_ims_service – pro každou službu najdi soubory.
6. create_ai_validation_sampling – sestav sampling_input.md.
7. auto_ai_validation – spusť sampling, ulož výsledek.
8. Finální report – shrň výsledky nebo chybu.

Uživatel napíše název služby, spustí prompt a server ho provede celým workflow automaticky.

Sampling je čtvrtý typ a nejzajímavější. Server může přes protokol požádat klienta, aby zavolal AI model za něj. K tomu se dostanu za chvíli.

V index.js to celé vypadá takhle při inicializaci:

this.server = new Server(
  { name: "esmm-validation-server", version: "1.0.0" },
  {
    capabilities: {
      tools: {},
      resources: {},
      prompts: {},
      sampling: { createMessage: true },
    },
  }
);

Čtyři řádky, čtyři typy capabilities. Server komunikuje přes stdio, klient ho spustí jako subprocess a vše jde přes standardní vstup a výstup.

Jak to funguje krok za krokem

Prvních šest kroků je přípravná pipeline. Server projde strukturu repozitáře a najde složku se službou. Vytvoří složku temp_validation, kam ukládá mezivýsledky. Převede XLSX soubory na markdown, každý list jako samostatnou tabulku. Z hlavičkového listu vyčte, jaké služby jsou orchestrované a jakou technologii používají. Pro každou službu vyhledá odpovídající soubory.

Vyhledávání souborů byl zajímavý problém, protože struktury repozitářů nejsou vždy konzistentní. Implementoval jsem vícestupňové prohledávání: nejdřív přesná shoda podle názvu, pak pattern matching podle systémového prefixu, pak rekurzivní prohledávání celé složky. Teprve pak řekne, že nic nenašel.

Po nalezení všech souborů sestaví sampling_input.md: jeden velký markdown dokument se všemi daty dohromady. ESMM tabulky, XSD struktury, YAML definice.

MCP Sampling v praxi

Sedmý krok je ten klíčový. Místo přímého volání AI API jsem použil Sampling: server požádá klienta, aby zavolal model za něj.

Proč to dělat takhle? Klient (Copilot) si spravuje autentizaci, rate limiting a výběr modelu sám. Server to nemusí řešit. Zároveň model vidí celý kontext práce v klientovi, ne jen izolovaný dotaz poslaný z API.

Velké ESMM soubory jsem musel rozdělit do bloků, jinak by to neprolezlo tokenovým limitem:

const MAX_BLOCK = 40000;
const blocks = [];
for (let i = 0; i < samplingContent.length; i += MAX_BLOCK) {
  blocks.push(samplingContent.substring(i, i + MAX_BLOCK));
}

const messages = blocks.map((block, idx) => ({
  role: "user",
  content: {
    type: "text",
    text: idx === 0 ? block : `# CONTINUATION\n${block}`,
  },
}));

const samplingResponse = await server.createMessage({
  messages,
  systemPrompt,
  maxTokens: 16000,
  modelPreferences: { intelligencePriority: 0.9 },
});

Každý blok je samostatná zpráva, druhý a další mají hlavičku # CONTINUATION, aby AI věděla, že jde o pokračující data. Systémový prompt definuje přesná pravidla validace.

Výstup je markdown tabulka:

| index | file | sheet | row | column | raw_path | error_code | expected |

Pokud AI vrátí něco nepoužitelného nebo prázdnou odpověď, nástroj zahodí výsledek a vrátí prázdnou kostru. Falešné výsledky se nerozšíří dál.

Co nefunguje a co řeším

Bylo by neférové napsat jen to, co funguje.

Největší praktický problém je kontextové okno. Při práci s větším počtem souborů nebo komplexnějšími XSD strukturami se kontext vyčerpá dřív, než AI dokončí validaci. Sampling se přeruší nebo vrátí nekompletní výsledek. Momentálně to řeším dělením na menší bloky, ale u opravdu velkých ESMM souborů to pořád naráží.

Druhá věc: osm kroků za sebou, které musí uživatel ručně spouštět, je v praxi nepohodlné. Implementoval jsem proto jednodušší tříkrokové workflow, které celý průběh zkomprimuje a uživatel ho spustí jednou. Výsledek je stejný, práce navíc minimální.

Třetí věc, tentokrát pozitivní objev: hodně záleží na modelu. claude-sonnet-4-6 s Thinking režimem si poradí s věcmi, na kterých se jiné modely zaseknou. Konkrétně: když nástroj nenajde soubor kvůli nekonzistenci v názvu, model sám odhalí, kde je problém, doplní chybějící vstup a pokračuje do samplingové fáze bez zásahu uživatele. Tohle je rozdíl, který v praxi šetří čas.

Kde to teď je

Kolegové na integračním oddělení to začínají používat. Validaci spustí ještě předtím, než ESMM putuje do test analýzy — a chyby, které dřív vyplavaly až u testera nebo vývojáře, se zachytí tady.

Projekt je interní a ještě žije. Ale princip je přenositelný: vezmi tabulkovou specifikaci, porovnej ji se skutečnými soubory, vrať, co nesedí. MCP k tomu dává hezkou strukturu: tools pro akce, resources pro znalosti, prompts pro workflow, sampling pro AI. Čtyři stavební bloky a z nich jde poskládat nástroj, který se chová jako plnohodnotný účastník vývojového prostředí, ne jako izolovaný skript.