Megjelentek az AWS MCP szerverei - Áttekintő

Bevezető: Hogyan jutunk el a monolitikus AI rendszerektől az MCP-ig?

A monolitikus architektúra nagy hátránya, hogy szoros függőségi viszonyok alakulnak ki a folyamatok között, nehezen tudunk cserélni, frissíteni ezekben a rendszerekben. Erre a nehézségre a microservices architektúra született válaszként. Ezt a mintát elég pontosan át tudjuk vetíteni az AI világra is: a Dense FFN-re (Feedforward Neural Network) például alternatíva a MoE (Mixture of Experts) FFN , ami a szoros függőségi viszonyt oldja fel és egy load balancer segítségével osztja ki a feladatot kisebb, speciálisabb modelleknek.

Ebbe a mintába illeszkedik az Agentic AI is, viszont itt nem alternatíváról van szó, hanem augmentációról, az agent ugyanis egy lokális kiterjesztése egy modellnek ami akár egy távoli erőforráson is futhat, ha az agent kérdez akkor a modell válaszol. Itt tehetünk egy különbséget a két viselkedés között: az agent proaktív, tehát képes loopban működni, észlelni a környezetet és az észlelés tükrében a következő műveletet felmérni és végrehajtani. Ezzel szemben a Generatív AI reaktív, válaszol egy kérdésre, generál egy képet vagy videót. Agentic AI-ból több típus is létezik, a jelenleg legfejlettebb verzió a Learning Agent:

Egy ilyen agent több modullal rendelkezik, ezeknek mindegyike más és más feladatért felel. Ezzel a moduláris rendszerrel számon tudja tartani a környezet állapotát, a múltban végrehajtott feladatok következményeit illetve fel tudja mérni a következő feladat megoldását és annak hatásait is megpróbálja előre jelezni. Az agent viszont csak egy kiterjesztése a modellnek, ami stateless tehát minden új üzenetváltással az egész kontextust kell kommunikálnia az agentnek a modell felé. Modell oldalon születik egy válasz a kontextus alapján amit az agent visszakap, ez alapján fut a következő ciklus.

Ha ennek a folyamatnak két szereplője van, a mérleg még jócskán a modell oldalára billen, ugyanis a modellnek tudnia kell hogy milyen eszközökkel kell megoldani az agentre kirótt feladatot. A modellben folyószövegként szerepelnie kell ennek a tudásnak, ez a tudás pedig a tanítás során kerül be ami igen hosszas és rendkívül költséges folyamat.

Ez probléma, ugyanis ebben a felállásban nem tudunk elég gyorsan alkalmazkodni az eszközök fejlődéséhez. Az eszközök ebben az esetben bármilyen külső szoftvert jelentenek amiket egy GUI, CLI, API segítségével tudunk használni. Erre keres megoldást az MCP, amire általában egy virtuális USB csatlakozóként szokás hivatkozni. A rendeltetése az, hogy a kontextusban tudjuk minél hatékonyabban szállítani az eszközök használatára vonatkozó tudást, legyen ez maga a használat vagy a háttértudás, forrás.

Az MCP-t is tudjuk tovább bontani, ki tudunk alakítani egy szerver és kliens oldalt: a szerver lokálisan is futhat akár egy konténerben vagy egy távoli erőforráson, a kliens pedig az agent mellett: így az agentet egyszerűen és könnyen tudjuk konfigurálni a klienseinkez.

Hogyan képzeli el az AWS az MCP integrációt?

Vitatott, hogy jó ötlet-e az infrastruktúránkat bármilyen szinten is AI-ra bízni. Hogy erre a kérdésre választ kapjunk végignéztük a 60 darab MCP szervert, a kollégáim pedig Proof of Concept projektjeiken keresztül kísérleteztek az AWS EKS MCP Serverrel és sok mással, de megnéztük a Prompt Library-t is (ezeket a beszámolókat külön cikkekben tudod elolvasni az oldalunkon). De miért is van szükség 60 különböző MCP szerverre?

A bevezetőből már sejtheted, hogy az MCP a kontextuson keresztül kommunikál ami az esetek többségében rendkívül limitált, arról nem is beszélve hogy minél nagyobb a terjedelme, annál költségesebb. Ebből az következik, hogy a sok MCP sok adatot fog küldeni az eszközök használatáról és leírásáról, aminek mellékhatása a hallucináció és a költségek növekedése, ezért érdemes csak a legszükségesebbeket használni.

Az AWS Labs nyolc kategóriába rendezi az MCP szervereit, a dokumentációtól az infrastruktúrán át a költség optimalizációig, a leírások érthetőek és jól strukturáltak, a sémakövetés miatt pedig gyorsan lehet bennük tájékozódni. Általános megfigyelésem viszont, hogy azoknál a szervereknél amik képesek írásra, tehát változtatni képesek az infrastruktúrát, szinte kivétel nélkül óvatosságra intenek a szerzők, kifejezetten nem ajánlják a prodon való használatot, főként sandbox és POC projektekre ajánlják.

Agentnek az Amazon Q Developert vagy Kiro-CLI-t használtuk. A kommunikáció vagy STDIO-n vagy SHTTP-n kereszül működik, ez a szervertől függ. A szerverek többsége fel van készítve bizonyos környezeti változók és argumentek beállítására, így allow- és deny-listet is megadhatunk amikkel tudjuk szabályozni az írás és olvasási műveleteket vagy az érzékeny adatokhoz való hozzáférést.

A konfigurációkat a ~/.aws/amazonq/mcp.json alatt tudjuk beállítani. Minden szerver más és más paraméterekkel rendelkezik, ha szeretnénk a szerver képességeiről többet tudni, érdemes nem csak a features, hanem a tools listát is végignézni amiből egy pontosabb képet kapunk.

Konkrét megoldások az AWS-től

A két alapvető szerver az AWS API MCP Server és az AWS Knowledge Base MCP Server. Ezek segítenek az agentnek az AWS CLI-t használni és a hivatalos dokumentációkhoz hozzáférni. Több átfedés is felfedezhető az MCP-k között, a megoldások viszont változnak. A leginkább kompetens és egyik legfrissebb szerver az AWS Cloud Control API MCP Server, ami mint megvalósításban mint képességekben az egyik legérdekesebb.

A megoldás lényegében az eszközök használatát tokenek megszerzéséhez köti, az agentnek így a teljesítenie kell az előfeltételeket, mint az adatgyűjtés vagy előkészítés, így hatékonyabban képes ellátni a komplex feladatokat. Ez egy általános szerver, CRUDL műveleteket végez minden létező erőforráson az AWS-ben.

Egy másik egyedi megoldás a Core MCP Server, ami proxyként működik. A használatához meg kell határozni role-okat, ezeket szintén környezeti változóként tudjuk megadni a konfigurációban. A dokumentációból kiderül, hogy melyik role milyen további MCP szervereket fog használni. Hasznos lehet ha nem szeretnénk a lokális mcp.json konfigurációt állandóan változtatni.

Az utolsó kakukktojás a bridge MCP szerverek, ezek API mapperként működnek, emiatt nagyon kell vigyázni a jogosultságaikkal és a kezelésükkel. Ilyen a AWS Lambda MCP Server, AWS Step Functions Tool MCP Server és az Amazon SNS SQS MCP Server. Előnyük hogy használatukkal az AWS hálózaton belül marad minden elérés az erőforrások irányába anélkül, hogy a nyilvános hálózatra csatlakoznánk. Biztonsági szempontból ez a megközelítés szétválasztja a feladatköröket: a modell meghívhatja a Lambda-függvényeket, de nem fér hozzá közvetlenül a többi AWS-szolgáltatáshoz. Az ügyfélnek csak olyan AWS-hitelesítő adatokra van szüksége, amelyekkel a Lambda-függvényeket tudja meghívni. A Lambda-függvények ezután – a saját szerepkörük jogosultságait használva hozzáférhetnek más AWS-szolgáltatásokhoz.

Összegzés

Az AWS rengeteg szervert jelentetett meg egyszerre, céljuk és funkcionalitások sok esetben nagyon eltérő viszont átfedésekben is bővelkednek. Ennek az egyik oka lehet az, hogy az MCP egy friss technológia sok hibával, ami hétről hétre változik akár alapjaiban is.

A leghasznosabb szerverek:

• AWS API MCP Server (az agent egyszerű CLI használatához)
• AWS Knowledge MCP Server (kutatáshoz és információ gyűjtéshez)
• AWS Cloud Control API MCP Server (komplexebb műveletekhez, szoros korlátok között)

Specifikus feladatokhoz érdemes tenni egy próbát az erőforrásoknak dedikált szerverekkel fokozott óvatossággal, a dokumentációban például javasolják a AWS_API_MCP_PROFILE_NAME beállítását, így könnyebb kezelni az jogosultságokat és nyomon követni az MCP aktivitását.

Források:

• AWS MCP elérhető szerverek
• Controlled Tool Orchestration
• Model Context Protocol
• Hangvezérelt AI asszisztens készítése - az MCP és az AWS környezet
• AI Agents
• Mixture of Experts
• Granite 4.0 - IBM Granite

Foglalj egy ingyenes konzultációt és nézzük meg, hogy a Code Factory csapata miben tud segíteni neked / nektek! A szolgáltatásaink listáját itt találod meg!