WebMCP 2026 októberében: hogyan tehető egy weboldal használhatóvá az MI-ügynökök számára, és mit jelent valójában az origin trial

A WebMCP lehetővé teszi, hogy egy weboldal rövid listát adjon egy MI-ügynöknek arról, mit tud elvégezni, mindegyik tevékenységet névvel, leírással és bemeneti sémával (input schema), ahelyett, hogy az ügynök képernyőképekből és a DOM-ból próbálná kitalálni az oldal működését. Az az ügynök, amely talál egy check_order_status eszközt, meghívhatja egy rendelésszámmal. Enélkül meg kell keresnie a megfelelő mezőt, és rá kell kattintania a megfelelő gombra.

Ez az ígéret. A helyzet 2026. október 22-én szűkebb, mint ahogy a legtöbb ismertető sugallja. A WebMCP egy W3C Community Group javaslata, nem szabvány. A Chrome origin trialként (a Chrome korlátozott idejű, domainhez kötött funkciótesztje) futtatja, a bevezetésről még nem született döntés. Egyetlen fogyasztói ügynök hívja az eszközöket (a ChatGPT asztali alkalmazásába épített böngésző), és ez az ügynök figyelmen kívül hagyja a deklaratív, űrlapalapú változatot, amelyet október 8-án töröltek a specifikációból. A Safari motorjának csapata ellenzi a javaslatot; a Mozilla semleges.

Ez a cikk azoknak a fejlesztőknek és termékfelelősöknek szól, akik azt döntik el, hogy érdemes-e most WebMCP-t hozzáadniuk. Bemutatja, mi az API, ki hívja, hogyan kapcsolható be valódi látogatóknak, hogyan írhatók olyan eszközök, amelyek nem adnak töltött fegyvert az ügynök kezébe, és mit érdemes elsőként javítani, ha egyáltalán azt szeretné, hogy az ügynökök használják az oldalát.

Mi a WebMCP

A specifikáció egy JavaScript API-t határoz meg a document.modelContext objektumon, amelyen keresztül az oldal eszközöket regisztrál: „A WebMCP API lehetővé teszi a webalkalmazásoknak, hogy JavaScript-alapú eszközöket nyújtsanak az MI-ügynököknek.” Egy eszköznek van name, description és execute callbackje, opcionálisan pedig title, inputSchema (JSON Schema) és annotations mezője. Amikor az ügynök meghívja az eszközt, az oldal saját kódja fut, a felhasználó munkamenetével.

Három dolgot könnyű félreérteni:

• Nem szabvány. A dokumentum a Web Machine Learning Community Group Draft Community Group Reportja (a közösségi csoport tervezetjelentése), és ezt maga is kimondja: „Nem W3C-szabvány, és nem is szerepel a W3C szabványosítási útján (Standards Track).” A Chrome saját dokumentációja „javasolt webes szabványnak” nevezi. A jelentés dátuma októberben néhány naponta változik; szerkesztői a Microsofttól és a Google-től vannak.
• Nincs benne MCP. A specifikáció szerint az azt használó oldalak „úgy foghatók fel, mint Model Context Protocol szerverek, amelyek eszközöket valósítanak meg kliensoldali szkriptben”, majd hozzáteszi, hogy „nem írja elő azt a formátumot, amelyben az eszközök a böngészőügynök felé megjelennek”. A Mozilla véleménye nyersen fogalmaz: „A név félrevezető ... Itt nincs MCP.” Egy WebMCP-eszköz nem kapcsolódik a háttérrendszer MCP-szerveréhez, és nem is helyettesíti azt.
• Nem teszi Önt felfedezhetővé. A Chrome dokumentációja maga is felsorolja a korlátozást: „A klienseknek és a böngészőknek közvetlenül meg kell látogatniuk az oldalt, hogy megtudják, vannak-e rajta hívható eszközök.” A WebMCP annak az ügynöknek segít, amely már az Ön oldalán van. Azon nem segít, hogy megtalálják.

Az API csak biztonságos környezetben (secure context) érhető el, és egy tools Permissions Policy kapuzza, amelynek alapértelmezett engedélyezési listája 'self', így egy cross-origin iframe nem regisztrálhat eszközöket, hacsak a beágyazó oldal nem engedi.

Hol tart 2026. október 22-én

A Chrome 156, az eredeti trialidőszak utolsó kiadása, 2026. október 20-án elérte a stabil csatornát. A Chrome 162, a kért meghosszabbítás vége, a tervek szerint 2027. február 2-án kerül a stabil csatornára. Hogy a meghosszabbítás él-e, a trialkonzolból nem volt megerősíthető, ezért számoljon úgy, hogy valószínű, de nem biztos.

A meghosszabbítási kérelem megmutatja, miért kér a Chrome több időt: „Az origin trial visszajelzései az API javítását javasolták, amelyeket most valósítunk meg.” Ugyanabban a szálban a Google-től Dominic Farolino azt írta, hogy a csapat „reméli, hogy a meghosszabbítási időszakon belül áttérhet az I2S-re”, vagyis kérheti a bevezetést, és hogy „az imperatív API sokkal népszerűbb, mint a deklaratív, ezért a felhasználói igényekre válaszul többet fektetünk bele”. Megemlített egy folytatási API-t (continuation API), egy eszközstabilitási API-t (tool stability API) és az eszközméret korlátait is, amelyekből prototípus készül. Az API, amelyre ma fejleszt, változni fog.

Ki hívja valójában az eszközöket

Az eszközök regisztrálásához nem kell semmi. A használatukhoz ügynök kell, és az ügynökök listája rövid.

A Chrome saját tesztbővítményei. A Chrome dokumentációja két bővítményt kínál, köztük a Model Context Tool Inspectort, amelyekkel a bemutatókban és a saját oldalain kipróbálhatja az eszközöket. Saját modell-API-kulcs kell hozzájuk, és a Chrome megjegyzi: „Ezek a bővítmények nem a Gemini in Chrome részei.” Fejlesztői eszközök, nem ügyfelek.

A ChatGPT beépített böngészője. Az OpenAI egyik munkatársa fejlesztői fórumukon 2026. augusztus 25-én azt írta: „A site tools a ChatGPT megvalósítása a javasolt WebMCP-szabványból.” Dokumentációja feltételeket szab: meghatározott modellek, a legfrissebb asztali alkalmazás, az Enterprise-munkaterületeken rendszergazdai engedély, az Edu-munkaterületeken nem érhető el, és „az elérhetőség a fokozatos bevezetéstől is függ”. Azt is felsorolja, mit nem támogat: „Deklaratív API: a HTML-űrlapattribútumokkal definiált eszközök nem érhetők el site toolsként”, valamint az iframe-ekben regisztrált eszközöket, a same-origin iframe-eket is beleértve. Az OpenAI utasítása egyértelmű: „JavaScripttel regisztrálja az eszközöket a legfelső szintű oldalon”. A dokumentáció nem mondja meg, hogy az oldalnak kell-e Chrome origin trial token ahhoz, hogy a ChatGPT lássa az eszközeit.

Gemini in Chrome. A Google májusban azt mondta, hogy „hamarosan támogatni fogja a WebMCP API-kat”. Azóta nem találtunk elsődleges forrást, amely szerint támogatja. Egyelőre ne építsen rá tervet.

Mindenki más a régi módszerhez tér vissza. Minden böngészőben minden ügynök továbbra is a régi módon olvassa az oldalakat. A Chrome ezt saját kockázatértékelésében is leírja: „A Chrome böngészőügynökei továbbra is úgy működtethetik az oldalakat, mint korábban, a felhasználói viselkedés szimulálásával.” Az OpenAI: „Ha nincs megfelelő eszköz, az ügynök továbbra is használhatja a szokásos böngészőképességeit.” A WebMCP nélküli oldal nem láthatatlan az ügynökök számára. A rossz gombokkal és címke nélküli mezőkkel teli oldal viszont mindegyikük számára nehéz.

Az imperatív API

Ezt a változatot határozza meg a specifikáció, ezt támogatja a ChatGPT, és a Chrome szerint ezt részesítik előnyben a fejlesztők. Az eszköz az oldal meglévő logikáját csomagolja be. Íme egy csak olvasási keresés egy bejelentkezett ügyfél számára, a Chrome dokumentációjának és az OpenAI funkciófelismerésének (feature detection) mintájára:

if (typeof document.modelContext?.registerTool === 'function') {
  const tools = new AbortController();

  await document.modelContext.registerTool({
    name: 'check_order_status',
    description: 'Look up the status and tracking link of one of the signed-in customer\'s orders by its order number.',
    inputSchema: {
      type: 'object',
      properties: {
        orderNumber: { type: 'string', description: 'Order number as printed in the confirmation email' },
      },
      required: ['orderNumber'],
    },
    annotations: { readOnlyHint: true },
    execute: async ({ orderNumber }, { signal }) => {
      const res = await fetch(`/api/orders/${encodeURIComponent(orderNumber)}`, { signal });
      if (!res.ok) return `No order ${orderNumber} was found on this account.`;
      const order = await res.json();
      return `Order ${orderNumber}: ${order.status}. Tracking: ${order.trackingUrl ?? 'not available yet'}.`;
    },
  }, { signal: tools.signal });

  // When the page state no longer fits the tool:
  // tools.abort();
}

Ami fontos benne:

• A modell a nevet, a leírást és a sémát olvassa. A Chrome eszközleírásonként legfeljebb 500, paraméterleírásonként 150, eszköz- és paraméternevenként 30, eszközkimenetenként 1,5 ezer karaktert javasol, és megjegyzi, hogy „ezek az ajánlások változhatnak”. A specifikáció magyarázó dokumentuma (explainer) figyelmeztet: „Túl sok eszköz (például tucatnyi vagy száznyi) közzététele súlyosan ronthatja az ügynök teljesítményét”: azt regisztrálja, amire az oldal aktuális állapotának szüksége van, a többit pedig távolítsa el az AbortController jelével.
• Az execute második argumentuma egy AbortSignal-t hordoz, így a megszakított hívás leállíthat egy folyamatban lévő kérést.
• Az annotációk csak jelzések. A readOnlyHint olvasási műveletet jelöl. A consequentialHint mindent jelöl, ami foglal, vásárol, küld, töröl vagy utal, és a Chrome dokumentációja szerint „lehetővé teszi az ügynököknek és a böngészőknek, hogy kötelező felhasználói megerősítést kényszerítsenek ki”. Az untrustedContentHint az olyan kimenetet jelöli, amely véleményeket, felhasználói tartalmat vagy harmadik féltől származó adatot hordoz. Egy debugging annotáció a Chrome 156-tól létezik.
• Az oldal kódja is listázhat és futtathat eszközöket a document.modelContext.getTools() és az executeTool() segítségével, és egy toolchange esemény jelzi, ha a lista változik. Az executeTool() JSON-nal sztringgé alakított argumentumai a Chrome 155-től elavultak.

A Reacthez, az Angularhoz és a Vue-hoz is léteznek kísérleti segédkönyvtárak, a webmcp-types npm-csomag pedig TypeScript-típusdefiníciókat ad. A navigator.modelContext-et hívó régebbi útmutatók elavultak: a specifikáció 2026. május 27-én áthelyezte az API-t a document objektumra.

A deklaratív API: a Chrome trialjában benne van, a specifikációból kikerült

A deklaratív változat két attribútummal alakít át egy meglévő HTML-űrlapot eszközzé. Régi, űrlapokra épülő oldalaknak vonzó, mert semmi mást nem kell megváltoztatni:

<form toolname="request_quote"
      tooldescription="Send a request for a quote. The user reviews the form and submits it."
      action="/quote" method="post">
  <label for="email">Work email</label>
  <input id="email" name="email" type="email" required>
  <label for="details">What you need</label>
  <textarea id="details" name="details" required></textarea>
  <button type="submit">Send</button>
</form>
<script>
  document.querySelector('form[toolname]').addEventListener('submit', (e) => {
    e.preventDefault();
    const sent = sendQuoteRequest(new FormData(e.target)); // your existing submit, returning a promise
    if (e.agentInvoked) e.respondWith(sent.then(() => 'Quote request sent.'));
  });
</script>

A Chrome trialjában „amikor egy ügynök meghívja a toolname eszközt, a böngésző fókuszba hozza az űrlapot, és kitölti a mezőit. Az űrlap látható marad a felhasználó számára.” A böngésző a vezérlőkből építi fel a paramétereket: a nevükből, a hozzájuk tartozó <label> elemekből, a required attribútumból és a <select> opcióiból. Hacsak az űrlap nem hordozza a toolautosubmit attribútumot, „a felhasználónak kézzel kell a Küldésre kattintania a feladat befejezéséhez”, ami pontosan az, amit egy megrendelést leadó vagy érdeklődést küldő űrlapnál akar. A SubmitEvent.agentInvoked jelzi a kezelőnek, hogy egy ügynök töltötte ki az űrlapot, a respondWith() pedig, a preventDefault() után, visszaadja az eredményt az ügynöknek. A toolactivated és a toolcancel eseményt a document.modelContext objektumon az addEventListener segítségével figyelje: a window.ontoolactivated és a window.ontoolcancel a Chrome 156-tól nem támogatott.

A bökkenő a státusza. A magyarázó dokumentum legutóbbi változtatása, amely 2026. október 8-án történt, ezt a címet viseli: „A deklaratív API ideiglenes eltávolítása a specifikációból”, és most úgy szól, hogy a deklaratív párja „külön vizsgálat alatt áll ..., de jelenleg nem része a specifikációnak.” A ChatGPT nem támogatja. A Chrome a trialban még dokumentálja, a Google-es Farolino pedig a Mozilla szálában azzal érvelt, hogy „értéket látunk a deklaratív javaslatban pusztán a régi, különösen az űrlapalapú weboldalak miatt”. Kezelje egy kísérleten belüli Chrome-kísérletként: kipróbálni érdemes, egyedüli útként nem tanácsos.

Bekapcsolás valódi látogatóknak

Egy flag (chrome://flags/#enable-webmcp-testing) bekapcsolja a WebMCP-t a saját böngészőjében teszteléshez. A látogatóknak ez nem segít. Nekik az oldalnak origin trial tokenre van szüksége.

1. Regisztrálja az originjét a Chrome WebMCP-trialoldalán. Az origin trialek „nyilvánosak, és minden fejlesztő számára nyitottak”, a token pedig „bekapcsol egy funkciót az originje összes felhasználójának”.
2. Szolgáltassa ki a tokent minden oldalon, amelyen eszközöket kíván közzétenni, <meta http-equiv="origin-trial" content="..."> formában a <head>-ben vagy Origin-Trial: válasz-headerként. A token szkriptből is beinjektálható. Egy token egy originre érvényes; egy oldal többet is hordozhat.
3. Újítsa meg. Amikor egy trialt meghosszabbítanak, a Chrome azt kéri a regisztrálóktól, hogy „adjanak új tokent a trialban részt vevő minden originhez”, és „a Chrome figyelmen kívül hagyja az érvénytelen vagy lejárt tokeneket”. A lejárt token csendben csődöt mond: az eszközök egyszerűen nem jelennek meg.
4. Az Edge-hez regisztráljon külön, az Edge trialoldalán. Feltételei azt kérik, hogy „ahol lehetséges, vállalja a funkciófelismerés / a fokozatos visszalépés (graceful degradation) alkalmazását”.

A Lighthouse WebMCP-auditjaihoz is kell a trial regisztrációja, ezért aki token nélkül teszteli őket, azt fogja látni, hogy elbuknak.

Biztonságosan hívható eszközök írása

A specifikáció biztonsági fejezete nem normatív, és őszintén megmondja, hol van a teher: az ügynök manipulálásának megakadályozása „elsősorban az ügynök saját biztonsági modelljének felelőssége, nem olyasmi, amit ez a specifikáció normatívan kikényszeríthetne.” Az Ön eszközei viszont továbbra is meghatározzák, mekkora kárt tehet egy manipulált ügynök.

• A jelzések hazudhatnak, ezért az ügynökök nem bíznak bennük. A specifikáció: „egy rosszindulatú oldal elhagyhatja vagy félrevezetően megadhatja ezeket a jelzéseket.” Az OpenAI: „Egy eszköz neve, vagy az az állítása, hogy csak olvas adatokat, nem bizonyíték arra, mit csinál”, és a böngészőjében minden hívás biztonsági felülvizsgálaton esik át, a vásárlásokhoz és hasonló műveletekhez pedig továbbra is megerősítés kell. Ennek ellenére jelölje őszintén. Ezt használja egy gondos ügynök arra, hogy eldöntse, mikor kérdezzen rá a felhasználónál.
• Pontosan írja le a hatásokat. A specifikáció saját rossz példája egy „A jelenlegi bevásárlókosarat véglegesíti” leírású eszköz, amely „valójában vásárlást indít el. A felhasználó nem akart semmit venni.” Ha egy eszköz terhel egy kártyát, a leírás ezt kimondja, a consequentialHint pedig true.
• Mindig a szerveren hitelesítse a jogosultságot. Az eszköz a felhasználó munkamenetével fut: a specifikáció megjegyzi, hogy „az ügynökök örökölhetik a böngészőből a felhasználó identitását és hitelesítési környezetét.” Egy eszközhívás az adott felhasználó kérése, és ugyanazokat az ellenőrzéseket kapja. A magyarázó dokumentum tanácsa érvényes: „A kódban szigorúan, a sémában lazán validáljon”, mert a szigorú sémahibák megakaszthatják az ügynököket.
• Számítson prompt injectionre. A specifikáció ezt sorolja elsőként, három formában: az eszköz metaadataiba rejtett utasítások, az eszköz kimenetébe rejtett utasítások, és az eszközöket célpontként használó támadások. Az olyan kimenet, amely mások által írt szöveget hordoz (vélemények, üzenetek, termékkérdések), az untrustedContentHint alá tartozik, és adatként kell visszaadni, nem olyan prózában, amelyet egy ügynök utasításnak vehet.
• Tudatosan zárja ki az oldalakat. A Permissions-Policy: tools=() header elérhetetlenné teszi az API-t egy dokumentum és minden beágyazott tartalma számára. A fiókbeállítások, a fizetési oldalak és az admin képernyők jelöltek erre.

Egy óvatossági megjegyzés a Chrome dokumentációjához: biztonsági oldala szerint a tervezet tartalmaz egy requestUserInteraction() metódust, amellyel az eszköz futása közben rá lehet kérdezni a felhasználóra. A specifikáció 2026. október 20-i tervezetében nincs ilyen metódus, a magyarázó dokumentum pedig a felhasználói megerősítést még mindig nyitott kérdésként sorolja fel. Ne erre építsen.

Mit kifogásolnak a Safari és a Firefox mérnökei

A kifogásokat akkor is érdemes elolvasni, ha csak a Chrome-ra fejleszt, mert megmutatják, hogyan mehet félre a WebMCP a gyakorlatban.

A WebKit 2026. június 3-án közzétett álláspontja szerint a nehezen használható oldalakat HTML-ben és ARIA-val kell javítani, „ahol a felhasználó, a kisegítő technológia és az ügynökök is profitálnak”, az eszközökkel pedig „a törékenység csak a DOM-ból az eszközleírásokba költözik.” Az ügynököt kisegítő technológiának tekinti, amelyet nem szabad kiemelni: „A WebMCP az ellenkezőjét teszi, megfigyelhető ténnyé téve, hogy »egy ügynök vezérel«.” És megjegyzi, hogy a javaslatnak „nincs hozzájárulási és visszafordíthatósági modellje a következményekkel járó műveletekre”.

A Mozilla augusztusban a semleges álláspont mellett döntött: a WebMCP „potenciálisan értékes absztrakciót vezet be”, de „olyan felületet nyit, amelynek valós működési dinamikája túl sok nyitott kérdést hagy ahhoz, hogy teljes szívvel támogassuk”. Arra figyelmeztet, hogy az oldalak „olyan eszközöket kínálhatnak, amelyek nem felelnek meg az oldalon lévő felhasználó élményének”, például „a tipikus felhasználók számára láthatatlan prompt injectiont” alkalmazhatnak. Egyes Mozilla-mérnökök érdeklődést mutattak egy imperatív függvényhívási primitív iránt; ez nem a Mozilla támogatása.

A Chrome maga alacsonynak értékeli annak kockázatát a felhasználók számára, hogy a többi motor nem veszi át a WebMCP-t. Ennek a másik oldala, hogy egy oldal ma semmit sem nyer a Safariban vagy a Firefoxban azzal, ha eszközöket ad hozzá.

Ami ma minden ügynöknél működik

Minden böngészőügynök képernyőképeket, HTML-t és a kisegítő lehetőségek fáját (accessibility tree) olvassa. A Google web.dev-útmutatója az ügynökbarát oldalakról azt írja, hogy az ügynökök „a DOM-ot és a kisegítő lehetőségek fáját használják arra, hogy tiszta, strukturált listát kapjanak az interaktív elemekről, majd ezt összevetik a vizuális megjelenítéssel”. Gyakorlati listája rövid:

• Valódi <button> és <a> elemeket használjon, ne kattintható <div>-eket és <span>-eket.
• Minden <label>-t kössön a mezőjéhez a for attribútummal.
• Ne legyenek átlátszó rétegek az interaktív elemek fölött, és semmi interaktív ne legyen 8 négyzetpixelnél kisebb.
• Stabil elrendezés, amely nem tolódik el, miközben az ügynök kattintani készül.

Következtetése: „Minden, amit azért javaslunk, hogy egy oldal »ügynökre kész« legyen, az embereknek is jobbá teszi az oldalakat.” Ez majdnem szó szerint az is, amit a WebKit a WebMCP helyett kér. Ha a pénztára megbukik egy akadálymentességi auditon, azt javítsa ki, mielőtt egyetlen eszközt megírna.

A Lighthouse-nak a 13.2.0 verzió (2026. május 1.) óta van Agentic Browsing kategóriája, amely a Chrome-ban a 150-es verziótól érhető el, a PageSpeed Insights API számára pedig a Lighthouse 13.4.1 (2026. július 20.) engedélyezte. A kisegítő lehetőségi auditoknak azt a részhalmazát ellenőrzi, amely a gépek számára fontos, továbbá az elrendezés stabilitását, a regisztrált WebMCP-eszközöket és az azok nélküli űrlapokat, a séma érvényességét és az llms.txt fájl meglétét. A Chrome „tájékoztató jellegűnek és viszonyítási alap nélkülinek” nevezi: nincs 0-tól 100-ig terjedő pontszám. Az llms.txt-ről a Google Kereső saját útmutatója azt mondja, hogy figyelmen kívül hagyja az ilyen fájlokat: egy hozzáadása „sem nem árt, sem nem használ az oldal láthatóságának vagy rangsorolásának a Google Keresőben”. Az, hogy a Lighthouse ellenőrzi a fájlt, ezen nem változtat.

Érdemes-e most hozzáadni a WebMCP-t?

Shopifyon, Liquid-témával: nincs teendő. A Shopify kirakat-, kosár- és pénztáreszközei már élnek, „nincs mit telepíteni vagy beállítani”, a Shopify saját fenntartásával: „az ügynöktámogatás jelenleg egy origin trialen keresztül a Chromium-alapú böngészőkre korlátozódik”. A headless kirakatokat csak a Hydrogen fejlesztői előzetes verziója fedi le. Nem találtunk más kereskedelmi platformot, fizetési szolgáltatót vagy CDN-t, amely a vevői számára bekapcsolná a WebMCP-t.

Egyedi, headless vagy régi oldalon: attól függ, kik a felhasználói.

• Ha az ügyfelei vagy munkatársai a ChatGPT asztali alkalmazás böngészőjét használják, a legfelső szintű oldalon lévő imperatív eszközök az egyetlen fajta, amely eljut hozzájuk. Kezdjen két-három csak olvasási eszközzel a leggyakoribb feladata körül (rendelés állapota, elérhetőség, árajánlat), funkciófelismerés (feature detection) mögött, origin trial tokennel, és mérje meg, hívja-e őket valaki.
• Ha olcsón akar kísérletezni a Chrome-ban, a meglévő űrlapokra tett deklaratív attribútumok néhány óra munkát jelentenek. Ne álljon meg itt: a ChatGPT nem látja őket, a specifikáció pedig már nem tartalmazza őket.
• Ha nincs bizonyítéka arra, hogy ügynökök látogatják Önt, először a szemantikát, a címkéket és az elrendezést javítsa. Ez a munka minden ügynöknek és a kisegítő technológiát használó minden embernek segít, és semmi nem megy veszendőbe belőle, ha az API változik.

Minden esetben tartsa teljesnek a normál felületet. Az OpenAI tanácsa: „Őrizze meg a normál felületet azoknak az embereknek és böngészőknek, amelyek nem támogatják a WebMCP-t.”

Mi változhat

• Intent to Ship. A Chrome csapata a meghosszabbítási időszakon belül reméli, hogy kérheti, ez pedig a Chrome 162-vel (2027. február 2.) ér véget, ha a meghosszabbítás érvényben marad. A bevezetés megszüntetné a tokenek szükségességét a Chrome-ban.
• Az API alakja. Egy folytatási API (olyan eredmények, amelyek navigáció után a következő oldalon érkeznek meg), egy eszközstabilitási API és méretkorlátok prototípusa készül. A legutóbbi kiadások már eltávolították a window.ontoolactivated-ot és a sztringgé alakított argumentumokat.
• A deklaratív API sorsa. „Egyelőre” kikerült a specifikációból, a Chrome trialjában még benne van.
• A hívók. A Gemini in Chrome támogatását bejelentették, de nem vezették be. A specifikáció megvalósítási állapot oldala a Meta Ray-Ban Display szemüvegén futó webalkalmazások WebMCP-támogatását „hamarosan” érkezőként, a Brave Leo asszisztensében pedig kísérleti támogatást sorol fel.

Ha most ad hozzá eszközöket, tartsa őket egy modulban, funkciófelismerés mögött, hogy a következő változás egyetlen szerkesztés legyen.

Hol kaphat segítséget

Megépítjük a weboldalnak és háttérrendszerének azokat a részeit, amelyekhez az ügynökök hozzáérnek: a meglévő rendelés-, foglalás- és fiókkezelési logikát becsomagoló eszközöket, a jogosultságkezelést, amely egy ügynök hívását ugyanúgy kezeli, mint a felhasználó bármely más kérését, valamint a szemantikai és akadálymentességi javításokat, amelyek használhatóvá teszik az oldalt még azelőtt, hogy bármilyen eszköz létezne. MI-ügynök-fejlesztési és MCP-integrációs szolgáltatásunk a WebMCP-eszközöket és a háttérrendszeri MCP-szervereket is lefedi, amelyek a nevük ellenére más dolgok.

Ha tudni szeretné, mit lát ma egy ügynök az Ön oldalán, és hogy az eszközök változtatnának-e bármin az ügyfelei számára, írjon az office@c9group.dev címre.