Rendszergazdáknak

1. Áttekintés

2. Előfeltételek

• Windows rendszer, .NET Framework 4.7.2 vagy ujabb.
• .NET 8 SDK (a központi MCP-átjáróhoz, ha helyben futtatja).
• Elérhető SQL Server a központi nyilvántartási adatbázishoz.
• A Cobra-cég adatbázisa legalább 20260701 adatbázis-változatú legyen.
• A Cobra.MCPAgent szolgáltatás telepítéséhez emelt jogosultságú, helyi Windows-rendszergazdai fiók szükséges. Ez a Windows-szolgáltatás telepítésének (nem a napi hozzáférés-kezelésnek!) a feltétele — lásd a 4. és 5. pontot, ahol ez élesen elválik.

3. A Cobra.MCPAgent telepítése

A telepítést az Install-Cobra.MCPAgent.ps1 szkript végzi, emelt jogú PowerShell-ből:

.\Install-Cobra.MCPAgent.ps1 -Action Preflight -AgentSourcePath <útvonal> -GatewayUrl <cím> -InstallationId <azonosító> -AgentCredential <hozzáférési kulcs> -LicenceNumber <licencszám> -WorkerPath <útvonal>

Előbb mindig -Action Preflight-tal ellenőrizzen, majd -Action Install-lal telepítsen ugyanazokkal a paraméterekkel. Fejlesztői/teszt környezetben -AllowLoopbackDevelopment és -AllowUnsignedDevelopmentBuild kapcsolók használhatók; éles környezetben -ExpectedSignerThumbprint kötelező, és a GatewayUrl-nek HTTPS/WSS címnek kell lennie.

A telepítő a NT SERVICE\Cobra.MCPAgent elkülönített szolgáltatás-identitást használja, nem teszi a hozzáférési kulcsot parancssorba vagy naplóba, ellenőrzi a programaláírást, és automatikus késleltetett indulást + újraindítási rendet állít be.

Ellenőrzés telepítés után:

Get-CimInstance Win32_Service -Filter "Name='Cobra.MCPAgent'"   # State=Running, StartName=NT SERVICE\Cobra.MCPAgent
Cobra.MCPAgent.exe --agent-status                                 # {"installationId":..., "tunnelReady": true}
Get-NetTCPConnection -State Listen                                # a Cobra.MCPAgent NEM nyit bejövő portot

Hibaelhárítás — időtúllépés a kapcsolat-ellenőrzésnél: a telepítés a helyén marad, nem kell újratelepíteni. Ellenőrzés sorrendje: 1) a központi MCP-átjáró elérhető-e, 2) a hozzáférési kulcs valóban fel van-e véve, 3) --agent-status a pontos hibaüzenetért.

Helyreállítás félbeszakadt telepítés után: -Action Recover ugyanazokkal a paraméterekkel. A %ProgramData%\Cobra\MCPAgent mappát soha nem szabad kézzel törölni.

A telepítő újrafuttatása a Cobra.MCPAgent.exe.cfg-t teljesen újraírja. A régi fájlból csak a csatornakulcsokat (Channel.<licencszám>.AgentKey) őrzi meg. Minden más kulcs a telepítő értékére áll vissza (MaxWorkers = 4, SessionIdleSeconds = 120, VerboseLogging = 0 stb.), a telepítő által nem írt kulcsok (LogDirectory, WorkerLogDirectory, a csatornák Label-je) pedig eltűnnek. Ha egy gépen kézzel módosított értékek vannak, az újrafuttatás után írja vissza őket, majd indítsa újra a szolgáltatást.

4. Hozzáférés kezelése a Cobra Adminban

A menüpont mai neve és helye: Gép-gép kommunikáció → MCP Gateway hozzáférések.

A megnyíló listában látja az adott Cobra-céghez tartozó összes hozzáférést: központi hozzáférés (grant) azonosítója, külső felhasználó, publikáció, állapot, hozzárendelt Cobra-felhasználó, boríték-revízió, utolsó módosítás időpontja.

Új hozzáférés létrehozása:

1. Új gomb, vagy meglévő sor Megnyitás.
2. Beírja a személy portál-azonosítóját (CCN-XXXX-XXXX-XXXX formátum) — ezt a személy a saját Cobra Connect fiókjában látja.
3. A publikáció (a megosztott Cobra-cég) az Admin aktuális, kiválasztott cégéhez kötött, nem külön mező.
4. Kiválasztja, melyik meglévő Cobra-felhasználóhoz kösse a hozzáférést.
5. OK — sikeres válasz: "Az MCP Gateway hozzáférés aktív. Envelope revízió: <n>".

A hozzáférés ekkor elfogadásra vár állapotba kerül, és attól a pillanattól foglalja a keretet, tehát az elfogadás előtt is számít a licenc kapacitásába. A személynek a Cobra Connect portálon el kell fogadnia, mielőtt működni kezd.

Visszavonás: a lista Törlés parancsával. Ez nem törli a sort, hanem Visszavonva állapotba teszi, és azonnal érvénytelenné teszi a hozzáféréshez tartozó titkosítási kulcsot — a visszavonás a következő AI-kliens hívástól kezdve érvényes, nincs várakozási idő.

Ha ugyanazt a személyt újra felveszi visszavonás után: a rendszer nem hoz létre új sort, hanem ugyanazt a sort élesíti újra, és az újra elfogadásra vár állapotba kerül — az újra-megadás minden esetben új elfogadást igényel a személy részéről.

Fontos: ehhez a dialógushoz ma már NEM kell emelt jogú (rendszergazdai) Windows-fiók — csak érvényes Cobra Admin bejelentkezés, és az, hogy a gépre valaki interaktívan bejelentkezett. Ez korábban másképp volt (emelt jogú rendszergazdai fiókot követelt), de ezt szándékosan megszüntették, mert semmilyen extra biztonságot nem adott a napi bejelentkezés fölött, és megzavarta a normál cégváltást. Ne dokumentáljon/ne mondjon ügyfélnek olyat, hogy ehhez rendszergazdai jog kell — ez csak a szolgáltatás telepítésére igaz (lásd 3. pont), a napi hozzáférés-kezelésre nem.

5. A rendszer legfontosabb korlátai

Ez a szakasz kiemelten fontos — ezeket kódban kikényszerített, nem szokásjogi korlátok, tehát nem "kérjük, hogy csak..." jellegű ajánlások, hanem olyan műszaki tények, amikkel a konzulensnek terveznie kell.

5.1 A hozzáférés-kezelés kizárólag a beléptetett gépről lehetséges

Az Admin a Cobra.MCPAgent szolgáltatással egy nevesített csövön (named pipe) keresztül beszél. A kliens ezt mindig így nyitja:

new NamedPipeClientStream(".", ...)

A "." szervernév kizárólag a helyi gépet jelentheti — a Windows named pipe API-ban ez nem konfigurálható, nem irányítható át távoli gépre. Vagyis fizikailag nincs olyan mód, amivel az Admin egy másik gépen futó Cobra.MCPAgent-hez kapcsolódna. A hozzáférés-kezelés csak azon a konkrét gépen végezhető, amelyiket beléptettek.

5.2 A csatlakozó félnek interaktívan bejelentkezettnek kell lennie

A Cobra.MCPAgent a saját nevesített csöve felett ellenőrzi, hogy a hozzá kapcsolódó fél interaktív Windows-munkameneten van-e (a Windows beépített Interactive biztonsági azonosítóján keresztül), és a csövön az elérési jogot is ehhez korlátozza. Ha egy szolgáltatás, ütemezett feladat, vagy egy soha nem lokálisan bejelentkezett távoli munkamenet próbálna csatlakozni, azt már a csatlakozásnál elutasítja, és ha valahogy átjutna, egy második ellenőrzés (NOT_INTERACTIVE) is elutasítja. Ez a mérce nem rendszergazdai jogosultság, hanem interaktív bejelentkezés (távoli asztali kapcsolat, RDP is elfogadott, ha az interaktív munkamenetet nyit).

5.3 A titkosítási kulcs géphez ÉS Windows-fiókhoz van kötve

A hozzáférésekhez tartozó titkosítási kulcsokat (amivel a rendszer a "boríték" formátumú hozzáférési csomagokat visszafejti/aláírja) egy külön kulcstár-fájl tárolja, Windows DPAPI-val védve, CurrentUser hatókörrel:

ProtectedData.Protect(plaintext, entropy, DataProtectionScope.CurrentUser);

Ez azt jelenti, hogy a fájl csak azon a gépen és azon a Windows-fiókban fejthető vissza, ahol létrehozták — a CurrentUser hatókör a konkrét felhasználói profilhoz kötött DPAPI-kulcsot használja, ami nem hordozható át másik gépre vagy másik Windows-fiókba. A kód emellett saját, kódszintű ellenőrzést is végez: a kulcsfájlba bele van írva a létrehozó Windows-fiók biztonsági azonosítója, és minden beolvasásnál ellenőrzi, hogy az egyezik-e a jelenlegi felhasználóéval — ha nem, a fájlt érvénytelennek tekinti.

Következmény a konzulens felé: a kulcstár-fájl (vagy bármilyen konfigurációs fájl) egyszerű átmásolása egy másik gépre, vagy másik Windows-fiók alá, nem elég a hozzáférés-kezelés átvételéhez — a fájl a másik gépen/fiókban visszafejthetetlen lesz. Ha egy ügyfél gépet cserél, a hozzáférést a Cobra Adminban az új gépen kell újra telepíteni és a hozzáféréseket ott kell újra létrehozni, nem elég a régi gépről fájlokat átvinni.

5.4 Összefoglaló táblázat

6. Gép beléptetése és licenc-átvétel a Licenckezelőben

A gép Licenckezelőben történő beléptetése két esetet kezel: új gép létrehozását, és egy már meglévő gép átvételét egy másik licenchez.

6.1 Az új gép azonosítója generált GUID

Új gép beléptetésekor a gépazonosító mezőt a rendszer automatikusan egy generált GUID-dal tölti ki — ezt nem kell és nem is érdemes kézzel átírni rövid, olvasható névre. Ez szándékos, 2026-08-10-i döntés: korábban az operátor kézzel talált ki rövid azonosítót (pl. "UI-TESZT"), és ezek ütközhettek — a gateway egy már ismert azonosítót nem hibaként kezelt, hanem csendben egy másik gép nevéhez/licenchez kötötte. A generált GUID gyakorlatilag kizárja az ütközést.

Meglévő gép szerkesztésekor (a gép már be van léptetve) az azonosító- és névmező írásvédetté válik — ott nincs új generálás.

6.2 Meglévő gép átvétele másik licenchez

A Licenckezelő "Meglévő gép" választó ablakában a konzulens/felhasználó licencet választ, lekéri az ahhoz tartozó gépeket, és kijelöl egyet.

Ha a kiválasztott gép egy másik licenchez tartozik, és a gép tulajdonosa nem nyitotta meg megosztásra, a beléptetés hibával áll le. A gateway válasza (angolul, mert a hibaüzenet a gateway API-jából jön):

"Machine '<gépazonosító>' already belongs to another licence owner, and is not open for joining. Its current owner has to open it on the portal (Licenceim -> Cég gépei -> Megosztás megnyitása) before it can be enrolled here."

A Licenckezelő ezt kiegészíti egy magyar üzenettel is:

"Ez a gépazonosító már egy másik licenchez tartozik, és nincs megosztásra megnyitva. A gép jelenlegi tulajdonosának a portálon kell megnyitnia (Licenceim → Cég gépei → Megosztás megnyitása), utána a beléptetés sikerülni fog."

Tehát a megoldás mindig a gép jelenlegi tulajdonosánál van — a konzulens a saját oldaláról ezt nem tudja megkerülni, a gép tulajdonosának kell a Cobra Connect portálon megnyitnia a megosztást (lásd a MCP_Felhasznaloi_Kezikonyv.md 5.3 szakaszát).

6.3 A gép-választó rács jelzi, mely gépek vannak megosztásra nyitva

A "Meglévő gép" választó ablak rácsában van egy "Megosztás" oszlop, ami explicit megmutatja, hogy az adott gép nyitva van-e átvételre:

• "Nyitva <dátum idő>" — ha a gép tulajdonosa megnyitotta a megosztást (a dátum a megnyitás időpontja, helyi idő szerint).
• "Nincs megnyitva" — ha zárva van.

Ezzel a konzulens előre látja, melyik gépet lehet ténylegesen átvenni, mielőtt megpróbálná a beléptetést — nem kell próbálgatással kideríteni.

7. Kapacitás, megosztás és megbízhatóság

Ez a szakasz a 2026-08-07-i változásokat írja le: a gép egyszerre több beszélgetést is ki tud szolgálni, a kapu magától újranyitja a céget, és a "gép megtelt" állapot már nem néz ki hozzáférési hibának.

7.1 Worker-keret (MaxWorkers)

A Cobra.MCPAgent.exe.cfg-ben (App.config) a MaxWorkers kulcs szabja meg, hány Cobra.MCPServer.exe kiszolgáló munkapéldány futhat egyszerre azon a gépen — gépszintű, minden csatornára (minden licenctulajdonosra) közös keret, nem csatornánkénti. Alapérték: 4. Környezeti változó felülírásként: COBRA_MCP_AGENT_MAX_WORKERS.

Egy több felhasználós, sok egyidejű AI-munkamenetet kiszolgáló gépen ezt érdemes megnövelni — minden worker egy külön Windows-folyamat, saját adatbázis-kapcsolattal, tehát a szám a géphez (memória, SQL Server-kapcsolat-limit) mérendő, nem a licenctulajdonosok számához.

7.2 Worker-megosztás — egy folyamat, több beszélgetés

Korábban minden AI-kliens beszélgetés (és minden újracsatlakozás) új workert nyitott — webes AI-klienseknél ez gyakori, tehát a folyamatszám a beszélgetéseket követte, nem az embereket. Ma egy workert több beszélgetés is megoszthat, ha pontosan ugyanahhoz a hozzáféréshez tartoznak: ugyanaz az ügynök-kapcsolat, licenctulajdonos, gép (Cobra-telepítés), publikáció, cég, személy, kliens, központi hozzáférés (grant), és a boríték (envelope) verziója+lenyomata, valamint az MCP protokollverzió is egyezik. Két különböző ember tehát soha nem kerül egy folyamatba — a megosztás csak megspórolja az újranyitást, nem tágítja a hozzáférést.

Visszavonáskor a megosztott worker azonnal megy, függetlenül attól, hányan tartják — egy megszűnt hozzáférés nem szolgálhat ki egy éppen félbehagyott kérést sem.

7.3 Két tétlenségi időzítő — mit állítson, és milyen sorrendben

A WorkerParkSeconds-nak szándékosan rövidebbnek kell lennie, mint az ügynök SessionIdleSeconds értéke — a kapunak kell először lezárnia egy tétlen workert, különben az ügynök már megszüntette a folyamatot, de a kapu még élő bejegyzést tartana rá. Ha egy gépen a SessionIdleSeconds-t megemeli, a WorkerParkSeconds-t is emelni kell ugyanolyan arányban, a gateway oldalán.

7.4 "A gép megtelt" — már nem hozzáférési hibaként jelentkezik

Ha egy gépen a MaxWorkers keret betelt, az ügynök MAX_WORKERS_REACHED hibát ad. A kapu ezt ma megkülönbözteti minden más hibától, és a kliens (AI-alkalmazás) felé egy explicit, cselekvésre alkalmas üzenetet ad: a gép átmenetileg tele van, ez nem hozzáférési probléma, ne válasszon céget újra, várjon körülbelül egy percet, és ismételje meg ugyanazt a kérést.

Korábbi, hibás viselkedés (2026-08-06-ig): minden sikertelen cégnyitásra ugyanazt a tanácsot adta a kapu — hívja a list_companies-t és a select_company-t. Ez a betelt gép esetén öngerjesztő hibát okozott: a javasolt "próbáljon újra cégválasztással" pontosan egy újabb workert indított egy már betelt gépen. Ha egy régebbi doksi vagy régi rendszerinstrukció ezt a tanácsot tartalmazza, az elavult — ne dokumentálja tovább.

7.5 A kapu magától újranyitja a céget — de csak hívás ELŐTT

Ha az ügynök már elengedte a workert (tétlenség miatt), a kapu a következő kérés ELŐTT automatikusan újranyitja a céget, mielőtt a kérést továbbküldi — a felhasználónak, az AI-kliensnek erről semmit nem kell tudnia, nem kell újra kiválasztania a céget.

Ha viszont a worker MENET KÖZBEN hal meg (egy hívás közepén), a kapu nem próbálja újra automatikusan — ilyenkor nem tudható, lefutott-e a kérés, és egy adatmódosító hívás (pl. könyvelés, feltöltés) megismétlése rosszabb lenne, mint a hiba. A válasz ilyenkor egyértelműen közli, hogy az eredmény ismeretlen, a hívó kérdezzen újra, és adatmódosító hívásnál ellenőrizze előbb, megtörtént-e a művelet.

8. Naplózás, méretkorlátok és Seq

8.1 Napló-helyek és -formátum

A worker alapértelmezett helye 2026-08-08-tól a felhasználói profil, nem a telepítés mappája — a telepítés helye gyakran írásvédett vagy közös, a profil viszont mindig írható, és ahhoz köti a naplót, aki futtatta. Ugyanaz a két mappanév (Cobra Computer Kft, CobraConto.Net), mint a Cobra.Conto.exe desktop-naplójánál, csak a Local ágon (a desktop katasztrófa-naplója, az Error.log, a Roamingban van — az más műfaj, ne keverje a kettőt). A COBRA_MCP_SERVER_LOG_DIRECTORY és az ügynök WorkerLogDirectory kulcsa továbbra is felülír mindent — csak az alapértelmezés változott.

Hol keresse a worker naplóját ügyfélgépen. Az ügynök szolgáltatás NT SERVICE\Cobra.MCPAgent fiókkal fut, és az általa indított worker ennek a fióknak a profiljába ír, nem a bejelentkezett felhasználóéba. Egy élő telepítésen mérve (2026-09-24) a worker naplója itt volt:

C:\Windows\ServiceProfiles\Cobra.MCPAgent\AppData\Local\Cobra Computer Kft\CobraConto.Net\Cobra.Conto.MCPServer-yyyyMMdd.log

A cégnév a mappanévben pont nélkül áll, bár a programok szerzői adatában Cobra Computer Kft. szerepel. Ha nem találja, keressen rá a fájlnévre:

Get-ChildItem C:\Windows\ServiceProfiles,C:\Users -Recurse -Force -Filter "*MCPServer-*.log" -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending | Select-Object -First 10 FullName,LastWriteTime,Length

Mindkét napló naponta új fájlt nyit, és 30 napnál régebbi fájlokat automatikusan töröl. A worker naplója soronként a folyamat-azonosítót is kiírja, mert egy gépen egyszerre több worker-folyamat is futhat, és FileShare.ReadWrite + hozzáfűző móddal, rövid újrapróbálással ír, hogy a párhuzamos írás ne veszítsen sort.

Fontos, eddig hiányzó rész: az ügynök szolgáltatás korábban sehova nem naplózott (se fájlba, se Windows eseménynaplóba) — ha nem tudott csatlakozni, vagy elszállt, a gépen semmi nyom nem maradt. Ma egy saját, önálló naplózója van (nem a Cobra.Notification-t használja, mert az ügynök szándékosan nem hivatkozik semmilyen Cobra-projektre). Ez a naplóz: indulás a beállításokkal, sikeres csatlakozás, minden sikertelen csatlakozás okkal (401/403 esetén ez is külön szerepel), betelt worker-keret, érvénytelen munkamenet-kötés, worker lezárása a megmaradt hellyel, leállítás, és a végzetes hiba a kilépés előtt.

Beragadt küldés (a 2026-09-24 utáni ügynök-verziótól). Ha az ügynök egy üzenetet 5 percnél tovább nem tud elküldeni a központ felé, ezt ERROR sorként írja a naplóba, Beragadt kuldes: kind=..., N masodperce nem ert veget szöveggel. Ezután a csatornát nem jelenti késznek, és a szolgáltatás nem nulla kóddal kilép. A telepítő a szolgáltatásra újraindítási rendet állít be (5, 15, majd 60 másodperc múlva), ennek kell a szolgáltatást újraindítania. Hogy a Windows erre a kilépésre valóban újraindít, éles gépen még nem ellenőriztük, ezért ha ilyen sort lát, nézze meg, fut-e újra a szolgáltatás. Ha a sor rendszeresen visszatér, jelezze a fejlesztőknek a napló idevágó részével.

Az előzmény, amiért ez a sor létezik: egy ügyfélgépen az ügynök egyik szála 15 órán át egy teljes processzormagot használt, közben semmit nem küldött ki (életjelet sem), a napló hallgatott, a --agent-status pedig "tunnelReady": true választ adott. Az ok a .NET Framework saját WebSocket keep-alive-ja és a mi küldésünk ütközése volt. Az ügynök ezért ma a keretrendszer keep-alive-ját kikapcsolja, és a saját életjelére támaszkodik (HeartbeatSeconds).

Fontos csapda, amit külön ki kell mondani az ügyfélnek/kollégának: a MCPServerSettings.LogDirectory (a Cobra.Conto.MCPServer beállítás-XML-je) csak a helyi stdio üzemmódban ér valamit. A gateway-worker módban induló folyamat (--gateway-session) szándékosan nem tölti be ezt a beállítás-fájlt (a cégét is környezeti változóból kapja), tehát ha valaki ide írja be a naplómappát, a gateway-worker azt egyszerűen nem veszi figyelembe — ott a WorkerLogDirectory / COBRA_MCP_SERVER_LOG_DIRECTORY a helyes beállítási pont.

8.2 Seq (opcionális, központi naplózás)

A központi MCP-átjáró és a Cobra Connect portál (mindkettő .NET 8, ugyanaz a naplózó segédosztály) opcionálisan egy Seq-szerverbe is küldhet naplót: Seq:ServerUrl beállítás (konténerben Seq__ServerUrl env változó). Üres/hiányzó érték = nincs Seq. A repóban szállított appsettings.json (a kapué és a portálé is) 2026-08-07 óta egy belső Seq-szervert ad meg. Hogy egy adott élő telepítésen melyik cím érvényes, azt az ott beállított Seq__ServerUrl dönti el, ezt az üzemeltetés tudja megmondani.

A Cobra.MCPAgent-be szándékosan nem került Seq-küldés — azt a gépet nem a Cobra csapat üzemelteti.

A kapu naplójának SQL-kiírása (EF Core) Warning szintre lett állítva, mert korábban minden lekérdezés teljes SQL-jét kiírta Information szinten, ami elárasztotta a naplót. Ha a kapu naplójában saját nyomkövetési jelöléseket keres, ezek most jól láthatók, nem tűnnek el a SQL-zajban — például RESTORE-TRACE (munkamenet-visszaállítás) és WORKER-REOPEN (automatikus cégnyitás, lásd 7.5).

8.3 Méretkorlátok — csatolmány vs. átviteli korlát, ezeket EGYÜTT kell méretezni

Két különböző korlátról van szó, ne keverje össze a kettőt:

A MaxTunnelMessageBytes/MaxRequestBodyBytes a Base64-kódolás és a JSON-keretezés miatt szükségszerűen nagyobb, mint a nyers csatolmány-korlát — ezért lett 12 MB, hogy a 8 MB-os fájl kódolva is átférjen. A hármat (MaxAttachmentBytes, ügynök MaxTunnelMessageBytes, kapu MaxRequestBodyBytes/MaxTunnelMessageBytes) mindig együtt kell méretezni — ha bármelyik átviteli korlátot lejjebb állítják a csatolmány-korlátnál, egy nagyobb csatolmány elakad, mielőtt elérné a workert.

Figyelem — a 2026-09-28 előtti telepítővel felrakott gépeken az ügynök korlátja 2 MB. Az Install-Cobra.MCPAgent.ps1 addig MaxTunnelMessageBytes = 2097152 értéket írt a .cfg-be, és az ügynök ezt érvényesnek veszi: a 2 MB-nál nagyobb üzenetet küldéskor és fogadáskor is elutasítja, tehát egy 8 MB-os csatolmány nem jut át. A telepítő a 2026-09-28-i változattól 12 MB-ot ír (a 2026.3, 2026.3 SP1 és 2026.4 kiadási ágon a telepítő 2026-09-28-án még a 2 MB-os értéket írta). Meglévő gépen két út van: a javított telepítő újrafuttatása ugyanazokkal a paraméterekkel (ez az egész .cfg-t újraírja, lásd a 3. pontot), vagy a .cfg-ben kézzel 12582912-re írni az értéket, és utána újraindítani a szolgáltatást. Hogy egy gépen melyik érték él, a Cobra.MCPAgent.exe.cfg MaxTunnelMessageBytes sora mutatja.

Figyelem — ugyanaz a hibaosztály, mint a napló-mappánál (8.1): a Cobra.Conto.MCPServer beállítás-XML-jébe írt MaxAttachmentBytes gateway-worker módban (--gateway-session) nem ér el semmit. Ez a mód szándékosan egy friss, be nem töltött MCPServerSettings objektummal indul (McpServerApplication.Run: context.Settings = gatewaySession ? new MCPServerSettings() : context.SettingsService.Load();), amelynek konstruktora automatikusan 8 MB-ra állítja vissza az értéket — az XML-t ilyenkor nem is olvassa be. Aki ezt az értéket az XML-ben megemeli, azt látja, hogy a beállítás elmentve, "zöld", és mégsem történik semmi: a gateway-worker csatolmány-korlátja marad 8 MB. Ha a kettő közül valamelyikre külön figyelmeztetést ír egy üzemeltetőnek, ezt is jelezze vele együtt.

Az export_browser eszköz (2026-08-08 óta gateway-módban is elérhető) gateway-módban ugyanezt a 8 MB-os korlátot használja (BrowserExportSupport.GatewayAttachmentLimitBytes, szándékosan a kapu MaxAttachmentBytes alapértékével egyező szám) — a worker a fájlt egy önmagát törlő ideiglenes fájlon keresztül tartalomként adja vissza, amit a kapu a csatolmány-letöltéssel azonos módon linkké alakít. Helyi stdio módban a fájl közvetlenül a megadott mappába íródik, és méret szerinti felső korlát nincs — ott a sorszám (maxRows) az egyetlen korlát. (A MaxExportBytes beállítás létezik a kódban, de GetMaxExportBytes-nak ma egyetlen hívója van, és az a gateway-ágon fut — a helyi íráskor semmi nem ellenőrzi ezt az értéket, tehát a beállítás jelenleg hatástalan.)

9. Referencia AI-kliens rendszerinstrukciókhoz

A Cobra.MCPServer.ClientInstructions.md fájl (ugyanebben a doc/ mappában) egy kész, bemásolható rendszerinstrukciót ad AI-kliensekhez (Cobra MCP-toolok konzisztens, biztonságos használatához). Ha egy ügyfélnél AI-klienst kell beállítani, ezt ajánlja a rendszerinstrukciók/projektinstrukciók közé bemásolni. A portál-regisztrációval és a claude.ai/ChatGPT beállítással kapcsolatos lépések a felhasználói kézikönyvben (MCP_Felhasznaloi_Kezikonyv.md) találhatók.