MCP vagy function calling? A csere nem mindig egyszerűsítés

Ha néhány saját műveletet csak egy MI-alkalmazás használ, többnyire elegendő a function calling: a közvetlen függvényhívásnak kevesebb kapcsolódási pontja van. Az OpenAI függvényhívási útmutatója szerint az alkalmazás átadja a műveletek leírását a modellnek, végrehajtja a kért hívást, majd visszaküldi az eredményt. Az MCP-re váltás ilyen helyzetben külön szerver és klienskapcsolat kezelését hozza be, ezért a kisebb kódismétlés önmagában nem biztos előny.

Az MCP akkor kerül előtérbe, ha ugyanazokat a képességeket több kliensnek szeretnéd felkínálni, vagy a meghívható eszközök mellett adatforrásokat és újrahasználható promptokat is közzétennél. Az MCP architektúraleírása a kliens és a szerver közti felfedezést, a tools, resources és prompts primitíveket, a szállítási módokat és az értesítéseket is lefedi. A választás tehát arról szól, hol legyen az integráció közös határa, és ki viselje annak működtetését.

Más rétegben dolgoznak

A függvényhívásnál a modell számára látható művelet leírása rendszerint nevet, feladatot és bemeneti sémát tartalmaz. A modell hívási szándékot és argumentumokat ad vissza; a tényleges kódot az alkalmazás futtatja. Ugyanez az alkalmazás dönti el, melyik felhasználó nevében történik a végrehajtás, hogyan ellenőrzi a bemenetet, és milyen eredményt ad vissza a modellnek. Ezek a felelősségek akkor is megmaradnak, ha a modell több egymást követő műveletet kér.

Az MCP a képességet kínáló program és az azt használó kliens közötti szerződést szabályozza. A szerver eszközöket, olvasható erőforrásokat és promptokat tehet elérhetővé; a kliens lekérdezheti a felkínált képességeket és eszközöket hívhat. A modellhez vezető utat továbbra is a fogadó alkalmazás alakítja ki. Ezért az MCP bevezetése nem váltja ki automatikusan a modell eszközhívásainak kezelését: a két mechanizmus ugyanabban a rendszerben is egymásra épülhet.

Döntési tábla az integráció tényleges költségéről

A döntésnél a kliensek száma fontosabb, mint a függvények puszta száma. Sok belső művelet is maradhat egy alkalmazáson belül, míg néhány jól elkülönített művelet megosztása értékes lehet több kliens között.

• Integrációk száma. Egy alkalmazás saját függvényeinél a közvetlen hívási ciklus kevés összetevőt igényel. Ha több MI-kliens ugyanazt a külső szolgáltatást használja, közös MCP-szerver csökkentheti a kliensekben külön fenntartott kapcsolódási logikát. A szerver üzemeltetése viszont új közös függőséggé válik.
• Eszközfelderítés. Állandó készletnél az alkalmazás maga adhatja át a megfelelő függvénysémákat. Változó kínálatnál az MCP lekérdezhető eszközlistája és a változásokról küldhető értesítés hasznos. A függvények késleltetett betöltése a közvetlen hívási ciklus mellett is lehetséges, de önmagában nem hoz létre más kliensek számára elérhető szervert.
• Hordozhatóság. Ha az integráció egyetlen alkalmazás része, a helyi séma gyakran megfelelő határ. MCP-t támogató különböző kliensek ugyanahhoz a szerverhez kapcsolódhatnak, de a támogatott primitíveket és a felhasználói élményt kliensenként ellenőrizni kell. A protokoll közös felületet ad, nem azonos alkalmazásviselkedést.
• Állapotkezelés. A beszélgetés és a felhasználói munkafolyamat állapota közvetlen hívásnál az alkalmazásban marad. Az MCP leírt adatcseréje állapotmentes kérésekre épül: a kérés maga hordozza a feldolgozáshoz szükséges protokolladatokat. Ettől a mögöttes üzleti műveletek állapota, az ismételt hívások és a hibák kezelése továbbra is tervezési feladat.
• Hitelesítés. Helyi függvénynél a meglévő alkalmazás jogosultsági ellenőrzése használható. Különösen távoli, több kliens által elérhető szervernél meg kell határozni, melyik kliens és felhasználó melyik művelethez fér hozzá. A kapcsolat módja ezért közvetlenül befolyásolja az integráció munkáját.
• Üzemeltetés. A közvetlen függvénykód az alkalmazás kiadási, naplózási és hibakeresési folyamatában maradhat. Megosztott szervernél külön figyelmet kér a rendelkezésre állás, a protokollverziók együttműködése, az eszközlista változása és a hibák követése. Ennek ára akkor térülhet meg, ha valóban megszűnik párhuzamos kliensoldali fejlesztés.

A helyi és a távoli szerver más jogosultsági feladat

Az MCP nem teszi kötelezővé a jogosultsági mechanizmus bevezetését. Az MCP jogosultsági specifikációja opcionálisnak nevezi az autorizációt; HTTP-alapú kapcsolatnál a leírt eljárás követését javasolja, míg stdio kapcsolatnál a hitelesítő adatok környezetből történő átvételét. A helyi szerver és a hálózaton elérhető szerver így eltérő bizalmi határt hoz létre.

Távoli kapcsolatnál a szervernek nem elég tudnia, hogy egy kérés technikailag végrehajtható. Azt is ellenőriznie kell, milyen felhasználói vagy szolgáltatási jogosultsággal érkezik, különösen ha több kliens ugyanazt az üzleti API-t éri el. Az eredeti alkalmazásban meglévő szerepkörök nem kerülnek át maguktól az új rétegbe. Helyi stdio szervernél sem mellékes, hogy a folyamat milyen környezeti hitelesítő adatokhoz és fájlokhoz jut hozzá.

Migrációs ellenőrzőlista

Ha a több kliens vagy a külön kezelendő erőforrások miatt az MCP mellett döntesz, a meglévő függvénysémák egyszerű átmásolása kevés. A közös felületnek önállóan értelmezhető bemenetet, kimenetet és hozzáférési szabályt kell adnia.

1. Válaszd szét a valóban megosztható műveleteket az eredeti alkalmazás belső állapotától függő lépésektől.
2. Rögzítsd minden eszköz bemeneti sémáját, eredményét, hibaeseteit és a végrehajtáshoz szükséges jogosultságot.
3. Az olvasható adatot erőforrásként, a végrehajtandó műveletet eszközként modellezd; promptot csak akkor tegyél közzé, ha ugyanaz a sablon több kliensben is értelmes.
4. A célkliensek alapján válassz helyi stdio vagy távoli Streamable HTTP kapcsolatot, majd döntsd el, hol tárolódnak és hol érvényesülnek a hitelesítő adatok.
5. Határozd meg, hogyan frissül a kliensek eszközlistája, hogyan kezelik a támogatott protokollverziókat, és mi történik sikertelen vagy megismételt hívásnál.
6. Próbáld ki a tényleges célklienssel a képességek felderítését, a jogosultsági hibát, a művelet eredményét és annak visszajutását a modellhez.

Ha az új szerver kizárólag egy alkalmazás változatlan függvényeit szolgálná ki, a fenti feladatokhoz kevés újrahasználat társul. Több, önállóan fejlődő kliens esetén viszont a szerver szerződése külön helyre teheti a közös műveletek karbantartását; ekkor a migráció valódi nyeresége a megosztott integráció, nem a függvényhívási ciklus eltűnése.