Atsakymas: MCP yra atviras protokolas, leidžiantis DI programai vienodu formatu atrasti ir naudoti išorinių sistemų įrankius, duomenų šaltinius bei paruoštas instrukcijas. Supaprastinta architektūra: ```text Darbuotojas ↓ DI programa arba agentas ↓ MCP klientas ↓ MCP serveris ↓ CRM / ERP / dokumentai / API ``` MCP serveris veikia kaip kontroliuojamas tarpininkas. Jis gali pateikti agentui, pavyzdžiui, šiuos įrankius: - `rasti_klienta` — perskaityti vieno kliento informaciją; - `sukurti_crm_pastaba` — įrašyti patvirtintą pastabą; - `gauti_saskaitos_busena` — patikrinti, ar sąskaita apmokėta; - `rezervuoti_laika` — sukurti įrašą kalendoriuje; - `ieskoti_vidineje_politikoje` — rasti atsakymą dokumentų saugykloje. Agentas mato įrankio pavadinimą, paaiškinimą ir leistinus parametrus. Jis neturi žinoti visų vidinės sistemos techninių detalių.

Atsakymas: MCP gali padėti centralizuoti prieigą, tačiau saugumas priklauso nuo serverio, autorizacijos, įrankių ribų ir visos agento architektūros. Oficialioje MCP autorizacijos specifikacijoje nuotolinėms HTTP integracijoms aprašomas OAuth 2.1 pagrįstas procesas, prieigos rakto susiejimas su konkrečiu serveriu ir draudimas nepatikrintus raktus perduoti kitoms sistemoms. Praktiniame diegime būtina: - kiekvienam serveriui suteikti minimalias teises; - atskirti skaitymo ir rašymo įrankius; - naudoti vartotojo tapatybę, o ne vieną bendrą paskyrą; - jautriems veiksmams reikalauti žmogaus patvirtinimo; - tikrinti visus įrankio parametrus; - registruoti kvietimą ir rezultatą; - izoliuoti vietinius MCP serverius; - neįdiegti nepatikrintų bendruomenės serverių į gamybos aplinką. OWASP MCP saugumo gairėse aprašomi įrankių užnuodijimo, perteklinių teisių, duomenų nutekėjimo ir tiekimo grandinės pavojai. Platesnį kontrolės sąrašą rasite mūsų DI agentų saugumo vadove.

Kas yra MCP: kaip DI agentas prisijungia prie CRM, ERP ir dokumentų

Q: Kokias galimybes MCP pateikia agentui?

Atsakymas: Pagrindinės MCP galimybės paprastai skirstomos į įrankius, išteklius ir paruoštas užklausas. | MCP elementas | Paskirtis | Verslo pavyzdys | | ----------------------------- | ------------------------------------- | ----------------------------------- | | Įrankiai (tools) | atlikti apibrėžtą veiksmą | sukurti užduotį CRM | | Ištekliai (resources) | pateikti kontroliuojamą informaciją | perskaityti produkto katalogą | | Paruoštos užklausos (prompts) | pasiūlyti standartinį darbo scenarijų | parengti mėnesio pardavimų apžvalgą | Oficiali MCP įžanga protokolą pristato kaip būdą kurti programas, kurios DI modelius jungia su išoriniais duomenimis ir įrankiais. Praktinė nauda atsiranda tada, kai tą pačią kontroliuojamą jungtį galima naudoti keliose suderinamose DI programose.

Q: Kuo MCP skiriasi nuo API?

Atsakymas: MCP nepakeičia API. Dažniausiai MCP serveris pats naudoja esamą API, duomenų bazę ar kitą sistemos sąsają, tačiau agentui pateikia standartizuotą ir siauresnį įrankių rinkinį. | Klausimas | API | MCP | | ---------------------------------- | --------------------------------- | ------------------------------------- | | Kam pirmiausia skirta? | programoms ir kūrėjams | DI programoms bei agentams | | Kaip atrandamos funkcijos? | dokumentacijoje, SDK ar sutartyje | standartizuotai per serverio aprašą | | Kas apibrėžia verslo veiksmą? | konkretus API galinis taškas | agentui suprantamas įrankis su schema | | Ar pakeičia sistemos logiką? | ne | ne | | Ar automatiškai užtikrina saugumą? | ne | ne | Pavyzdžiui, CRM gali turėti šimtus bendrų API operacijų. MCP serveris klientų aptarnavimo agentui gali pateikti tik tris: rasti klientą, perskaityti atvirą užklausą ir sukurti pastabos juodraštį. Taip sumažėja integracijos paviršius ir agentui nereikia matyti visos sistemos. Jei sena sistema neturi API, MCP savaime jos neatnaujins. Vis tiek reikės saugaus ryšio per duomenų bazę, failų mainus, robotinį procesų automatizavimą arba naują tarpinę paslaugą. Apie šiuos variantus skaitykite DI integravimo su senomis sistemomis vadove.

Q: Kaip MCP veiktų realiame verslo procese?

Atsakymas: Agentas gauna žmogaus tikslą, parenka MCP įrankį, pateikia struktūrizuotus parametrus, o serveris patikrina teises ir kreipiasi į vidinę sistemą. Pavyzdys — pardavimų vadovas klausia: > „Paruošk šiandienos neatsakytų potencialių klientų santrauką ir sukurk užduočių juodraščius atsakingiems vadybininkams.“ Galima seka: 1. agentas per CRM MCP serverį iškviečia `gauti_neatsakytus_kontaktus`; 2. serveris patikrina vadovo tapatybę ir leidžiamą komandą; 3. agentas apibendrina grąžintus duomenis; 4. kiekvienam kontaktui paruošia užduoties parametrus; 5. prieš rašymo veiksmą parodo vadovui suvestinę; 6. vadovui patvirtinus iškviečia `sukurti_uzduotis`; 7. MCP serveris įrašo veiksmus CRM ir grąžina jų identifikatorius; 8. agentas pateikia nuorodas į sukurtas užduotis. Svarbu, kad agentas negavo bendro CRM administratoriaus prisijungimo. Jis naudojo konkrečius, verslo taisyklėmis apribotus įrankius.

Q: Kada MCP yra geras pasirinkimas?

Atsakymas: MCP naudingiausias, kai tą patį kontroliuojamą duomenų ar veiksmų rinkinį norite pateikti kelioms agentinėms programoms arba dažnai keičiamoms DI sąsajoms. Geri kandidatai: - viena CRM jungtis keliems vidiniams asistentams; - centralizuota dokumentų paieška skirtingoms DI programoms; - bendri kalendoriaus ar projektų valdymo veiksmai; - įmonės patvirtintų įrankių katalogas; - agentai, kuriems reikia dinamiškai atrasti leistinas funkcijas; - organizacijos, norinčios centralizuoti tapatybės ir audito kontrolę. 2026 m. birželį MCP bendruomenė paskelbė stabilią Enterprise-Managed Authorization plėtinio versiją. Ji leidžia organizacijai centralizuotai suteikti MCP serverių prieigą per tapatybės tiekėją. Tarp ankstyvųjų naudotojų nurodomi „Anthropic“, „Microsoft“, „Okta“, „Asana“, „Atlassian“, „Canva“, „Figma“ ir kitos platformos. Prekyboje taip pat atsirado praktinių pavyzdžių: Shopify Spring '26 kūrėjams atvėrė viešą MCP galinį tašką, skirtą agentinės prekybos scenarijams.

Q: Kada MCP nereikalingas?

Atsakymas: Jei turite vieną paprastą, stabilią integraciją tarp dviejų sistemų, tiesioginis API ryšys dažnai bus trumpesnis ir lengviau prižiūrimas. MCP nebūtinai reikalingas, kai: - vienas procesas turi vieną aiškų API kvietimą; - nėra DI agento ar dinaminio įrankių pasirinkimo; - sistema jau turi patikimą integraciją, kurios nereikia naudoti kitur; - papildomas protokolo sluoksnis nesumažina jokio realaus darbo; - organizacija dar neturi sutvarkytų teisių ir duomenų; - norima MCP naudoti tik todėl, kad tai populiari santrumpa. Pirmiausia apibrėžkite procesą ir vartotoją. Technologijos pasirinkimas turi sekti po jų.

Q: Kaip pradėti MCP pilotą?

Atsakymas: Pasirinkite vieną skaitymo scenarijų, vieną patikimą sistemą ir vieną vartotojų grupę. 1. Apibrėžkite verslo klausimą. Pavyzdžiui, „rasti kliento sutartį ir paskutinio kontakto santrauką“. 2. Pasirinkite duomenų šaltinį. Viena CRM arba dokumentų saugykla yra pakankama. 3. Sukurkite siaurus įrankius. Venkite bendro `vykdyti_uzklausa` ar `paleisti_komanda` tipo įrankio. 4. Įgyvendinkite tapatybę ir teises. Rezultatai turi priklausyti nuo konkretaus vartotojo prieigos. 5. Pradėkite nuo skaitymo. Rašymo veiksmus pridėkite tik išmatavę atsakymų kokybę. 6. Registruokite ir testuokite. Tikrinkite neteisingus parametrus, neleistinus duomenis ir bandymus įterpti instrukcijas. 7. Išmatuokite naudą. Vertinkite sutaupytą laiką, sėkmingų užduočių dalį ir klaidas.

2026 m. birželio 18 d. • 7 min. skaityti • Artūras Pikšrys

DI agentas tampa naudingas verslui tada, kai gali pasiekti aktualius duomenis ir atlikti leistinus veiksmus. Tam jį reikia sujungti su CRM, ERP, dokumentų saugykla, el. paštu, kalendoriumi ar kita sistema. Iki šiol kiekvienai tokiai jungčiai dažnai reikėjo atskiros integracijos.

Model Context Protocol, trumpiau MCP, siūlo bendrą būdą agentinei programai sužinoti, kokius duomenis ir veiksmus konkreti sistema gali pasiūlyti. Dėl to jis dažnai vadinamas „USB-C jungtimi DI programoms“.

Šis palyginimas naudingas, bet turi ribas. USB-C laidas nepasako, ką saugu kopijuoti iš jūsų kompiuterio. MCP taip pat neišsprendžia duomenų kokybės, procesų logikos, vartotojų teisių ar sistemos API problemų. Jis standartizuoja ryšį — ne visą integraciją.

1. Kas yra MCP?

Atsakymas: MCP yra atviras protokolas, leidžiantis DI programai vienodu formatu atrasti ir naudoti išorinių sistemų įrankius, duomenų šaltinius bei paruoštas instrukcijas.

Supaprastinta architektūra:

Darbuotojas
    ↓
DI programa arba agentas
    ↓
MCP klientas
    ↓
MCP serveris
    ↓
CRM / ERP / dokumentai / API

MCP serveris veikia kaip kontroliuojamas tarpininkas. Jis gali pateikti agentui, pavyzdžiui, šiuos įrankius:

rasti_klienta — perskaityti vieno kliento informaciją;
sukurti_crm_pastaba — įrašyti patvirtintą pastabą;
gauti_saskaitos_busena — patikrinti, ar sąskaita apmokėta;
rezervuoti_laika — sukurti įrašą kalendoriuje;
ieskoti_vidineje_politikoje — rasti atsakymą dokumentų saugykloje.

Agentas mato įrankio pavadinimą, paaiškinimą ir leistinus parametrus. Jis neturi žinoti visų vidinės sistemos techninių detalių.

2. Kokias galimybes MCP pateikia agentui?

Atsakymas: Pagrindinės MCP galimybės paprastai skirstomos į įrankius, išteklius ir paruoštas užklausas.

MCP elementas	Paskirtis	Verslo pavyzdys
Įrankiai (tools)	atlikti apibrėžtą veiksmą	sukurti užduotį CRM
Ištekliai (resources)	pateikti kontroliuojamą informaciją	perskaityti produkto katalogą
Paruoštos užklausos (prompts)	pasiūlyti standartinį darbo scenarijų	parengti mėnesio pardavimų apžvalgą

Oficiali MCP įžanga protokolą pristato kaip būdą kurti programas, kurios DI modelius jungia su išoriniais duomenimis ir įrankiais. Praktinė nauda atsiranda tada, kai tą pačią kontroliuojamą jungtį galima naudoti keliose suderinamose DI programose.

3. Kuo MCP skiriasi nuo API?

Atsakymas: MCP nepakeičia API. Dažniausiai MCP serveris pats naudoja esamą API, duomenų bazę ar kitą sistemos sąsają, tačiau agentui pateikia standartizuotą ir siauresnį įrankių rinkinį.

Klausimas	API	MCP
Kam pirmiausia skirta?	programoms ir kūrėjams	DI programoms bei agentams
Kaip atrandamos funkcijos?	dokumentacijoje, SDK ar sutartyje	standartizuotai per serverio aprašą
Kas apibrėžia verslo veiksmą?	konkretus API galinis taškas	agentui suprantamas įrankis su schema
Ar pakeičia sistemos logiką?	ne	ne
Ar automatiškai užtikrina saugumą?	ne	ne

Pavyzdžiui, CRM gali turėti šimtus bendrų API operacijų. MCP serveris klientų aptarnavimo agentui gali pateikti tik tris: rasti klientą, perskaityti atvirą užklausą ir sukurti pastabos juodraštį. Taip sumažėja integracijos paviršius ir agentui nereikia matyti visos sistemos.

Jei sena sistema neturi API, MCP savaime jos neatnaujins. Vis tiek reikės saugaus ryšio per duomenų bazę, failų mainus, robotinį procesų automatizavimą arba naują tarpinę paslaugą. Apie šiuos variantus skaitykite DI integravimo su senomis sistemomis vadove.

4. Kaip MCP veiktų realiame verslo procese?

Atsakymas: Agentas gauna žmogaus tikslą, parenka MCP įrankį, pateikia struktūrizuotus parametrus, o serveris patikrina teises ir kreipiasi į vidinę sistemą.

Pavyzdys — pardavimų vadovas klausia:

„Paruošk šiandienos neatsakytų potencialių klientų santrauką ir sukurk užduočių juodraščius atsakingiems vadybininkams.“

Galima seka:

agentas per CRM MCP serverį iškviečia gauti_neatsakytus_kontaktus;
serveris patikrina vadovo tapatybę ir leidžiamą komandą;
agentas apibendrina grąžintus duomenis;
kiekvienam kontaktui paruošia užduoties parametrus;
prieš rašymo veiksmą parodo vadovui suvestinę;
vadovui patvirtinus iškviečia sukurti_uzduotis;
MCP serveris įrašo veiksmus CRM ir grąžina jų identifikatorius;
agentas pateikia nuorodas į sukurtas užduotis.

Svarbu, kad agentas negavo bendro CRM administratoriaus prisijungimo. Jis naudojo konkrečius, verslo taisyklėmis apribotus įrankius.

5. Kada MCP yra geras pasirinkimas?

Atsakymas: MCP naudingiausias, kai tą patį kontroliuojamą duomenų ar veiksmų rinkinį norite pateikti kelioms agentinėms programoms arba dažnai keičiamoms DI sąsajoms.

Geri kandidatai:

viena CRM jungtis keliems vidiniams asistentams;
centralizuota dokumentų paieška skirtingoms DI programoms;
bendri kalendoriaus ar projektų valdymo veiksmai;
įmonės patvirtintų įrankių katalogas;
agentai, kuriems reikia dinamiškai atrasti leistinas funkcijas;
organizacijos, norinčios centralizuoti tapatybės ir audito kontrolę.

2026 m. birželį MCP bendruomenė paskelbė stabilią Enterprise-Managed Authorization plėtinio versiją. Ji leidžia organizacijai centralizuotai suteikti MCP serverių prieigą per tapatybės tiekėją. Tarp ankstyvųjų naudotojų nurodomi „Anthropic“, „Microsoft“, „Okta“, „Asana“, „Atlassian“, „Canva“, „Figma“ ir kitos platformos.

Prekyboje taip pat atsirado praktinių pavyzdžių: Shopify Spring '26 kūrėjams atvėrė viešą MCP galinį tašką, skirtą agentinės prekybos scenarijams.

6. Kada MCP nereikalingas?

Atsakymas: Jei turite vieną paprastą, stabilią integraciją tarp dviejų sistemų, tiesioginis API ryšys dažnai bus trumpesnis ir lengviau prižiūrimas.

MCP nebūtinai reikalingas, kai:

vienas procesas turi vieną aiškų API kvietimą;
nėra DI agento ar dinaminio įrankių pasirinkimo;
sistema jau turi patikimą integraciją, kurios nereikia naudoti kitur;
papildomas protokolo sluoksnis nesumažina jokio realaus darbo;
organizacija dar neturi sutvarkytų teisių ir duomenų;
norima MCP naudoti tik todėl, kad tai populiari santrumpa.

Pirmiausia apibrėžkite procesą ir vartotoją. Technologijos pasirinkimas turi sekti po jų.

7. Ar MCP yra saugus?

Atsakymas: MCP gali padėti centralizuoti prieigą, tačiau saugumas priklauso nuo serverio, autorizacijos, įrankių ribų ir visos agento architektūros.

Oficialioje MCP autorizacijos specifikacijoje nuotolinėms HTTP integracijoms aprašomas OAuth 2.1 pagrįstas procesas, prieigos rakto susiejimas su konkrečiu serveriu ir draudimas nepatikrintus raktus perduoti kitoms sistemoms.

Praktiniame diegime būtina:

kiekvienam serveriui suteikti minimalias teises;
atskirti skaitymo ir rašymo įrankius;
naudoti vartotojo tapatybę, o ne vieną bendrą paskyrą;
jautriems veiksmams reikalauti žmogaus patvirtinimo;
tikrinti visus įrankio parametrus;
registruoti kvietimą ir rezultatą;
izoliuoti vietinius MCP serverius;
neįdiegti nepatikrintų bendruomenės serverių į gamybos aplinką.

OWASP MCP saugumo gairėse aprašomi įrankių užnuodijimo, perteklinių teisių, duomenų nutekėjimo ir tiekimo grandinės pavojai. Platesnį kontrolės sąrašą rasite mūsų DI agentų saugumo vadove.

8. Kaip pradėti MCP pilotą?

Atsakymas: Pasirinkite vieną skaitymo scenarijų, vieną patikimą sistemą ir vieną vartotojų grupę.

Apibrėžkite verslo klausimą. Pavyzdžiui, „rasti kliento sutartį ir paskutinio kontakto santrauką“.
Pasirinkite duomenų šaltinį. Viena CRM arba dokumentų saugykla yra pakankama.
Sukurkite siaurus įrankius. Venkite bendro vykdyti_uzklausa ar paleisti_komanda tipo įrankio.
Įgyvendinkite tapatybę ir teises. Rezultatai turi priklausyti nuo konkretaus vartotojo prieigos.
Pradėkite nuo skaitymo. Rašymo veiksmus pridėkite tik išmatavę atsakymų kokybę.
Registruokite ir testuokite. Tikrinkite neteisingus parametrus, neleistinus duomenis ir bandymus įterpti instrukcijas.
Išmatuokite naudą. Vertinkite sutaupytą laiką, sėkmingų užduočių dalį ir klaidas.

Apibendrinimas

MCP sprendžia realią agentinių sistemų problemą: kaip vienodu būdu parodyti DI programai, kokius duomenis ir veiksmus ji gali naudoti. Jis gali sumažinti pasikartojančių integracijų kiekį ir centralizuoti prieigos valdymą.

Tačiau MCP nėra API pakaitalas, automatinis saugumo sertifikatas ar būdas apeiti senos sistemos ribas. Didžiausią vertę jis sukuria tada, kai naudojamas kaip siauras, valdomas sluoksnis virš patikimų verslo sistemų — su aiškiomis teisėmis, validavimu, žmogaus patvirtinimais ir auditu.

Šaltiniai

Svarstote, kaip saugiai sujungti DI agentą su CRM, ERP ar dokumentais? Susisiekite su mumis — padėsime nuspręsti, ar jūsų procesui tinka MCP, tiesioginė API integracija ar paprastesnis sprendimas.

Grįžti į tinklaraštį