MCP vs. API: põhjalik tehniline ülevaade (määratlused, erinevused ja kasutusjuhud)

Saage teada, mille poolest MCP ja API erinevad, kuidas need koos töötavad ning millal neid tehisintellekti integratsioonide ja tarkvara töövoogude jaoks kasutada.

Diagram comparing an MCP host, client, and server connected to tools, resources, and prompts with an API client-server flow.

MCP (Model Context Protocol ehk mudeli kontekstiprotokoll) on avatud standard, mida tehisintellektid ehk agentid kasutavad välissüsteemidele juurdepääsemiseks: rakenduste funktsionaalsus (tööriistad), ressursid (sh andmebaasid) ja viibad.

Erinevalt API-st, mis ühendab kahte rakendust määratud lõpp-punktide ja parameetrite kaudu, võimaldab MCP LLM-idel avastada ajakohaseid tööriistu käitusajal. Samuti võib MCP oluliselt vähendada integratsiooni hooldamiseks kuluvat aega.

MCP ja API ei ole vastandlikud tehnoloogiad. MCP loodi selleks, et anda tehisintellektipõhistele rakendustele põhjalik juurdepääs välisele funktsionaalsusele ja teabele, vähendades samal ajal vajadust kohandatud API konfigureerimise järele. Sageli käivitavad MCP-päringud serveripoolseid API-kõnesid ja on olemas olulisi arendajate kasutusjuhte, kus API-d on MCP ees endiselt eelistatud.

MCP vs. API: millised on peamised erinevused?

  • MCP on avatud lähtekoodiga protokoll (reeglite kogum), mis võimaldab tehisintellekti tööriistadel ohutult ja autonoomselt kutsuda välja selliseid tööriistu nagu andmebaasid, tarkvarafunktsioonid ja viibad.
  • Võrreldes eelkonfigureeritud API-dega võimaldab MCP LLM-il valida praeguse välise funktsionaalsuse vastavalt ülesande vajadustele, ilma et see koormaks selle kontekstiakent.
  • Traditsiooniliste tarkvaraintegratsioonide ja mõningate fikseeritud iteratiivsete LLM-i töövoogude puhul on eelistatud API-d.
  • Kui tehisintellekti funktsionaalsus teie rakenduses laieneb, haldate suurt hulka integratsioone või müüja funktsioonid muutuvad sageli, on MCP ülekaalukalt parem valik.
  • Väljaspool arendajate ringkonda ei nõua MCP-konnektorite isiklik kasutamine suuremate tehisintellekti vestlusrobotitega (Claude, ChatGPT, Perplexity jne) mingeid keerulisi programmeerimis teadmisi. Enamikul on ühe klõpsuga integratsioonid.

Mis on mudeli kontekstiprotokoll (MCP)?

MCP on laialdaselt kasutatav protokoll tehisintellektimudeli ja MCP-serveri vaheliseks suhtluseks. Protokoll võimaldab MCP-kliendil kutsuda välja kõiki MCP-serveris saadaolevaid tööriistu ja ressursse.

MCP töövoog koosneb kolmest komponendist:

  • Host: ümbritsev rakendus (näiteks Perplexity), kus lõppkasutaja käivitab toimingu või sisestab loomulikus keeles viiba, näiteks „ütle mulle Londoni ilma“. Host annab LLM-ile loendi saadaolevatest tööriistadest ja LLM otsustab, milline tööriist sobib ülesande täitmiseks kõige paremini.
  • Klient: protokollihaldur (hosti sisse ehitatud), mis loob ühenduse MCP-serveriga, kasutades MCP-protokolli.
  • Server: rakendus, mis võtab vastu MCP-päringuid ning teeb kättesaadavaks või „avab“ mitmesugused funktsioonid, millele sellel on juurdepääs.

Väärib märkimist, et MCP-serverid kasutavad tööriistadega suhtlemiseks sageli API-sid. Kui ühendate näiteks Perplexity Slacki MCP-ga, suhtleb klient MCP-serveriga, mis omakorda kasutab algses MCP-päringus kirjeldatud päringute tegemiseks Slacki API-t.

Mis on rakendusliides (API)?

API on kahe rakenduse vaheline liides. Sarnaselt MCP-le määratleb see reeglid selle kohta, kuidas üks süsteem saab teiselt andmeid või toiminguid taotleda. Klient saadab päringu teenusepakkuja määratud parameetreid kasutades ja server edastab vastuse.

Siin on ülevaade API-päringu ja -vastuse erinevatest elementidest:

  • Lõpp-punkt (Endpoint): URL, kuhu päring saadetakse.
  • Meetod (Method): toiming, mida soovite serverirakendusel teha.
  • Parameetrid (Parameters): sisendid, mida saadate serverile töötlemiseks.
  • Päised (Headers): lisateave, näiteks autoriseerimine ja vastuse vorming.
  • Päringu sisu (Request body): päringu täitmiseks vajalikud andmed (need on mõnikord valikulised).
  • Vastus: teave või õnnestumise/ebaõnnestumise olek, mille server tagastab.

Kõrgetasemeliselt taandub peaaegu kõik, mida API teeb, andmete vahetamisele süsteemiga või süsteemilt toimingu sooritamise taotlemisele.

Pealiskaudselt võib see tunduda sarnane sellega, mida MCP-konnektor teeb. Otsustav erinevus seisneb aga selles, et API-põhise lähenemise korral nõuavad erinevad ülesanded erinevaid lõpp-punkte, meetodeid ja parameetreid, mida kõiki tuleb kliendi poolel hallata. MCP-server teeb kogu oma saadaoleva funktsionaalsuse või andmed LLM-ile nähtavaks ilma kliendipoolsete värskendusteta.

Kasutusjuhud, eelised ja puudused

MCP

API

Põhirakendus

Töövoogud LLM-põhises tööriistas

Määratletud päringud tarkvaraplatvormide vahel

Kuidas need töötavad

Juurdepääs mitmele tööriistale LLM-i arutluse põhjal; kogu funktsionaalsus on ajakohane, kuna müüja juhib MCP-serverit

Tarkvara saadab teenusepõhiseid päringuid eelmääratletud lõpp-punktide, meetodite ja parameetrite abil

Avastamine

LLM näeb ja saab kasutada kõiki serveri pakutavaid tööriistu, sealhulgas uusi

Tarkvara saab teha ainult eelnevalt konfigureeritud API-päringuid

Peamised kasutusjuhud

Tehisintellektil põhinevad ja agentide töövood; dünaamiline tööriistade valik loomuliku keele viipade põhjal; tehisintellekti tööriistade müüjate integratsioonid

Suuremahulised andmeedastused; fikseeritud, korratavad töövood; traditsioonilised tarkvaraintegratsioonid

Lisakasutusjuhud

Koodiabilised juurdepääsuga mitmele failile ja hoidlale; loomuliku keele juurdepääs ettevõtte süsteemidele; sisemised korduskasutatavad integratsioonid tehisintellekti tööriistade jaoks

Kohandatud integratsioonid; veebitehingud; plaanitud andmete toomine; müüjate integratsioonid tehisintellekti tööriistade jaoks, mis ei toeta MCP-d

Seadistusaeg

Minimaalne pärast MCP-ühenduse loomist

Uuele funktsionaalsusele juurdepääsemiseks tuleb API-d rakenduses eraldi konfigureerida

Puudused

Keeruliste ülesannete puhul on sageli kõrge tokenikulu; liiga ressursimahukas selgelt määratletud ja korduvate andmeülesannete jaoks

Äärmiselt kõrged hoolduskulud keeruliste integratsioonidega rakenduste puhul; ei taga juurdepääsu praegusele funktsionaalsusele

Eelised

Universaalne standard, suudab käsitleda keerulisi töövooge, suurem juurdepääs tööriistadele, pärast seadistamist autonoomne

Väiksema tokenimahuga fikseeritud ja suuremahuliste töövoogude jaoks tehisintellekti tööriistades

Praktiline näide MCP ja API võrdlusest

Vaatame lihtsat näidet, mis illustreerib MCP ja API erinevusi. Selles stsenaariumis sobib päring tegelikult paremini API-le (see on lihtne ega vaja konteksti). Need kaks näidet näitavad siiski selgelt, kuidas MCP on mitmeetapiliste LLM-i töövoogude jaoks optimaalne.

Siin on skript (kirjutatud Pythonis), mis saadab Open-Meteo API kaudu API-päringu ilmateabe saamiseks:

python
import requests url = "https://api.open-meteo.com/v1/forecast" params = { "latitude": 51.5072, "longitude": -0.1276, "current": "temperature_2m"} response = requests.get(url, params=params) data = response.json() temperature = data["current"]["temperature_2m"] print(f"Temperature in London: {temperature}°C")

See näide kasutab täpset päringuvormingut, et pärida Open-Meteo kaudu HTTPS-i teel praegust 2-meetrist temperatuuri laiuskraadile 51.5072 ja pikkuskraadile -0.1276 (London).

Vastupidiselt võib MCP-klient saata ilmateabebaasile juurdepääsu omavale serverile järgmise sarnase tools/call JSON-RPC päringu:

json
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "get_weather", "arguments": { "city": "London" } } }

Selles kujutletud näites palub klient serveril kasutada registris olevat spetsiaalset tööriista (get-weather) ülesande täitmiseks (Londoni ilma kirjeldamiseks).

Peamine erinevus seisneb selles, et see funktsionaalsus oleks üks paljudest, mida MCP-server pakub. MCP-klient ei pea päringu genereerimiseks teadma spetsiifilisi lõpp-punkte, parameetreid, vastuse struktuure ega autentimismeetodeid. LLM saab registris olevad tööriistade kirjeldused üle vaadata, et valida need, mida ta peab loomulikus keeles kirjeldatud ülesande täitmiseks kõige sobivamaks.

Kuidas valida MCP ja API vahel

MCP ja API ei ole vastandid. MCP loodi integratsioonide lihtsamaks avastamiseks ja hooldamiseks. Seetõttu on API-d sageli parim valik mittetehisintellekti tarkvaraühenduste ning LLM-i ülesannete ja töövoogude jaoks, mis on fikseeritud ja toetuvad kindlale stabiilsete API-de rühmale.

Millal kasutada MCP-d

  • Peate haldama suurt või kasvavat tööriistakomplekti: MCP-klient saab käitusajal avastada kõik müüja serveri kaudu pakutavad tööriistad, vähendades individuaalseid API konfigureerimiskulusid tööriistakomplekti kasvades.
  • Tööriista valik sõltub kasutaja päringutest: MCP on kasulik siis, kui ülesande samme ei saa ette määrata, näiteks kui kasutajad esitavad vestlusrobotile laias valikus päringuid. LLM saab kontrollida saadaolevaid tööriistade nimesid, kirjeldusi ja skeeme ning seejärel valida ülesande jaoks kõige paremini sobivad.
  • Müüja funktsionaalsus muutub sageli: Kui müüjad lisavad oma rakendustele uusi funktsioone, on need MCP kaudu kohe saadaval. Te ei pea lisama uusi API-d ega ümber konfigureerima olemasolevaid.
  • Soovite, et samad integratsioonid oleksid saadaval mitmes tehisintellekti rakenduses: Üks MCP-server saab pakkuda samu võimalusi mitmele agentile või rakendusele, vähendades topeltintegratsioonitööd.

Millal kasutada otsest API-t

  • Toote struktureeritud andmeid: Kui teie tehisintellekti tööriist toob kasutaja töövoo määratud etapil esile ennustatavat struktureeritud teavet, näiteks saadetise oleku või klienditoe pileti numbri, on standardne API-päring tokeni- ja ajamahult vähem nõudlik.
  • Teie töövoog on korraldatud fikseeritud järjestusse: Kui teie töövoog järgib ranget, korratavat järjestust täpsete API-de ja täpse tulemusega, pole MCP-d vaja kasutada.
  • Teie rakendus käivitab suuremahulise töövoo: Tokenite kasutus võib suuremahuliste ülesannete puhul olla eriti kulukas. Kui keeruline töövoog nõuab iteratiivseid suuremahulisi sisendeid või väljundeid koos aruteluga, on eelistatud kasutada MCP- ja API-päringute kombinatsiooni.
  • Tehisintellekti arutlusest pole kasu: Kui tavaline rakenduse loogika saab ülesandega piisavalt hakkama, on otsene API-päring tavaliselt lihtsam ja vähem ressursimahukas.

MCP konnektori kasutamine Perplexitys

Küsimus „MCP vs. API“ puudutab suurel määral arendajaid, kes loovad tehisintellekti funktsioonidega rakendusi. Siiski võite te ka ise mõelda, kas kasutada MCP-d oma professionaalsete töövoogude jaoks valitud tehisintellekti tööriistas või mitte.

Kehtivad samad üldised reeglid: kui soovite laiaulatuslikku ja ajakohast juurdepääsu kolmandate osapoolte rakenduste funktsionaalsusele, on MCP õige valik. Rutiinsete ja suuremahuliste ülesannete jaoks kulutab lihtne API-häälestus vähem tokeneid.

Enamik tehisintellekti tööriistu, sealhulgas Perplexity, võimaldab kasutajatel seadistada ja kasutada MCP-konnektoreid ilma koodi kirjutamata. See võimaldab korraldada mitmeetapilisi töövooge vestlusliidesest lahkumata. Näiteks on võimalik integreeruda selliste platvormidega nagu Gmail, Hubspot ja Supabase vaid paari klikiga.

Miks teeb MCP LLM-põhised rakendused võimsamaks

MCP põhiomadused on dünaamiline avastamine ja väiksem API hoolduskoormus. Ühendades oma rakenduse MCP-serveriga, saate juurdepääsu kõigile uusimatele tööriistadele, andmetele ja viipadele, mida teie valitud teenusepakkujad (või kohalikud süsteemid) pakuvad.

API-d on aga endiselt hädavajalikud. Need moodustavad rakenduste omavahelise ühenduvuse aluseks oleva arhitektuuri. MCP toimib vahekihina rakenduse ja välise funktsionaalsuse vahel. See võimaldab tehisintellekti agentidel pääseda ligi võimalikult laiale tööriistakomplektile vormingus, mis sobib keeruliste töövoogude jaoks.