MCP-átjárók: Hogyan kezelhetünk több MCP-kiszolgálót nagy léptékben?

Sokunk számára ez egy MCP-kiszolgálóval kezdődik. A fejlesztő összekapcsolja a GitHubot a Claude-dal vagy a Cursorral, és máris működik. Aztán valaki hozzáadja a Slacket, majd a Jirát, végül egy belső adatbázist.

Hat hónap múlva minden fejlesztőnek megvan a saját konfigurációs fájlja, API-kulcsai és szerverlista.

Jelenleg nem tudja, mely ügynökök férhetnek hozzá a termelési adatokhoz. Ha egy mérnök távozik, akkor minden általa létrehozott tokent nyomon kell követnie. Egy új szerver hozzáadása azt jelenti, hogy 15 kliens konfigurációját kell kézzel frissítenie.

A legijesztőbb az, hogy amikor egy ügynök valami váratlant tesz, nincs egyetlen napló sem, amely megmagyarázná, miért is történt ez egyáltalán.

A tokenek jelentik a második költségtényezőt. Minden csatlakoztatott szerver betölti az eszközdefinícióit a kontextusablakba. Egy öt szerverből álló konfigurációban az Anthropic körülbelül 55 000 tokennyi eszközdefiníciót mért , mielőtt az ügynök egyetlen kérést is feldolgozott volna.

Tehát a több MCP-kiszolgáló kezelése két feladatra vezethető vissza: a hozzáférés egy helyről történő ellenőrzésére és az egyes ügynökök eszközlistájának rövidre tartására. Az MCP-átjáró alapértelmezés szerint az elsőt kezeli. A másodikat csak akkor kezeli, amikor szűri vagy keres az eszközök között. Öt olyan átjárót veszünk górcső alá, amelyeket érdemes értékelni, megnézzük, mennyibe kerülnek, és hogyan lehet őket bevezetni anélkül, hogy az ügynökök működését megzavarnánk.

Mi az az MCP-átjáró?

Amikor beérkezik egy kérés, az átjáró ellenőrzi, ki küldte, és hogy az adott felhasználó vagy ügynök mely eszközöket láthatja. Letölti az eszközdefiníciókat az egyes upstream szerverekről, és előtagot ad a nevekhez, így a github_create_issue és a jira_create_issue nem ütköznek egymással. Minden, amit kiszűrtél, elvetésre kerül, így a modell egy tiszta listát lát.

Amikor a modell kiválaszt egy eszközt, az átjáró a hívást annak a szervernek továbbítja, amelyik az eszköz tulajdonosa, és csatolja az adott szerver hitelesítő adatait. A legtöbb termékben az ügynök soha nem tárolja ezeket az adatokat. Minden hívás egy ponton halad át, így az átjáró naplózhatja, hogy mit hívtak meg, ki hívta meg, és mi volt a válasz.

Az eszközválasztás és a szerver biztonsága továbbra is attól függ, hogyan konfigurálja a szűrést és a jogosultságokat, amit az alábbi útmutató részben fogunk tárgyalni.

Miben különbözik egy MCP-átjáró egy regisztertől, egy LLM-átjárótól vagy egy API-átjárótól?

Mind a négy a kliens és az általa igényelt elem között helyezkedik el, ezért keverik össze őket a csapatok.

A különbség az egyes rendszerek által kezelt forgalomban rejlik. Az MCP-átjáró dönti el, hogy egy ügynök meghívhat-e egy eszközt, míg a regisztráció csak tájékoztatja az ügyfeleket a létező szerverekről, és soha nem továbbít kéréseket. Az LLM- és az API-átjárók különböző forgalmat kezelnek: az előbbi kiválasztja, melyik modell válaszoljon egy parancsra, az utóbbi pedig védi a szolgáltatásaihoz érkező szokásos HTTP-hívásokat.

A gyakorlatban a határok elmosódnak. Például az olyan eszközök, mint a Kong AI Gateway, az LLM- és MCP-forgalmat egy vezérlőrétegen keresztül továbbítják, míg a ContextForge a gateway mellett egy regisztrációt is üzemeltet. A termékek összehasonlításakor ellenőrizze, hogy az egyes termékek valójában mely rétegeket fedik le.

A hivatalos MCP Registry 2025 szeptemberében indult el az Anthropic, a GitHub, a PulseMCP és a Microsoft támogatásával. Egy évvel később még mindig előzetes verzióban van. Használd szerverkeresésre, de tartsd meg a saját listádat a jóváhagyott szerverekről.

Csökkenti-e az MCP-átjáró a tokenek használatát?

Igen, de csak akkor, ha szűri vagy keres az eszközök között. Minden MCP-kiszolgálóhoz tartozik egy eszközkészlet, és minden eszközhöz tartozik egy leírás, amelyet az AI-nek el kell olvasnia, mielőtt használni tudná. Ezek a leírások pedig tokeneket fogyasztanak. Az átjáró az összes kiszolgálót egy helyen gyűjti össze. Hacsak nem állítod be szűrésre, továbbra is minden kiszolgáló minden eszközét megmutatja az AI-nek, így az AI ugyanazt a leíráshalmot olvassa el, mint korábban.

Csak akkor takaríthat meg tokeneket, ha az átjáró elrejti azokat az eszközöket, amelyekre egy feladatnak nincs szüksége.

A költség csak a probléma fele. Gyakori hibaforrás, amikor a modell rossz eszközt választ, vagy rossz paramétereket ad meg. Ez különösen akkor fordul elő, ha az eszköznevek hasonlóak, például a notification-send-user és a notification-send-channel. Az Anthropic dokumentációja szerint az eszközválasztás minősége 30–50 rendelkezésre álló eszköz felett romlani kezd, és néhány szerver önmagában is túllépheti ezt a határt.

Az Anthropic által javasolt megoldás az, hogy előre betöltsünk egy keresőeszközt, és csak a feladat elvégzéséhez szükséges három-öt eszközt vonjuk be. Egy több mint 50 MCP-eszközt felölelő teszt során a teljes kontextus mérete körülbelül 77 000 tokenről körülbelül 8 700-ra csökkent, amit az Anthropic 85%-os csökkenésként jelentett. A belső MCP-értékelések pontossága is nőtt: az Opus 4 esetében 49%-ról 74%-ra emelkedett az eszközkeresés engedélyezésével, az Opus 4.5 esetében pedig 79,5%-ról 88,1%-ra.

A vállalat MCP-vel végzett kódvégrehajtással kapcsolatos megállapításai még ennél is tovább mennek. Amikor egy ügynök átnézte az eszközfájlok mappáját, és csak a szükséges definíciókat olvasta be, egy Google Drive-ról a Salesforce-ra irányuló munkafolyamat tokenjeinek száma 150 000-ről 2 000-re csökkent. Ez a megközelítés azonban sandbox-környezetet igényel az ügynök által írt kód számára, ami önmagában is működési költséget jelent.

Az átjárók kétféle lehetőséget kínálnak erre.

Az első módszer az eszközlisták kézi szűkítése. A Docker profiljaival szerverenként engedélyezheti az egyes eszközöket, a ContextForge virtuális szerverei több upstream szerverből válogatott készletet tesznek közzé, a Composio Tool Router pedig egy munkamenetet rögzíthet egy fix listához.

A második a híváskor történő keresés. Az AgentCore Gateway tartalmaz egy beépített szemantikai keresőeszközt, amelyet az ügynökök egyszerű nyelven használhatnak, és a Composio futásidőben is képes eszközöket találni.

Az Anthropic ajánlása szerint akkor kell intézkedni, ha a definíciók meghaladják a 10 000 tokent, vagy ha 10 vagy több eszköz áll rendelkezésre. A legtöbb AI-alapú munkafolyamat-automatizálási konfiguráció gyorsan átlép ezt a határt, a többügynökös munkafolyamatok pedig még hamarabb.

Melyek a legjobb MCP-átjárók?

Rengeteg termék nevezi magát MCP-átjárónak, és némelyik inkább szerverkönyvtárhoz hasonlít. Ez a lista azokat az eszközöket sorolja fel, amelyek a rendszer felépítésének középpontjában állnak. Az ügynökei egy végponthoz kapcsolódnak, az átjáró eléri a mögötte lévő szervereket, és Ön legalább egy valódi ellenőrzési lehetőséget kap arra, hogy mi halad át a rendszeren.

Ez az ellenőrzés lehet bejelentkezés, eszközengedélyezési lista vagy ellenőrzési napló.

Öt maradt versenyben. Mindegyik ugyanazt a problémát oldja meg, de különböző módon. A megfelelő választás attól függ, hogy hol futnak már az ügynökei: egy fejlesztő laptopján, a saját infrastruktúráján, egy meglévő Kong-konfigurációban, az AWS-en vagy SaaS-alkalmazásokban.

1. Docker MCP-átjáró (legalkalmasabb a Docker Desktopon történő helyi fejlesztéshez)

A Docker MCP Gateway a Docker Desktop MCP Toolkitjének nyílt forráskódú motorja. Ha már használja a Desktopot bekapcsolt eszközkészlettel, az átjáró további beállítás nélkül fut a háttérben. A szerverpark szétterjedésére adott válasza a konténerek használata. Minden MCP-szerver saját konténerben fut, korlátozott jogosultságokkal, hálózati hozzáféréssel és erőforrásokkal, és az átjáró csak akkor indítja el, ha egy ügynöknek szüksége van az egyik eszközére.

A profilok egy helyen tartják a beállításokat. Egy profil összefogja a projekthez szükséges szervereket, és minden kliens, amelyhez csatlakozol – legyen az Cursor, VS Code, Claude Desktop vagy Claude Code –, ugyanazt a beállítást használja. A profilt feltöltheted egy OCI-regisztrációba, hogy a csapattársaid letölthessék, így 15 kézzel szerkesztett konfigurációs fájlt egyetlen megosztott definícióval helyettesíthetsz.

Egy profilon belül bekapcsolhatja az egyes eszközöket, például a github.create_issue-t, a szerver többi részét pedig kikapcsolva hagyhatja. Így tartja rövidnek a Docker a modell eszközlistáját.

A hitelesítő adatok nem kerülnek a konfigurációs fájlokba. Az átjáró a Docker Desktop titkos adattárából tölti be a titkos adatokat, és hozzáadja azokat a szerver indításakor, valamint kezeli az OAuth-bejelentkezést azoknál a szervereknél, amelyeknél erre szükség van. A beépített naplózás és a híváskövetés megmutatja, mely eszközök futottak. Az átjáró csak a hívásokat irányítja, a döntéshozatal pedig az automatizáláshoz futtatott AI-ügynökökben történik. A kezdéshez a Docker MCP-katalógus több mint 200 eszközt és szolgáltatást sorol fel.

Ahol elmarad: Az átjárót azoknak a fejlesztőknek tervezték, akik saját gépeiken futtatnak szervereket. A Docker AI Governance részeként értékesített irányítási változat kizárólag meghívásos alapon érhető el a Docker értékesítési csapatán keresztül, így nem lehet önállóan regisztrálni a csapat-szintű szabályozási funkciókra. Az átjárót manuális telepítéssel a Docker Desktop nélkül is futtathatja, de a titkos adatok kezelése továbbra is a Desktop-tól függ.

Mit mondanak a valós felhasználók a Docker MCP Gateway-ről?

Egy felhasználói vélemény szerint:

A Docker MCP-átjárója valóban kiváló a helyi fejlesztéshez – szerverenkénti konténerelkülönítés, a Docker Desktopba beépített hitelesítőadatok kezelése –, de valójában nem a csapatok és régiók közötti vállalati irányításra lett kialakítva.

2. IBM ContextForge (Legalkalmasabb saját szerveren futó, csapatonkénti eszközkészletekhez)

Az IBM ContextForge egy nyílt forráskódú átjáró és nyilvántartás, amelyet a saját infrastruktúráján futtathat. Az MCP-kiszolgálókat, az ügynök-ügynök (A2A) szolgáltatásokat, valamint a hagyományos REST- vagy gRPC-API-kat egyetlen végpont mögé egyesíti. Telepítheti a PyPI-ről, konténerként futtathatja, vagy a projekt Helm-diagramjával telepítheti a Kubernetes-re.

Ami kiemeli a többi közül, az a virtuális szerver. Kiválaszthatja az átjáróban regisztrált eszközöket, egyetlen név alá csomagolhatja őket, majd a kliensnek megadhatja a csomag végpontját. A pénzügyi ügynök a pénzügyi eszközöket kapja, a támogatási ügynök pedig egy másik készletet, és egyik sem tölti be a másik definícióit. Minden virtuális szerver lehet privát, megosztható egy csapattal, vagy nyilvános.

Emellett a már meglévő API-kat is MCP-eszközökké alakítja. Ha egy REST végpontra irányítja, automatikusan letölti a JSON-sémát. Az eszköz emellett szerverreflexió segítségével lefordítja a gRPC-szolgáltatásokat is. Ezzel elkerülhető, hogy minden belső API-hoz külön wrapper szervert kelljen írni.

Minden upstream szerver megőrzi saját OAuth-beállításait, a ContextForge pedig felhasználónként tárolja a tokeneket, így két szerver is különböző identitásszolgáltatókat használhat. Az adminisztrációs felület tartalmaz egy élő napló-megjelenítőt, a nyomkövetési adatok pedig az OpenTelemetry-n keresztül kerülnek elküldésre olyan háttérrendszerekbe, mint a Jaeger, a Zipkin és a Datadog. Több mint 40 bővítmény biztosít további adatátviteli módokat és integrációkat.

A hátránya: A futtatást, a frissítéseket és a méretezést magának kell elvégeznie. Az átjáró addig nem indul el, amíg nem generál erős titkos kulcsokat. A projekt a termelési környezetben a PostgreSQL használatát javasolja, a támogatás pedig a GitHub-on megnyitott problémajelentések és fórumok keretében történik.

Mit mondanak a valós felhasználók az IBM ContextForge-ról?

Egy felhasználói vélemény szerint:

Apache-licenc alatt áll, és azok számára készült, akik már komoly Kubernetes-infrastruktúrát üzemeltetnek. Egy igazán hatékony megoldássá fejlődött – valódi irányítást és felügyeletet biztosít, és képes az MCP-t a vállalat egyéb API-jaival együtt kezelni. Beüzemelése azonban nehezebb, mint a kisebb megoldásoké, ezért ez nem egy hétvégi projekt.

3. Kong AI Gateway (Leginkább azoknak a csapatoknak ajánlott, amelyek már Kongot használnak)

A Kong az MCP-forgalmat egyfajta API-forgalomként kezeli. Ha a csapata már használja a Kong Gateway-t vagy a Kong Konnect-et, az MCP-támogatás pluginek formájában érhető el a már üzemeltetett átjárón. Ugyanazt a hitelesítést, sebességkorlátozást és naplózást fogja használni, mint az API-k esetében.

A rendszer központi eleme az AI MCP Proxy bővítmény. Ez beilleszthető egy már futó MCP-kiszolgáló elé, vagy bármely OpenAPI-sémával rendelkező API-t MCP-eszközzé alakíthat egyedi kód írása nélkül. Több API-ból származó eszközöket is összevonhat egyetlen MCP-végpontba, így az ügynököknek nem minden szolgáltatáshoz külön-külön, hanem csak egyszer kell csatlakozniuk.

A hozzáférés-vezérlés eszközönként működik. A felhasználó vagy felhasználói csoportok szerint állíthat be engedélyezési és tiltási listákat, és amikor egy ügynök lekérdezi az eszközlistáját, a Kong csak azokat az eszközöket adja vissza, amelyeket az adott hívó használhat. Minden engedélyezett vagy elutasított kísérlet bekerül a bővítmény auditnaplójába. Mivel egy ügynök soha nem tölti be azokat az eszközöket, amelyeket nem tud meghívni, a szűrt lista a kontextust is kisebb méretűvé teszi.

A bejelentkezés a Kong hitelesítési bővítményein keresztül történik, beleértve az OpenID Connectet és az AI MCP OAuth2 bővítményt. Az MCP forgalmi naplói rögzítik a munkamenet-azonosítókat, a JSON-RPC-módszereket, a hasznos adatokat, a késleltetéseket és a hibákat, és nyomkövetéseket küldhet az OpenTelemetry-nek. Ha az LLM-forgalmat is a Kong AI Gateway-en keresztül irányítja, akkor a modellforgalom és az eszközforgalom egy közös vezérlőréteget használ.

Ahol korlátokba ütközik: Az SSO és a platform auditnaplói a Konnecten csak az Enterprise csomagban érhetők el. Az AI MCP Proxy bővítmény nem támogatja a WebSocket vagy gRPC upstreameket, és az AI védelmi korlátok nem vonatkoznak az MCP-kérelmekre. A REST-konverzióhoz minden API-hoz érvényes OpenAPI-séma szükséges, az eszközönkénti ACL-ekhez pedig a Kong Gateway 3.13 vagy újabb verziója szükséges. Az MCP-ügyfelektől érkező pingek is beleszámítanak a havi kérések összszámába.

Mit mondanak a valódi felhasználók a Kong AI Gateway-ről?

Egy felhasználói vélemény így szól:

Ez akkor érdemes, ha már Kongot használsz. Ez már nem csak egy ráhúzott MCP, hanem valódi, célra szabott támogatás, beleértve az ügynökök közötti forgalmat is, és július közepén partnerségre léptek egy AI-alapú irányítási céggel, hogy a szabályellenőrzéseket közvetlenül az átjáróba építsék be. A mélyebb funkciók egy része azonban valószínűleg fizetős csomagot igényel.

4. Amazon Bedrock AgentCore Gateway (A legjobb az AWS-en futó ügynökök számára)

Az Amazon Bedrock AgentCore Gateway az AWS teljesen felügyelt megoldása, így nincs szükség semmilyen szerver üzemeltetésére vagy méretezésére. Az ügynökök számára egyetlen végpontot biztosít az eszközeikhez. Az AgentCore emellett az OpenAPI- és Smithy-specifikációkat, a Lambda-függvényeket, valamint a meglévő MCP-kiszolgálókat is MCP-eszközökké alakítja át egyedi kód írása nélkül. Tartalmaz egykattintásos integrációkat a Salesforce, a Slack, a Jira, az Asana és a Zendesk szolgáltatásokhoz.

Az eszközkeresés beépített funkció. Ha az átjáró létrehozásakor bekapcsolja a szemantikus keresést, az ügynökök egy olyan keresőeszközt (x_amz_bedrock_agentcore_search) kapnak, amelyet egyszerű nyelven kérdezhetnek le. Így csak a feladathoz szükséges eszközöket töltik be, ahelyett, hogy a teljes katalógust betöltenék. Ez ugyanaz az igény szerinti mintázat, amelyet az Anthropic is leír, csak az átjárón fut, nem pedig a kliensen.

A hitelesítés mindkét irányban működik. Bejövő forgalom esetén az átjáró az AWS IAM-en vagy az identitásszolgáltatótól származó JWT-n keresztül ellenőrzi, ki kezdeményezi a hívást. Kimenő forgalom esetén OAuth-val, API-kulccsal vagy IAM-szerepkörrel jelentkezik be az egyes eszközökbe, és maga adja hozzá ezeket a hitelesítő adatokat, így az ügynökök soha nem tárolják őket. Az AgentCore Identity használata az átjárón keresztül nem jár többletköltséggel, az AgentCore Policy pedig minden eszközhívást összevethet a Cedar nyelven írt szabályokkal.

Az átjáró nyílt forráskódú keretrendszerekkel működik együtt, beleértve a CrewAI-t, a LangGraph-ot, a LlamaIndex-et és a Strands Agents-et, valamint bármilyen modellel. A 2026. júniusi frissítés hozzáadta az MCP-utasításokat és erőforrásokat, a streaminget és a munkamenetkezelést, a feladat közbeni jóváhagyások kérését, valamint az OAuth „on-behalf-of” tokencserét.

Hátrányai: Kizárólag az AWS-en fut, így nem lehet saját szerveren üzemeltetni. Az árazás több AgentCore-szolgáltatás esetében is a felhasználás alapján történik, ami miatt a havi költségek nehezebben jósolhatók meg, mint egy átalánydíj esetében. Az AWS saját példája szerint egy olyan ügynök, amely havonta 50 millió interakciót kezel, egy-egy kereséssel és négy eszközhívással mindegyiknél, havi körülbelül 2 250 dollárba kerül, és ennek több mint a fele a keresésre jut. A szemantikus keresés 18 AWS-régióban érhető el. Minden átjáró csak az Ön által konfigurált MCP-protokollverziókat fogadja el, a megfigyelhetőség pedig a CloudWatch-on keresztül működik, ami külön költséget jelent.

Mit mondanak a valódi felhasználók az Amazon Bedrock AgentCore Gateway-ről?

Egy felhasználói vélemény így szól:

A komplexitás több szempontból is adódik: 1) a felhasználóknak be kell állítaniuk az AWS-hitelesítő adataikat és környezeteiket; 2) a fejlesztőknek teljes mértékben meg kell írniuk és annotálniuk az ügynök kódjukat az AgentCore használatához; és 3) a kontextuskezelés olyan speciális programozási modelleket igényel, amelyek nem minden keretrendszerrel működnek együtt.

5. Composio (A legjobb megoldás az ügynökök és a SaaS-alkalmazások összekapcsolására szerver üzemeltetése nélkül)

A Composio egy felügyelt platform, amely az ügynököket több mint 1 500 alkalmazáshoz csatlakoztatja, többek között a Gmailhez, a Slackhez, a GitHubhoz, a HubSpothoz és a Salesforce-hoz. Nincs szükség szerver üzemeltetésére. Az ügynök vagy az AI-ügyfél egyetlen MCP-URL-hez csatlakozik, és a Composio kezeli az egyes alkalmazásokba való bejelentkezést, az OAuth-folyamatoktól és az API-kulcsoktól a tokenek frissítéséig.

Az átjáró munkájának nagy része a Tool Routerben zajlik. Minden felhasználó számára létrehoz egy munkamenetet a számára szükséges eszközkészletekkel, és a Composio egy hatókörrel rendelkező MCP végpontot ad vissza. A munkameneten belül rögzíthet egy pontos eszközlistát, blokkolhat bizonyos eszközöket, vagy szűrhet MCP-jelzések alapján, például „csak olvasható” vagy „romboló” kategóriák szerint. Az eszköz futásidőben is kereshet a katalógusában, és csak a feladathoz szükséges eszközöket tölti be, ami kicsinek tartja az ügynök kontextusát.

A jogosultságok előírhatják, hogy egy személy minden egyes híváskor vagy munkamenetenként egyszer jóváhagyja az eszközhívásokat, az egyes eszközökre vonatkozó „mindig engedélyezés” vagy „mindig elutasítás” felülírási lehetőségekkel. A munkamenetek felhasználónként jönnek létre, így minden személy csatlakoztatott fiókjai elkülönülnek egymástól, és egy személy több fiókot is csatlakoztathat ugyanahhoz az alkalmazáshoz. Ha egy alkalmazás nem szerepel a katalógusban, de rendelkezik MCP-kiszolgálóval, ingyenesen hozzáadhatja azt egyéni kiszolgálóként.

Együttműködik a Claude-dal, a ChatGPT-vel, a Cursorral, a Claude Code-dal és bármely más MCP-klienssel, valamint olyan keretrendszerekkel, mint a LangChain, a LlamaIndex, a CrewAI és az OpenAI Agents SDK. Többlépéses feladatokhoz a Composio távoli futtatási környezetet kínál, ahol minden végrehajtás a saját, elszigetelt sandboxában fut. A vállalat SOC 2 Type II megfelelőségről és ISO 27001:2022 tanúsításról számol be.

Kiemelkedő jellemzők

Árak

Értékelések

A korlátai: Mivel ez egy felügyelt szolgáltatás, az eszközhívások és a felhasználók tárolt hitelesítő adatai a Composio felhőjén keresztül futnak, kivéve, ha saját felhőalapú telepítést állít be. Amikor az MCP-n keresztül csatlakozik, az SDK eszközhívási hookjai és sémamódosításai nem futnak, és a saját kódjában definiált egyéni eszközök nem érhetők el az MCP végponton. 2026 májusában a Composio nyilvánosságra hozott egy biztonsági incidenst, amely az aktív kapcsolatok körülbelül 0,3%-át érintette – ezek többsége GitHub-kapcsolat volt –, és amely miatt az ügyfeleknek meg kellett változtatniuk az API-kulcsaikat. Vegye figyelembe a jelentést a biztonsági felülvizsgálat során.

Mit mondanak a Composio-ról a valódi felhasználók?

Egy felhasználói vélemény így szól:

Egy felügyelt MCP-platform hatalmas könyvtárral, több mint 1000 alkalmazással, például a Gmail-lel és a Slackkel. A legnagyobb előnye, hogy nem kell minden integrációt saját maga építenie és karbantartania, ráadásul a Composio támogatja a VPC-ben történő saját üzemeltetést és a beágyazott SDK-t is, így rugalmas telepítési lehetőségeket kínál.

Mennyibe kerül egy MCP-átjáró?

Az ár attól függ, hogy fizet-e a felügyelt használatért, vagy saját maga üzemelteti az infrastruktúrát.

A nyílt forráskódú átjárók esetében nincs licencdíj, de a tárhelyért, a karbantartásért és a biztonságért továbbra is fizetnie kell. A menedzselt átjárók esetében az eszközhívások, a keresések, a vezérlőrétegek vagy egyéb használat után számolnak fel díjat.

Az, hogy melyik átjáró olcsóbb, attól függ, hogy mit használ már jelenleg. A Composio és az Amazon Bedrock AgentCore Gateway az infrastruktúra kezelésének nagyobb részét a szolgáltatóra hárítja, és használat alapján számol fel díjat. A Docker MCP Gateway és az IBM ContextForge esetében nincs licencdíj, de a tárhely és a karbantartás költségeit Önnek kell viselnie. A Kong akkor a legköltséghatékonyabb megoldás, ha a csapata már használja a Kongot, mivel ha kizárólag az MCP miatt vezetné be, az új platformmal és licencköltségekkel járna.

Hogyan válasszunk MCP-átjárót?

Az árak szűkítik a listát, de ritkán döntenek helyetted.

Jobb kiindulási pont az a probléma, ami miatt keresni kezdtél. A legtöbb csapat kétféle problémával szembesül: vagy nem látják, illetve nem tudják ellenőrizni, hogy ki melyik eszközt hívja meg, vagy az ügynökeik olyan sok eszközdefiníciót töltenek be, hogy elkezdenek rosszakat választani. Néhányuknál mindkét probléma fennáll.

Ha már tudod, melyik probléma okoz a legnagyobb gondot, akkor tudni fogod, mit kell jól csinálnia az átjárónak, és mely funkciók nélkül is meg tudsz boldogulni.

Kezdje azzal, ahol az ügynökei már futnak

Az ebben az útmutatóban bemutatott öt átjáró ugyanazokat az alapvető funkciókat kínálja, így a döntő tényező általában a már meglévő technológiai környezet.

Ha az ügynökei többnyire SaaS-alkalmazásokon belül, egyedi felhasználók nevében működnek, akkor a Composio jelenti a legnagyobb munkamegtakarítást, mivel az Ön helyett kezeli az egyes felhasználók OAuth-kapcsolatait. Ennek az az ára, hogy ezek a hitelesítő adatok a Composio felhőjében tárolódnak, amit a biztonsági csapatának érdemes lesz áttekintenie.

Azoknak a csapatoknak, amelyek a fejlesztők laptopjain szétszórt, egymástól elszigetelt munkafolyamatokkal küzdenek, a Docker MCP Gateway a természetes első lépés. Alkalmas azoknak a csapatoknak, amelyek már a Docker Desktopot használják, minden szervert saját konténerben futtat, és lehetővé teszi, hogy az egész csapat egy profilt osszon meg. Ha később csapat-szintű irányításra van szükség, külön megbeszélést kell kezdeményeznie a Docker értékesítési csapatával.

Azok a platformcsapatok, amelyek inkább saját infrastruktúrát szeretnének üzemeltetni, az IBM ContextForge felé fognak hajlani. Virtuális szerverei minden csapatnak saját eszközkészletet biztosítanak, és a belső REST- és gRPC-szolgáltatásokat MCP-eszközökké alakíthatják. Emellett a saját üzemeltetéssel járó frissítési, méretezési és ügyeleti feladatok is az Önöké lesznek.

A Kong AI Gateway az MCP-forgalmat ugyanazoknak a szabályoknak veti alá, amelyeket a csapata már az API-k esetében is alkalmaz. Ha SSO-ra vagy platform-auditnaplókra van szüksége, akkor az Enterprise-verzióra kell számolnia, mivel mindkettő kizárólag az Enterprise-verzióban érhető el.

Az AWS-en dolgozó csapatok számára az Amazon Bedrock AgentCore Gateway gondoskodik a teljes felügyeletről, és szemantikus eszközkeresést biztosít az átjárón. Korán tervezze meg a használat alapú számlát, mivel a keresési hívások, az eszközhívások és a CloudWatch mindegyike külön kerül felszámításra.

Ha egy kis csapat számára néhány stabil szervert üzemeltetsz, akkor valószínűleg még nincs szükséged átjáróra. A verziókezelőben tárolt közös konfiguráció és egy titkosadat-kezelő ugyanazt a feladatot elláthatja, amíg nincs szükséged csapatonkénti jogosultságokra vagy központi naplófájlokra.

Mit érdemes ellenőrizni a commit előtt?

Ha kiválasztott egy esélyest, tesztelje azt a saját környezetében, mielőtt bármilyen szerződést aláírna. A funkciókat bemutató oldalak gyakran kihagyják azokat a részleteket, amelyek később fontosak lehetnek, ezért vegye át néhány konkrét kérdést a biztonsági és platformfelelősökkel:

A válaszok általában eldöntik a kérdést. Ha egy átjáró csak a beállításváltozásokat rögzíti, és nem tudja megmutatni, hogy az ügynökei valójában mely eszközöket használták, akkor egy audit során nem fogja kiállni a próbát. Ha pedig úgy csatlakoztatja a szervereit, hogy nem szűri le az eszközlistákat, az ügynökei továbbra is minden eszközdefiníciót betöltenek, így a token-használat változatlan marad.

Hogyan lehet a meglévő MCP-kiszolgálókat átállítani egy átjáróra?

A legbiztonságosabb bevezetés során először egy alacsony kockázatú szervert állítunk át, és a régi útvonalat addig működésben tartjuk, amíg az új megbízhatónak nem bizonyul.

Kezdjük a leltárral

Minden szerver esetében jegyezze fel, ki a tulajdonosa, milyen eszközöket kínál, milyen adatokhoz fér hozzá, és nagyjából hány tokent igényelnek az eszközdefiníciói. Ez egyben a szűrés ideje is. A legtöbb katalógus olyan eszközöket tartalmaz, amelyeket hónapok óta senki sem hívott meg, és ha ezeket a migráció előtt eltávolítja, csökken a felügyelendő terület.

A szerverek csoportosítása bizalmi határok szerint

Helyezze a magánadatokat olvasó, a megbízhatatlan tartalmakat kezelő és az adatokat kifelé továbbító szervereket külön eszközkészletekbe, hogy egyetlen ügynök se rendelkezzen mindhárommal egyszerre. Ez a kombináció tette lehetővé az Invariant Labs GitHub MCP prompt-injection bemutatóját. Ezenkívül győződjön meg arról, hogy az egyes szervereket továbbra is karbantartják. Az eredeti MCP referencia-szerverek közül több, köztük a GitHub és a Slack, ma már archívumban található, és nem kapnak többé frissítéseket.

A csoportok felállítása után indítson egy rövid kísérleti projektet

A kísérleti fázis sikeres lezárása után az írási jogosultsággal rendelkező szervereket egyenként helyezze át. Minden áthelyezés előtt határozza meg a visszaállítási feltételeket, így nem kell az incidens közepén dönteni a visszaállításról. Tartsa fenn a közvetlen konfigurációt, amíg az átjáró útvonal néhány hétig zavartalanul működik, majd vonja vissza a régi hitelesítő adatokat és az ügyfélkapcsolatokat.

Bármelyik átjárót is válassza, egy szabály érvényes. Az MCP specifikáció tiltja a tokenek továbbítását. Az átjárónak kizárólag a számára kiadott tokeneket szabad elfogadnia, és a kliens tokenjének továbbítása helyett a saját, külön engedélyezett hitelesítő adataival kell meghívnia a downstream szervereket. Mielőtt átirányítaná a termelési forgalmat, ellenőrizze, hogy az átjáró konfigurációja megfelel-e ennek a szabálynak.

Hogyan működik a ClickUp egy MCP-átjáróval?

A ClickUp az átjáró mindkét oldaláról csatlakozik az MCP-hez.

A ClickUp-on kívüli AI-alkalmazások, mint például a Claude, a Cursor és a ChatGPT, a ClickUp MCP-kiszolgálón keresztül érhetik el a munkaterületedet, amely – akárcsak bármely más kiszolgáló – az átjáród mögött található. A ClickUp-on belül a Super Agents és a Brain² használhatja az általad csatlakoztatott külső MCP-kiszolgálók eszközeit, és az átjáród is lehet ezek egyike.

Helyezze a ClickUp MCP-kiszolgálót az átjáró mögé

A ClickUp MCP-szerver a https://mcp.clickup.com/mcp címen fut, és minden csomagban elérhető, beleértve a Free Forever csomagot is. Kizárólag OAuth-t fogad el, így az átjárónak soha nem kell személyes API-kulcsokat tárolnia, sem azokat cserélnie, ha valaki kilép. Ha saját klienst fejleszt, annak támogatnia kell az OAuth 2.1-et PKCE-vel. A ClickUp engedélyezési listát vezet a jóváhagyott kliensekre vonatkozóan, így minden olyan klienst, amely nem szerepel a listán, először felülvizsgálatra kell benyújtani.

A csatlakozás után az ügynökök feladatokat hozhatnak létre és irányíthatnak tovább, állapotfrissítéseket készíthetnek a feladatok és a dokumentumok alapján, rögzíthetik az eltöltött időt, kereshetnek feladatok, dokumentumok és megjegyzések között, valamint összefoglalhatják a csevegési szálakat. Így az ügynökök maguk is megkereshetik a projekt kontextusát, anélkül, hogy azt minden parancsba be kellene illeszteniük.

Az átjáró mögött érdemes közelebbről megvizsgálni a sebességkorlátozásokat. A korlát az egész munkaterületre vonatkozik, és minden csatlakozó kliens ugyanabból a megosztott keretből merít. Az Everything AI kiegészítő nélkül a ClickUp 24 órás gördülő időszakonként korlátozza az MCP-hívások számát, a Free Forever csomagban 100-tól az Enterprise csomagban 5 000-ig.

A kiegészítő használatával az MCP-kérelmek a nyilvános API percenkénti korlátait követik. Ezek a Free Forever, Unlimited és Business csomagoknál percenként 100 kérelemtől az Enterprise csomag 10 000 kéreleméig terjednek. A ClickUp egyelőre nem jeleníti meg az MCP-használatot. Ha több csapat is egy átjárón keresztül éri el a ClickUp-ot, állítson be csapatonkénti korlátokat az átjárón, hogy egy forgalmas ügynök ne merítse ki a többiek számára rendelkezésre álló keretet.

Csatlakoztassa a Super Agenteket az MCP-kiszolgálóihoz

Fordított irányban pedig a ClickUp App Centerből csatlakoztathat külső MCP-kiszolgálókat, akár az egész munkaterületre, akár csak saját magára vonatkozóan. Az adminisztrátorok döntik el, ki adhat hozzá egyes kapcsolattípusokat. A kiszolgáló csatlakoztatása után kiválaszthatja, hogy az egyes szuperügynökök a kiszolgáló mely eszközeit kapják meg: az összeset, vagy csak bizonyosakat. Ez ugyanaz az elv, mint az útmutató korábbi részében említett eszközlisták szűkítése, csak most a munkaterületen belüli ügynökökre alkalmazva.

Ha az a szerver, amelyhez csatlakozik, egyben az átjárója is, először ellenőrizzen két részletet. A ClickUp változó felhőalapú IP-címekről csatlakozik, ezért egy IP-engedélyezési lista nem engedi át. Az átjárónak emellett szüksége van egy OAuth-val vagy API-kulccsal védett nyilvános URL-re is. A ClickUp munkaterületi ellenőrzési naplója rögzíti, ki csatlakozott, frissített vagy bontotta a kapcsolatot egy szerverrel. Ahhoz, hogy nyomon követhesse, melyik ügynök mely eszközöket hívta meg valójában, szüksége lesz az átjáró naplófájljaira.

Kövesse nyomon a bevezetést a ClickUp-ban

A fenti leltározási és kísérleti lépések során számos apró döntés születik, amelyekről könnyen elveszítheti a fonalat. Adja hozzá az egyes szervereket feladatként egy listához, egyéni mezőkkel a tulajdonos, az adat-hozzáférés, a bizalmi csoport és a tokenköltség megadásához. Ezután írja le a visszavonási kritériumokat egy dokumentumban, amelyet minden migrációs feladathoz kapcsoljon. Ha egy kísérlet sikertelen, vagy egy upstream szervert archiválnak, a tulajdonos és a teljes előzmények egy helyen találhatók.

Válassza ki az Ön problémájához leginkább megfelelő átjárót!

Az útmutató minden szakasza ugyanahhoz a két feladathoz vezet vissza.

Az első az irányítás: egy végpont, egy hely a hitelesítő adatok tárolására, és egy nyilvántartás arról, hogy melyik ügynök melyik eszközt hívta meg. Az ebben az útmutatóban bemutatott öt átjáró valamilyen formában mind ezt biztosítja, a legnagyobb különbség pedig abban rejlik, hogy az infrastruktúra mekkora részét üzemelteti saját maga. A második feladat az, hogy az egyes ügynökök eszközlistáját rövidre tartsuk, és egy átjáró ebben csak akkor segít, ha szűrést vagy keresést állít be.

Mielőtt bármit aláírna, számolja össze az eszközeit, és mérje meg, hány tokent használnak azok definíciói.

Szűrd ki azokat, amelyeket senki sem hív meg, a többit pedig csoportosítsd a bizalmi határok szerint, majd először egy írásvédett szervert helyezz át az átjárón keresztül. Ha a ClickUp is ezek között a szerverek között van, csatlakoztasd a ClickUp MCP-kiszolgálón keresztül, és nézd meg, hogyan kezeli az ügynök a feladataidat, a dokumentumaidat és a csevegéseidet a teljes projektkontextusban.

Gyakran feltett kérdések az MCP-átjárókról

Mi a legjobb MCP-átjáró?

Az Ön számára legmegfelelőbb MCP-átjáró attól függ, hogy az ügynökei jelenleg hol futnak. A Docker MCP Gateway a helyi fejlesztéshez alkalmas. Az IBM ContextForge azoknak a csapatoknak felel meg, amelyek saját szerveren szeretnék üzemeltetni a rendszert. A Kong AI Gateway azoknak a csapatoknak felel meg, amelyek már a Kongot használják, az Amazon Bedrock AgentCore Gateway pedig az AWS-en futó ügynökökhöz alkalmas. A Composio azoknak az ügynököknek felel meg, amelyek számos SaaS-alkalmazásban működnek. Szabályozott iparágak esetében keressen saját szerveren történő üzemeltetést vagy privát telepítési lehetőséget, eszközönkénti hozzáférés-vezérlést, valamint az egyes eszközhívások naplózását.

Az MCP egy API-átjáró?

Nem. A Model Context Protocol egy olyan specifikáció, amely meghatározza, hogyan kapcsolódnak az AI-alkalmazások az eszközökhöz és az adatokhoz. Az MCP-átjáró egy, ezen a specifikáción alapuló szoftver. Az ügynökök és az MCP-kiszolgálók között helyezkedik el, és kezeli a hozzáférést, a hitelesítő adatokat és a naplózást. Úgy működik, mint a HTTP és egy API-átjáró: a HTTP határozza meg a kérésekre vonatkozó szabályokat, az átjáró pedig eldönti, mely kérések jutnak át.

Szüksége van egy MCP-átjáróra?

MCP-átjáróra akkor van szükséged, ha szabályozni szeretnéd, hogy ki mely eszközöket hívhatja meg több szerveren keresztül, vagy ha központi nyilvántartást szeretnél vezetni az ügynökök tevékenységéről. Ha egy kis csapat néhány stabil szervert üzemeltet, akkor a verziókezelőben tárolt megosztott konfiguráció és egy titkos adatkezelő nagyjából ugyanazt a feladatot látja el. Az átjáró akkor kezd megtérülni, ha csapatonkénti eszközhozzáférésre van szükséged, vagy egy helyről szeretnéd kezelni a hitelesítő adatokat.

Biztonságosak-e az MCP-kiszolgálók az átjáró mögött?

Az átjáró megkönnyíti az MCP-kiszolgálók biztonságának biztosítását. Önmagában azonban nem teszi őket biztonságossá. Egy helyen tárolja a hitelesítő adatokat, korlátozza, hogy az egyes hívók mely eszközöket használhatják, és központilag naplózza a hívásokat. A parancsbefecskendezés továbbra is megjelenhet egy megbízható kiszolgálón keresztül, ahogyan azt az Invariant Labs a GitHub MCP-kiszolgálóján bemutatta. Azokat az eszközöket, amelyek magánadatokat olvasnak, megbízhatatlan tartalmakat kezelnek vagy adatokat küldenek ki, külön eszközkészletekben kell tartani. Győződjön meg arról, hogy az átjáró soha ne továbbítsa az ügyfél tokenjét. És ne használjon olyan szervereket, amelyek már nem kapnak frissítéseket.

Az eszközkeresés helyettesíti-e a hozzáférés-vezérlést?

Nem. Az eszközkeresés határozza meg, hogy egy ügynök mely eszközöket lát egy feladathoz. A hozzáférés-vezérlés dönti el, hogy az ügynöknek engedélyezett-e azok meghívása. Az Amazon Bedrock AgentCore Gateway például külön funkcióként kezeli a szemantikus keresést és a hitelesítést. A keresést csak azokon az eszközökön futtassa, amelyeket a hívó fél használhat, és ellenőrizze újra a jogosultságokat, amikor az eszköz ténylegesen fut. Ha egy eszköz elrejtése a keresés elől az egyetlen védelme, akkor az nem védett.

Mit kell rögzítenie az MCP-átjáró auditnaplóinak?

Az MCP-átjáró auditnaplóinak rögzíteniük kell, hogy ki kezdeményezte az egyes hívásokat, melyik ügynök és eszköz vett részt benne, melyik szerver kezelte azokat, engedélyezték-e vagy elutasították-e a hívást, mikor történt, és mi volt a válasz. A Kong AI MCP Proxy bővítménye például minden engedélyezett és elutasított eszköz-hozzáférési kísérletet naplóz. Vásárlás előtt győződjön meg arról, hogy a naplók az egyes eszközhívásokat is rögzítik, és nem csak a fiók- és konfigurációs változásokat, majd ellenőrizze, mennyi ideig tárolják őket, és exportálhatók-e.