AI Drupal Arendus Turvalisus UX

WebMCP ja MCP: mis vahe neil on ja millal veebis kumbagi kasutada

🎧 Kuula kõiki artikleid järjest

WebMCP on uus ettepanek veebilehe ja brauseriagendi vahelise koostöö jaoks. See ei ole MCP uus nimi ega asendus. Praktiline reegel on lihtne: MCP sobib serveri ja andmete juurde, WebMCP sobib elava veebilehe ja kasutaja nähtava töövoo juurde.

  1. aasta augusti lõpus ei ole WebMCP veel asi, mille peaks igasse tootmissaidi vormi kiiruga lisama. Aga seda tasub juba mõista, sest 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 kasutada ja millise skeemiga andmeid need ootavad.

See on oluline vahe.

Tavaline brauseriagent näeb lehte ligikaudu nagu kasutaja või automatiseerimistööriist: pealkirjad, vormiväljad, nupud, DOM, ligipääsetavuse puu ja mõnikord ekraanipilt. Kui ta peab kontakti- või broneerimisvormi täitma, peab ta järeldama, mida iga väli tähendab. Kui disain muutub, võib töövoog katki minna.

WebMCP püüab selle ebakindluse 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 olemas on?".

See ei tähenda, et kõik peaks liikuma WebMCP peale. Chrome for Developersi WebMCP ja MCP võrdlus ütleb sama üsna otse: WebMCP ja MCP lahendavad eri kihte. MCP on backend. WebMCP on frontend.

MCP: püsiv tööriistakiht serverite ja andmete jaoks

MCP ehk Model Context Protocol sobib siis, kui agent peab töötama asjadega, mis ei ela ainult avatud brauseritab'is:

  • failid ja repositooriumid;
  • andmebaasid;
  • CRM, dokumendihoidlad ja sisemised API-d;
  • 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. Meil on MCP kaudu võimalik artikleid otsida, avada, mustandit muuta, valideerida, diffi näidata ja avaldamist ette valmistada. See ei sõltu sellest, kas kasutaja on parajasti avalikus blogilehes. Tööriist töötab lähtefailide ja avaldamisprotsessiga.

Sellise töö jaoks ei oleks WebMCP õige põhikiht. Blogi lähtefail, build, testid, commit, varukoopia ja deploy ei ole brauseri vormi sisene tegevus. Need on release-protsessi osad.

WebMCP: brauseris avatud lehe agent-liides

WebMCP GitHubi projekt 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 tähendab see kahte tüüpi API-t:

  • imperatiivne API, kus lehe JavaScript registreerib tööriista;
  • deklaratiivne vormide API, kus HTML-vormile lisatakse tööriista nimi, kirjeldus ja väljade kirjeldused.

Deklaratiivse poole mõte on eriti huvitav tavalistele veebidele. Kui kontaktivormil on väljad nimi, e-post, veebiaadress ja kirjeldus, võiks vorm ise öelda: "see on päringu saatmise tööriist; need on nõutud väljad; 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 UI.

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 UI-d 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 UI sees, 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 Drupal admin-liideses 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 jaoks.

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 revisions.

Tehniline release-töövoog. Agent võib analüüsida koodi, võrrelda konfiguratsiooni, kontrollida teste või valmistada muudatusi ette. See on pigem MCP, CLI ja arenduskeskkonna maailm, mitte WebMCP.

Hea arhitektuur ei ürita kõike ühe protokolliga lahendada. Avalik vorm, sisutoimetaja töövoog ja deploy 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, buildi, teste ja deploy'd. See on õige koht püsivale agent-tööriistale.

Teiseks on avalikul saidil olemas vormid ja Drupal auditi tööriist. Need on just sellised kohad, kus WebMCP sobib esimeseks madala riskiga katseks. WebPro kontaktvorm ja auditi vormid saavad juba deklaratiivse tööriistakirjelduse: kontaktivormi puhul peab inimene saatmise üle vaatama, avaliku auditi eelkontrolli puhul võib tööriist vormi automaatselt käivitada ja tulemust 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 2026. aasta augustis

WebMCP on veel kujunev standardiettepanek. WebMCP implementation status näitab 2026. aasta augusti lõpu seisuga toetust ChatGPT Desktopis, Chrome 149 Origin Triali, Edge 150 Origin Triali ning Brave Leo eksperimentaalset tuge. Firefoxi ja Safari juures on praegu nähtaval standards-position arutelud, mitte valmis lai tugi.

See on piisav, et prototüüpida. See ei ole piisav, 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;
  • hoia auditijälg alles;
  • tee tundliku tegevuse jaoks inimese kinnitus nähtavaks.

Kui WebMCP puudub, peab leht endiselt töötama. Kui WebMCP on olemas, saab agent kasutada selgemat, kiiremat ja vähem haprat rada.

Turvarisk ei kao

WebMCP võib vähendada UI äratundmise vigu, kuid see ei tee agenti automaatselt turvaliseks.

Kõik argumendid, mida agent tööriistale annab, on endiselt sisend. Neid tuleb valideerida. Kui tööriist teeb päringu backend'i, peab backend kontrollima õigusi uuesti. 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, permissions policy 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 saada mööda Drupali õigustest, CSRF-kaitsest, sisutöövoost ega logidest. Kui tööriist kutsub Drupali API-t, peab see API olema sama rangelt ehitatud nagu iga teine avalik või autentitud endpoint.

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, backlogi 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 backend'i, andmete ja süsteemide jaoks. WebMCP on brauseris avatud lehe tööriistakiht, mis aitab agentidel kasutada sama UI-d, 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 release-protsess 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.

Telli RSS
Kaido Toomingas, WebPro tehniline juhtWebPro Company OÜ Tehniline juht: Kaido Toomingas

Vajad Drupal abi?

Kui artikkel puudutab sinu olukorda, ei pea kõike lõpuni lugema. Sinuga suhtleb päris inimene ja aitab järgmise sammuni jõuda.

Võta ühendust