MCP ar funkcijų kvietimas: protokolas nepakeičia vykdymo logikos

MCP ir funkcijų kvietimas sprendžia skirtingas integravimo užduotis: MCP apibrėžia, kaip DI programa per klientą keičiasi pranešimais su išoriniu serveriu, o funkcijų kvietimas – kaip modelio prašymas perduodamas vykdyti ir rezultatas grąžinamas modeliui. MCP architektūros aprašas pagrindinei programai priskiria po atskirą klientą kiekvienam serveriui ir palieka jai sprendimą, kaip naudoti modelį bei gautą kontekstą.

Vienai valdomai DI programai su jos pačios funkcijomis paprastai pakanka tiesioginio funkcijų kvietimo; kai tą pačią išorinę integraciją turi pasiekti kelios suderinamos programos, verta svarstyti MCP serverį. OpenAI funkcijų kvietimo vadovas aprašo modelio pateiktą kvietimą, programos pusėje atliekamą vykdymą ir rezultato perdavimą atgal modeliui. Abu mechanizmai gali būti naudojami kartu, nes apima skirtingas tos pačios sistemos ribas.

Ką apibrėžia kiekvienas mechanizmas

Funkcijų kvietimo atveju programa pateikia modeliui funkcijos pavadinimą, aprašą ir argumentų schemą. Modelis gali grąžinti prašymą su argumentais, bet tas atsakymas dar nereiškia, kad duomenys perskaityti ar veiksmas atliktas. Programa turi parinkti atitinkamą kodą, jį paleisti ir susieti gautą rezultatą su konkrečiu modelio kvietimu; tik tada modelis gali tęsti atsakymą, remdamasis grąžintu turiniu.

MCP aprašo kitą sąveiką: pagrindinė DI programa palaiko MCP klientą, o šis bendrauja su įrankius ar kontekstą teikiančiu serveriu. Serveris gali skelbti įrankius, išteklius ir užklausų šablonus. Protokolas apima pranešimų struktūrą bei ryšio būdus, įskaitant vietinių procesų standartinę įvestį ir išvestį bei nuotoliniam ryšiui skirtą HTTP. Jis nenumato vienos privalomos programos logikos, pagal kurią konkretus įrankis pateikiamas modeliui ar jo rezultatas įtraukiamas į pokalbį.

Svarbi ir vykdymo vieta. Tiesioginės funkcijos atveju veiksmą atlieka programos kodas arba jo iškviesta paslauga. MCP atveju programos klientas išsiunčia prašymą, o serverio realizacija atlieka paskelbtą įrankio veiksmą. Pagrindinė programa vis tiek sprendžia, ar konkretų įrankį siūlyti modeliui ir kaip panaudoti grąžintą atsakymą.

Dvi sekos nuo užklausos iki atsakymo

Tiesioginis funkcijų kvietimas: naudotojo užklausa → programa pateikia modeliui funkcijų aprašus → modelis grąžina pasirinktos funkcijos pavadinimą ir argumentus → programa paleidžia funkciją → jos rezultatą susieja su kvietimu ir perduoda modeliui → modelis tęsia atsakymą. Tarp programos ir jos pačios funkcijos MCP serveris nereikalingas. Modelio sugeneruoti argumentai čia yra vykdymo įvestis, o ne įrodymas, kad naudotojas turi teisę atlikti prašomą veiksmą.

Tarkime, sąlyginė Lietuvos užsakymų sistema turi funkciją, kuri pagal užsakymo identifikatorių grąžina būseną. Modelis gali pateikti identifikatorių ir paprašyti paieškos, tačiau programa prieš kreipdamasi į duomenų bazę turi nustatyti, kuriam naudotojui tas užsakymas priklauso. Vien argumentų schemoje aprašytas identifikatoriaus formatas šio klausimo neišsprendžia.

MCP integracija: naudotojo užklausa → pagrindinė programa per MCP klientą gauna serverio įrankių sąrašą → tinkamas galimybes pateikia modeliui → modelio prašymą programa perduoda MCP klientui → klientas siunčia serveriui tools/call su įrankio pavadinimu ir argumentais → serveris grąžina rezultatą → programa jį perduoda modeliui. Protokolas nusako kliento ir serverio apsikeitimą pranešimais; modelio kvietimo sujungimą su šiuo apsikeitimu atlieka integracijos logika.

Nuotolinis MCP serveris gali aptarnauti skirtingų pagrindinių programų klientus. Jei sąlyginį užsakymų įrankį naudotų vidinis asistentas ir kitas suderinamas klientas, serveris galėtų pateikti jiems bendrą įrankio sąsają. Tačiau kiekvienos programos pokalbio eiga ir kiekvieno naudotojo teisės turi būti įvertintos atskirai: bendras įrankio pavadinimas nereiškia bendro leidimo matyti duomenis.

Kada MCP ir funkcijų kvietimas veikia kartu

Derinyje modelis vis tiek pasirenka veiksmą iš jam prieinamų įrankių, o programa nusprendžia, kaip tą prašymą įvykdyti. Jei įrankį pateikia MCP serveris, programa jį pasiekia per savo MCP klientą ir po serverio atsakymo grąžina rezultatą į modelio darbo eigą. Tokia schema leidžia programai vienoje pokalbio eigoje naudoti tiek savo funkcijas, tiek išorinio teikėjo įrankius.

Svarbu nepainioti įrankio aprašo su jo realizacija. Tą patį užsakymo būsenos paieškos tikslą galima įgyvendinti vietine funkcija arba MCP serveryje, bet šie pasirinkimai keičia, kur laikomas vykdymo kodas, kaip pasiekiama paslauga ir kas prižiūri jos sąsają. Pats modelio gebėjimas paprašyti įrankio nenusprendžia, kurioje sistemoje bus tikrinama prieiga prie užsakymo.

Pasirinkimo medis pagal klientus ir įrankius

• Viena valdoma programa ir jos pačios įrankiai. Rinkitės tiesioginį funkcijų kvietimą, jei funkcijų aprašus, vykdymo kodą ir prieigos taisykles prižiūri ta pati komanda. Papildomas serveris vien dėl modelio kvietimo nėra būtinas.
• Viena programa naudoja jau esantį MCP serverį. Prijunkite serverį per MCP klientą ir įtraukite tinkamus jo įrankius į modelio darbo eigą. Tai neatima galimybės kitas, vietines funkcijas vykdyti tiesiogiai.
• Kelios programos naudoja tą pačią išorinę integraciją. Bendras MCP serveris gali pateikti joms vienodą įrankių aptikimo ir kvietimo sąsają. Kiekviena programa atskirai tvarko, ką siūlo savo modeliui ir kaip susieja rezultatą su naudotojo užklausa.
• Daug įrankių, bet vienas klientas. Vien įrankių gausa savaime nereikalauja MCP. Sprendimą lemia tai, ar įrankių realizaciją reikia atskirti nuo programos ir pakartotinai naudoti per standartinę sąsają.

Jei planuojamas nuotolinis serveris keliems klientams, svarbi ir ryšio riba: klientai turės pasiekti serverį ir pateikti jam tinkamus įgaliojimus. Vietinis MCP serveris, su kuriuo programa bendrauja per standartinę įvestį ir išvestį, sprendžia kitokį diegimo klausimą. Todėl vien MCP pasirinkimas dar nepasako, ar integracija bus bendra kelioms programoms.

Kas atsako už veiksmą, teises ir rezultatą

Įrankio schema aprašo galimus argumentus, bet neperkelia atsakomybės už naudotojo teises modeliui. MCP įrankių specifikacija serveriams nustato pareigą tikrinti įvestį ir taikyti prieigos kontrolę, o klientams rekomenduoja tikrinti įrankio rezultatą prieš perduodant jį modeliui. Tiesioginio funkcijų kvietimo atveju šiuos patikrinimus turi užtikrinti funkciją vykdanti programa ir jos naudojamos paslaugos.

Užsakymų pavyzdyje būtina atskirai patikrinti, ar argumentas atitinka reikiamą formatą, ar konkretus naudotojas gali matyti nurodytą užsakymą ir kokią grąžintos būsenos dalį galima įtraukti į modelio kontekstą. Net jei serveris grąžina techniškai taisyklingą atsakymą, programa turi nuspręsti, ar jį rodyti būtent šioje pokalbio eigoje. Ši riba ypač svarbi tada, kai vieną nuotolinį įrankį pasiekia keli skirtingi klientai.

Taip pat skaitykite:

• RAG bazės atnaujinimas: naujas laukas senų vektorių nepakeičia