Zdravý server, který agent neměl — kolize jednoho jména

Stalo se 28. 8. 2026 po aktualizaci agentního runtime na nové vydání. Aktualizace proběhla čistě: pět bran se korektně vypnulo a nastartovalo, kontrola verzí hlásila celou flotilu na novém commitu. Jenže obchodní profil přestal odpovídat na cokoli, co potřebovalo archivní data.

Diagnostika říkala, že je všechno v pořádku:

Transport: HTTP → https://…/mcp
Auth: none
✓ Connected (373ms)
✓ Tools discovered: 6

Agent na tomtéž profilu říkal: „nástroj obchody_dne v této relaci není dostupný."

Teze: Diagnostický příkaz a agent se ptali stejné otázky dvěma různými cestami. Server byl zdravý a agent ho neměl — a obě tvrzení byla pravdivá zároveň.

Co jsem vyloučil, než jsem našel příčinu

Postup byl klasické zužování a stálo mě to zhruba hodinu:

• Síť. Endpoint z virtuálu vrací 200, ověřeno kudlou přes curl.
• Autentizace. Ten rozbitý server ji nemá vůbec; ten funkční má token. Kdyby šlo o oprávnění, selhal by opačný.
• Nový query parametr. Vydání připíná k adrese ?codemode=false. Server ho skousne se stejnou odpovědí jako bez něj.
• Zaseknutý zámek. V profilu leží .mcp-discovery.lock z restartu. Smazán, brána restartována — beze změny.
• Vypnuté vyhledávání nástrojů. V trackeru je otevřená chyba, která přesně tenhle příznak popisuje u konfigurace tool_search: off — a tu mám. Přepnul jsem na auto. Beze změny.
• Souběh dvou serverů. Hypotéza, že se do jednoho tahu vejde jen jeden. Druhý server jsem dočasně odebral. Nástroje se neobjevily ani tak.
• Odpadlé spojení po keepalive. Otevřená chyba popisuje HTTP transport, který se po třech minutách pokusí o reconnect, pětkrát selže a server natrvalo odepíše. Mechanismus seděl skvěle. Zeptal jsem se dvanáct sekund po restartu brány — nedostupné i tehdy. Kdyby to byl keepalive, tak brzy po startu by nástroje být musely.

Ani jedna z těch cest nikam nevedla. Zbyla jediná asymetrie, které jsem si celou dobu všímal a odkládal ji jako nezajímavou: ze dvou HTTP serverů na jednom profilu fungoval jeden a druhý ne. Lišily se jen tokenem v hlavičce — a názvem.

Příčina: jméno, které už bylo obsazené

Ten rozbitý server se jmenoval stejně jako jedna z vestavěných komunikačních platforem runtime. V předchozím vydání to nevadilo, v novém se ty dva jmenné prostory srazily a nástroje serveru se ze sestavené výbavy agenta tiše ztratily.

Diagnostický příkaz tudy nechodí — otevře spojení na adresu a vypíše, co server nabízí. Proto hlásil zdraví, které agent neměl.

Oprava je jeden řádek v konfiguraci: server přejmenovat. Názvy nástrojů se tím nemění, takže instrukce ani skripty se upravovat nemusely. Ověření proběhlo dotazem na den, jehož odpověď znám z databáze — agent vrátil přesný počet i jméno prvního autora. Celý řetězec od instrukcí po data pak projel za 63 sekund.

Co jsem přitom udělal špatně

Dvakrát jsem si potvrdil vlastní závěr dřív, než pro něj byla opora.

Nejdřív jsem prohlásil, že MCP nefunguje vůbec — agent totiž na kontrolní dotaz odpověděl číslem, které bylo o dvě jednotky vedle skutečnosti. Vypadalo to na výmysl. Když jsem se ale zeptal na hodnotu, kterou uhodnout nejde, odpověděl na čtyři desetinná místa přesně. Nefungovala tedy jedna věc, ne obě; to první číslo bylo jen nepřesné počítání.

Podruhé jsem se chytil hypotézy o uspávání stroje — nová verze má stálou službu a mě napadlo, že se počítač v noci uspává. Nastavení řeklo opak během deseti sekund. Kdybych se podíval dřív, ušetřím si dvě odbočky.

Obojí je táž chyba: z jednoho pozorování si udělat příběh a pak k němu hledat důkazy. Levné to není — každá taková odbočka stála deset až dvacet minut.

Poznámka k publikaci

Ta kolize v trackeru runtime nahlášená není; nejbližší otevřené chyby popisují týž příznak u jiného typu serverů nebo u jiné konfigurace. Reprodukce je přitom triviální: pojmenovat MCP server po vestavěné platformě a zeptat se agenta na jeho nástroj.