Napsal jsem MCP nástroj pro validaci ESMM.

Funguje to tak, že analytik napíše ESMM, pošle ho dál a chyba se najde buď v test analýze nebo přímo u vývojáře v kódu. V obou případech se vrátíš ke specifikaci a předěláváš. Stávalo se to pravidelně a nebyl žádný nástroj, který by xpath zkontroloval předtím. Tak jsem si jeden napsal.

Co je ESMM a kde vznikají chyby

ESMM je mapovací tabulka v Excelu. Analytik do ní zapisuje 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, rychle MCP jako koncept, protože je to věc, o které se hodně mluví ale málo konkrétně vysvětluje.

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 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řed tí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. Moje 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ří temp_validation složku 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: model hodně záleží. claude-sonnet-4-6 s Thinking režimem si poradí s věcmi, kde 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. Spustí validaci předtím než ESMM putuje do test analýzy a chyby, co se dřív nacházely u testera nebo vývojáře, se teď zachytí dřív.

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.