WebMCP ja MCP: mis vahe neil on ja millal kumbagi kasutada
🎧 Kuula kõiki artikleid järjest
WebMCP on ettepanek, kuidas veebileht saab brauseriagendile oma vormid ja tegevused selgelt kirjeldada. See ei ole MCP uus nimi ega asendus. Lihtne reegel: MCP sobib serveri ja andmete juurde, WebMCP sobib avatud veebilehe ja kasutaja nähtava töövoo juurde.
WebMCP on praegu veel liiga värske, et seda igasse tootmissaidi vormi kiiruga lisada. Aga suund on õige: AI-agent ei peaks veebilehel ainult nuppe ära arvama ja inimese eest klõpsama. Veebirakendus saab ise öelda, milliseid tegevusi agent võib käivitada ja milliseid andmeid need tegevused ootavad.
See on oluline vahe.
Tavaline brauseriagent loeb lehte umbes nii nagu kasutaja või testimistööriist: pealkirjad, vormiväljad, nupud, DOM, ligipääsetavuse puu ja mõnikord ekraanipilt. Kui ta peab kontakti- või broneerimisvormi täitma, peab ta ise järeldama, mida iga väli tähendab. Kui kujundus või väljade tekst muutub, võib töövoog katki minna.
WebMCP püüab seda ebakindlust vähendada. Leht saab registreerida tööriista, näiteks submit_contact_request, filter_products või start_audit, ning kirjeldada selle sisendeid JSON Schema abil. Agent ei pea siis küsima "kus nupp on?", vaid saab küsida "milline tööriist selle tegevuse jaoks on?".
See ei tähenda, et kõik peaks liikuma WebMCP peale. Chrome for Developersi WebMCP ja MCP võrdlus (avaneb uues aknas) ütleb sama üsna otse: WebMCP ja MCP lahendavad eri kihte. MCP kuulub serveri ja süsteemide juurde. WebMCP kuulub brauseris avatud lehe juurde.
MCP: püsiv tööriistakiht serverite ja andmete jaoks
MCP ehk Model Context Protocol (avaneb uues aknas) sobib siis, kui agent peab töötama asjadega, mis ei ela ainult avatud brauseri vahekaardil:
- failid ja repositooriumid;
- andmebaasid;
- CRM, dokumendihoidlad ja sisemised liidesed;
- pikemad analüüsi- või avaldamistöövood;
- tööriistad, mida agent peab kasutama ka siis, kui konkreetne veebileht ei ole avatud.
WebPro enda blogi töövoog on hea näide. MCP kaudu saab artikleid otsida, avada, mustandit muuta, valideerida, muudatuste vaadet näidata ja avaldamist ette valmistada. See ei sõltu sellest, kas kasutaja on parajasti avalikul blogilehel. Tööriist töötab lähtefailide ja avaldamisprotsessiga.
Sellise töö jaoks ei oleks WebMCP õige põhikiht. Blogi lähtefailid, lehe ehitus, testid, commit, varukoopia ja serverisse viimine ei ole brauseri vormi sisene tegevus. Need on avaldamisprotsessi osad.
WebMCP: avatud lehe tööriistad agentidele
WebMCP GitHubi projekt (avaneb uues aknas) kirjeldab WebMCP-d kui viisi, millega veebileht saab JavaScripti funktsioonid või HTML-vormid agentidele tööriistadena nähtavaks teha. See on brauseri ja lehe vaheline kiht, mitte eraldi serveriprotokoll.
Praktiliselt saab veebileht agendile tegevusi näidata kahel viisil:
- lehe JavaScript võib öelda: siin on tööriist, mida agent võib käivitada;
- tavaline HTML-vorm võib öelda: see vorm on tööriist ning need väljad tähendavad nime, e-posti, veebiaadressi ja sõnumit.
Teine variant on tavalistele veebidele eriti huvitav. Kui kontaktivormil on väljad nimi, e-post, veebiaadress ja kirjeldus, võiks vorm ise öelda: "see on päringu saatmise tööriist; need väljad on kohustuslikud; enne saatmist peab kasutaja nägema, mida täidetakse."
See sobib hästi kohtadesse, kus inimene ja agent tegutsevad samal hetkel samal lehel:
- kontaktivorm;
- toetuspäringu vorm;
- e-poe tooteotsing või ostukorv;
- broneerimisvoog;
- kalkulaator;
- veebiauditi tööriist;
- keeruline sisutoimetaja vaade.
WebMCP tugevus on kontekst. Agent näeb sama sessiooni, sama lehe seisu ja sama kasutaja pooleliolevat tööd. Kui tööriist käivitub, saab leht oma tavapärase loogikaga kasutajaliidest muuta, tulemuse nähtavaks teha ja vajaduse korral inimeselt kinnitust küsida.
Kõige kasulikum vahe: kus tegevus elab?
Lihtne otsustusreegel:
- kui tegevus peab toimuma serveris, andmebaasis, failides või mõnes teises süsteemis, alusta MCP-st;
- kui tegevus peab toimuma avatud veebilehe kasutajaliideses, kaalu WebMCP-d;
- kui vaja on mõlemat, kasuta mõlemat, aga ära sega vastutust.
Näiteks Drupali saidil võib MCP tööriist küsida sisumudelit, lugeda artikleid JSON:API kaudu, võrrelda tõlkeid või luua muudatusettepaneku. WebMCP võiks samal ajal aidata kasutajal Drupali haldusliideses või avalikus tööriistas konkreetset vormi täita, filtrit kasutada või eelvaadet uuendada.
Need kaks ei ole konkurendid. Need on kaks erinevat lepingut agendi ja süsteemi vahel.
MCP ütleb: "siin on püsiv teenus, mille kaudu saad andmeid ja tegevusi kasutada."
WebMCP ütleb: "see konkreetne leht, mis on praegu brauseris avatud, pakub need tööriistad."
Mida see Drupali jaoks tähendab?
Drupali puhul ei ole esimene küsimus "kas lisame WebMCP?". Esimene küsimus on: milline tegevus on üldse agendile lubatud?
Kui Drupal sait on teenuseportaal, kooli veeb, omavalitsuse leht või e-pood, siis tasub eristada vähemalt kolme pinda.
Avalik leht. Agent võib aidata kasutajal leida teenust, täita päringu vormi või käivitada avaliku auditi. WebMCP võib siin sobida, sest tegevus toimub kasutaja nähtaval lehel.
Sisutoimetaja töölaud. Agent võib aidata vormi täita, sisu kokku võtta või välju kontrollida. Siin on WebMCP huvitav, aga õigused ja kinnitused peavad olema väga selged. Drupalil on selleks juba rollid, õigused, töövood ja versioonid.
Tehniline avaldamistöövoog. Agent võib analüüsida koodi, võrrelda konfiguratsiooni, kontrollida teste või valmistada muudatusi ette. See on pigem MCP, käsurea ja arenduskeskkonna maailm, mitte WebMCP.
Hea arhitektuur ei ürita kõike ühe protokolliga lahendada. Avalik vorm, sisutoimetaja töövoog ja serverisse viimine ei vaja sama tööriistakihti.
WebPro saidi näide
WebProl on praegu kaks eri asja, mida ei tohiks segi ajada.
Esiteks on olemas MCP-põhine artiklitöövoog. See sobib sisufailide ja avaldamise jaoks, sest seal on vaja kontrollida lähtefaili, tõlget, lehe ehitust, teste ja serverisse viimist. See on õige koht püsivale agent-tööriistale.
Teiseks on avalikul saidil vormid ja Drupal auditi tööriist. Need on kohad, kus WebMCP sobib esimeseks madala riskiga katseks. WebPro kontaktvorm ja auditi vormid saavad juba tööriistakirjelduse: kontaktivormi puhul peab inimene saatmise üle vaatama, avaliku auditi eelkontrolli puhul võib tööriist vormi automaatselt käivitada ja tulemuse lehele tagasi tuua.
See ei tähenda, et agent peaks saama piiramatult päringuid teha või vorme automaatselt saata. Kontaktivormi, auditi ja e-poe puhul peab jääma alles sama põhimõte: tööriist võib aidata, aga tundliku või lõpliku tegevuse peab inimene kinnitama.
Seis: august 2026
WebMCP on veel kujunev standardiettepanek. WebMCP implementation status (avaneb uues aknas) näitas augusti 2026 lõpus tuge ChatGPT Desktopis, Chrome 149 ja Edge 150 katseprogrammis ning Brave Leo eksperimentaalses režiimis. Firefoxi ja Safari puhul olid näha standardipositsiooni arutelud, mitte laialt kasutatav tugi.
Sellest piisab prototüübiks. Sellest ei piisa, et kogu kriitiline veebitöövoog ainult WebMCP peale ehitada.
Seetõttu on mõistlik lähenemine tagasihoidlik:
- ära lõhu olemasolevat semantilist HTML-i;
- ära eelda, et kõik brauserid või agendid WebMCP-d toetavad;
- ära anna agendile rohkem õigusi kui kasutajal endal on;
- valideeri WebMCP sisendid samamoodi nagu tavalise vormi või API sisendid;
- salvesta, mida agent tegi ja millal;
- näita tundliku tegevuse puhul inimese kinnitust selgelt.
Leht peab töötama ka siis, kui WebMCP tuge ei ole. Kui tugi on olemas, saab agent vormi või tööriista kindlamalt kasutada.
Turvarisk ei kao
WebMCP võib vähendada kasutajaliidese valesti tõlgendamist, kuid see ei tee agenti automaatselt turvaliseks.
Kõik andmed, mida agent tööriistale annab, on endiselt sisend. Neid tuleb valideerida. Kui tööriist teeb päringu serverisse, peab server õigusi uuesti kontrollima. Kui tegevus võib saata vormi, muuta tellimust, teha ostu või avaldada sisu, peab kinnitus olema päriselt arusaadav.
Brauseri tasemel räägitakse siin samast päritolust, õiguste poliitika piirangutest ja sellest, kellele tööriistad nähtavaks tehakse. Need on vajalikud mehhanismid, aga mitte ärireeglite asendajad.
Drupal saidil tähendab see eriti selgelt: WebMCP tööriist ei tohi minna mööda Drupali õigustest, CSRF-kaitsest, sisutöövoost ega logidest. Kui tööriist kutsub Drupali API-t, peab see liides olema sama rangelt ehitatud nagu iga teine avalik või autentitud liides.
Millest alustada?
Kui sul on Drupal või muu keerukam veebirakendus, siis ära alusta WebMCP märgendite lisamisest. Alusta töövoo valikust.
Hea esimene kandidaat on tegevus, mis on:
- kasutajale nähtav;
- korduv;
- vormi või filtriga seotud;
- madala riskiga;
- hästi valideeritav;
- inimese kinnitusega lõpetatav.
Näiteks kontaktivormi eeltäitmine, auditi URL-i kontroll, tugipäringu koostamine või tooteotsingu filtrite seadmine.
MCP poolel on parem alustada sealt, kus agent vajab taustal püsivat ligipääsu: sisuanalüüs, tõlgete võrdlus, auditiraporti ettevalmistus, tööjärje koostamine, failide või konfiguratsiooni kontroll.
Kui mõlemad kihid on vaja kokku panna, peaks piir olema selge. WebMCP juhib avatud lehe tegevust. MCP toob serveri või organisatsiooni süsteemidest vajaliku konteksti.
Kokkuvõte
WebMCP ei ole MCP uus versioon. MCP on püsiv tööriistakiht serveriandmete ja süsteemide jaoks. WebMCP on brauseris avatud lehe tööriistakiht, mis aitab agentidel kasutada sama kasutajaliidest, mida inimene parajasti näeb.
Drupal saidiomaniku jaoks on praktiline küsimus lihtne: millised tegevused peaksid olema agentidele nähtavad ja millises kihis? Avalik vorm või tööriist võib sobida WebMCP jaoks. Sisumudel, konfiguratsioon, failid ja avaldamisprotsess sobivad pigem MCP jaoks.
WebPro saab aidata seda piiri hinnata AI ja Drupal töövoogude, automaattestimise ja tehnilise auditi kaudu. Kõigepealt tuleb paika panna õigused, kontroll ja vastutus. Alles siis tasub valida, kas tööriist elab brauseris, serveris või mõlemas.

Vajad Drupal abi?
Saada veebiaadress ja lühike taust. Ütleme, kas järgmine mõistlik samm on audit, hooldus, versiooniuuendus või migratsioon.