Adam Jones és Tadas Antanavicius cikke — eredetileg a Pulse blogján megjelent és az szerzők engedélyével átvett — azt vizsgálja, hogyan érdemes gyakorlatilag több MCP-szervert és több MCP-klienset összekapcsolni. A szerzők hangsúlyozzák, hogy az egyszerű 1×1 bemutatók (egy szerver, egy kliens) hasznosak ugyan, de a valódi előny akkor jön, ha több szervert teszünk elérhetővé több felület számára: ezzel olyan feladatok válnak automatikussá, amelyeket egyetlen alkalmazás önmagában nem tud elvégezni.
Miért jelent többet a több szerver?
Egy egyszerű példa: egy Gmail MCP-szerver önmagában tudja triázsolni az e-maileket és vázlatot készíteni válaszokhoz — de a Gmail felület ezt már 20 éve jól kezeli. Az érték abban látható, amikor a Gmail-szerver egy másik szolgáltatással dolgozik együtt: például egy IKEA rendelésről érkező levél mellékleteként kapott számlát a Benepass (egy juttatásszolgáltató) rendszerébe feltölteni és beküldeni. Claude Code képes megtalálni az e-mailt, kinyerni a mellékletet, megszerezni a Benepass bejelentkezéshez szükséges egyszeri kódot a Gmailből, feltölteni a számlát és elküldeni — ezt egyetlen alkalmazás önmagában nem tudná végrehajtani.
Több kliens: ugyanazok az integrációk több felületen
A szerzők kiemelik, hogy nem elég, ha egy integráció egyetlen kliensben (például Claude Code-ban) elérhető: hasznos, ha ugyanazok a szerverek más felületeken is működnek, például Claude.ai, Gmail, Linear, Slack stb. Gyakori forgatókönyv: egy Slack-beszélgetésben valaki bekéri az "@ai does our discussion here align well with current company strategy?" típusú inline választ, amely beemeli a Notion-beli OKR-eket és néhány Zoom-megbeszélés átiratát. Vagy Linearben feladatból kiderül, hogy megbeszélést kell szervezni — egy kommenttel lehet azt kérni: „@ai schedule a meeting with John and draft an agenda based on the meeting I just had with Pam to address this.”
A cikk megjegyzi, hogy natív MCP-kliensfunkciók hamarosan sok felületen elérhetők lesznek, és már láthatók nem-natív megoldások is, például Claude Tag. Ugyanakkor azt is hangsúlyozzák, hogy ezek a képességek ma is beállíthatók a csapat számára egy kis „ragasztó” kóddal, amely egy webhook vagy polling mögé injektál egy teljes értékű agent-harness-t és MCP-klienst.
Távoli szerverek előnyben — helyi szerver csak bizonyításra
A helyi szerverek telepítése sok kolléga számára problémás: npm telepítése, JSON fájl szerkesztése, környezeti változók beállítása nem skálázódik. A távoli szerverek használata egyszerűbb: elég egy URL megosztása. Néhány felület, például claude.ai, csak távoli szervereket támogat.
A tipikus minta: helyi fejlesztéshez használhatunk lokális szervert, de éles használatra érdemes «remote, multitenant» réteget tenni elé. Itt jön képbe az mcp-auth-wrapper: ez OAuth-ot ad előre, és felhasználó-specifikus hitelesítést kezel mögötte, így a helyi szerver megosztható linkként viselkedik.
Konfigurációs súrlódás csökkentése
Már csak egy link van szerverenként, de hol adják meg a felhasználók ezt a linket? A javasolt minta, hogy minden MCP-klienshez adunk telepítési útmutatót. Az install-mcp szolgáltatás például egyetlen oldalon generálja a megfelelő telepítőlinket és kliensspecifikus instrukciókat. Akik saját felületükbe akarják integrálni, használhatják a mcp-install-instructions TypeScript könyvtárat.
A szerzők említik, hogy dolgoznak az mcp.json fájlformátum standardizálásán, de a nem-CLI felületek várhatóan továbbra is különböző kapcsolódási folyamatokat igényelnek. Sok vállalatnál ez később az IT feladatává válhat enterprise-managed auth megoldásokkal.
Konfiguráció egyszer kelljen csak — mcp-aggregator
Alapértelmezés szerint minden felhasználónak minden kliensben külön kell hitelesítenie minden szervert — ez gyorsan fárasztóvá válik (10+ „add connector”, 10+ OAuth tánc). A megoldás: egy központi, aggregáló MCP-szerver. Az mcp-aggregator telepítésével egy végpont és egy bejelentkezés fog minden eszköz mögött állni; minden kliens egyszer konfigurálva van, minden szolgáltatásért egyszer kell bejelentkezni, és egy link megosztható a csapattal. A szerzők 7 kliens × 6 szerver = 42 kapcsolat konfigurálásának példáját hozzák fel, de az aggregátorral ez 7 + 6 = 13 konfigurációra egyszerűsödik: mindkét oldal egyszer van beállítva.
Az mcp-aggregator a minimális, DIY verziója egy MCP gateway-nek; vállalati igények (SSO, finom admin szabályozás) itt "ráépíthetők". Alapból az aggregator elveszíti a per-session korlátozások (per-session constraints) natív használatának lehetőségét, de az aggregációs réteg kiegészíthető úgy, hogy query paraméterekkel vagy külön végpontokkal újra bevezesse azokat.
A hiányzó MCP-szerverek hosszú farka — képernyőműveletek mint menekülőút
Nem mindig találni kész MCP-szervert egy adott szolgáltatáshoz. Például: Octopus Energy küld egy megerősítő e-mailt és az API kulcs csak a webes bejelentkezés mögött érhető el — nincs API arra, hogy lekérd az API-kulcsot. Ilyenkor a megoldás: engedjük meg az agentnek, hogy képernyőn dolgozzon.
A computer-use-mcp egy minimális példája egy MCP-szervernek, amely Playwright-szerű lépésekkel képes bejelentkezni a weboldalra, kimásolni a kulcsot, majd tiszta API-hívásokkal folytatni a folyamatot. Ezzel a „lesz-e API” probléma megszűnik blokkoló tényező lenni.
Anthropic hangolásából idézett logika szerint: ha van MCP-szerver egy szolgáltatáshoz, Claude azt használja; ha shell-parancsról van szó, Bash-t használ; ha böngészőművelet kell és a Claude Chrome-ban be van állítva, azt használja; ha egyik sem áll rendelkezésre, Claude a computer use-t alkalmazza.
Ha egy munkafolyamatot rendszeresen böngésző-műveletekkel vagy computer-use-szal kell megoldani, érdemes ezt a Playwright-hívást stabil MCP-szerverré absztrahálni — jó példa erre a Good Eggs példája.
Lokális, géphez kötött szerverek távoli elérhetővé tétele
Néhány szerver csak akkor működik helyben. A computer-use a tipikus példa. A mcp-local-tunnel minta azt mutatja be, hogyan tehetőek géphez kötött szerverek távoli aggregátorok számára elérhetővé: a tunnel úgy viselkedik, mint bármely más távoli végpont.
Figyelem a kontextus-burjánzásra (context bloat)
Naiv eszköz-hívásoknál minden köztes eredmény a modell kontextusába kerül, és sok kliensnél az összes eszközdefiníció kezdettől a kontextusban van — így már a munkafolyamat elején tízezrek tokenje elfogyhatnak feleslegesen. Példa: egy Google Drive-dokumentum Salesforce-ba másolásakor a teljes dokumentum kétszer megy át a modellen feleslegesen. Anthropic mérése szerint egy munkafolyamat 150 000 tokenről 2 000-re esett vissza ilyen problémák kezelése után.
Ennek több megközelítése van, mindegyik kompromisszumokkal:
- Kódvégrehajtás beiktatása az MCP fölé: a tool-sandbox-mcp egy execute_code absztrakciót mutat, amely a model és a szerverek közé kódvégrehajtási réteget húz — működik bármely MCP-kliensben.
- MCP, mint CLI eszköz: a call-mcp példája azt mutatja, hogyan lehet az eszközöket CLI-környezetbe csomagolni (shell, jq, cron, script), így a szokásos parancssori eszköztárral komponálhatók.
- Keresőeszközök és nagy válaszok trancsírozása: ezt Claude Code natívan megvalósítja, de hidakkal is bevezethető.
Gyakorlatias példa: Linear harness és más beágyazások
A szerzők bemutatnak egy végponttól végpontig projektet, amely egy Linear integrációt alakít át úgy, hogy egy erőteljes MCP-klienst (Claude Code-ot) injektál a Linear munkafolyamatába. A harness bármilyen Linear-tevékenységre képes figyelni (például ticket-kommentek olvasása), és bármilyen készséggel, pluginnal vagy MCP-kapcsolattal vissza tud reagálni egy Linear MCP-szerveren keresztül (vagy az mcp-aggregatorral).
Nem korlátozódik ez a mintázat task-managementre: egy rövid példa akár Minecraft-on belüli Claude Code-ügynökről is szól, amely javaslatokat ír magáról, ellenőrzi az energiaárakat és naptárbejegyzést hoz létre, vagy egy játékbeli hirdetőtáblát épít. A cél demonstrálni, hogy egy teljes értékű agent — az összes eszközzel és fenti mintával — gyakorlatilag bárhol futhat egy kis ragasztóval.
Következtetés
A cikk bemutatja a haladási útvonalat az 1×1 demonstrációktól egy M+N összekapcsolási modell felé: távoli, multitenant szerverek preferálása, hitelesítési wrapper-ek, egyszerű telepítési UX, központi aggregator az egyszeri konfigurációért, „computer use” és browser-automáció mint escape hatch, valamint a kontextus-burjánzás kezelése kódvégrehajtási réteggel vagy CLI-hidakon keresztül. Ezek a minták elérhetők ma is egyénektől a csapatokon át a vállalati környezetekig.
Szerzők: Adam Jones és Tadas Antanavicius. Eredeti megjelenés: Pulse blog (újraközölve a szerzők engedélyével).
