Fă-ți website-ul pregătit pentru asistenți astazi după-amiază

You are helping me make my website WebMCP-enabled, so AI assistants can USE it (book, order, look something up) instead of guessing from the page text. Work step by step, keep it practical, and be honest when something is not possible on my platform.

Context
- WebMCP is a W3C Web Machine Learning Community Group draft. Spec: https://webmachinelearning.github.io/webmcp/ — explainer, best practices and implementation status: https://github.com/webmachinelearning/webmcp
- Chrome's developer docs (overview, imperative API, declarative API, best practices, tool security): https://developer.chrome.com/docs/ai/webmcp
- The plain-language overview I read: https://busymate.ai/webmcp
- My site: <YOUR SITE URL>
- Built with: <PLATFORM>  (plain HTML / React / Next.js / Shopify / WordPress / Webflow / Wix / Squarespace / other)
- Where I can add code: <WHERE YOU CAN ADD CODE>  (theme files / a custom-code block / a plugin / I have a developer)

Step 0 — The fastest path, if my site already has our assistant installed
If the page already loads the assistant's embed script, the SHORTEST correct adoption is ONE call to its SDK, and you should prefer it over hand-writing the browser API:

  BusymateAI.registerPageTools([
    { name: "check_order_status",
      description: "Look up an order by its number and say where it is.",
      inputSchema: { type: "object", properties: { orderNumber: { type: "string", description: "The order number as printed on the receipt" } }, required: ["orderNumber"], additionalProperties: false },
      annotations: { readOnlyHint: true },
      execute: async ({ orderNumber }) => (await fetch(`/api/orders/${orderNumber}`)).json() },
  ]);

Why prefer it: that ONE call now covers ALL THREE surfaces itself — it registers each tool on the browser's native document.modelContext where the engine has it (Chrome/Edge behind the origin trial); where the engine has NOTHING yet, it installs its own registry as document.modelContext too, so ANY agent reading the standard API — not only ours — sees the same tools; and it always publishes the same tools over the assistant's own postMessage bridge, which works in Safari, Firefox, and inside an iOS or Android WebView where the native API does not exist at all. So a page with the assistant installed does NOT need the separate polyfill tag from Step 4 at all — one call is the whole adoption. It validates each tool independently and console.errors the exact field that is wrong — one bad tool never blocks its siblings in the same call, so nine good tools still register even if a tenth has a typo. Every argument in a tool's inputSchema needs its own one-line description; skip one and the tool still registers, with a console.warn naming it, because a missing description degrades the assistant's guess, it does not make the tool unusable. It also stamps the page so a scan can see WebMCP is on. Same annotations, same schemas, same consent rules as below — nothing about the tool design changes. Guide: https://busymate.ai/docs/guides/page-tools
It uses the SAME registry the polyfill installs, so a page that carries both has ONE tool list, not two — you never need to choose between them, and there is no order to get wrong.
If the site does NOT have the assistant installed, use the polyfill tag in Step 4 with the browser API or the declarative forms; the polyfill gives every browser the same document.modelContext, and everything below applies unchanged.

Step 1 — Audit my site
List the pages and forms a visitor uses to get something done (search, booking, order lookup, contact, returns, quotes, account changes). For each: the URL, what it does, and whether it CHANGES something (a booking, a payment, a return) or only READS.

Step 2 — Propose 3 to 7 tools
- Name each tool with a verb that says what it DOES: book_appointment, check_order_status, start_return. A tool executes the action; if the site needs the person to finish it, name it as the step it really performs (start_return), never a vague start_booking_process.
- One job per tool, no overlapping tools.
- Inputs are what a person would SAY — "next Tuesday at 10", "Express" — never internal IDs or codes the assistant would have to guess.
- A strict JSON Schema per tool: type "object", properties with a one-line description each, required, additionalProperties false. Descriptions under about 500 characters, parameter descriptions under about 150. EVERY property needs its own description — an argument with none makes the assistant guess its meaning, so write one even for an argument that feels obvious.

Step 3 — Choose the route per tool
(a) A form already exists → prefer the DECLARATIVE route: add toolname and tooldescription to the <form>, toolparamdescription to each input/select, and toolautosubmit when the form should submit on the assistant's call. The form keeps working for people exactly as before.
(b) No form → the IMPERATIVE route: document.modelContext.registerTool({ name, description, inputSchema, annotations, execute }).

Step 4 — Write the code, following these rules
- Works in every browser, FIRST: put the polyfill ABOVE any code that registers tools, in the <head> (or at least before the registration script):
  <script src="https://busymate.ai/webmcp/polyfill-1.0.1.js" integrity="sha384-pLZ5lO3gwZIn8Nim+hDrUQY+bvpliRtZhrS1O1OGRFB3lvoW0sZ71DUFHIk3m+DG" crossorigin="anonymous"></script>
  It feature-detects and does NOTHING where the browser already has WebMCP (Chrome 149 / Edge 150 with the origin trial or the testing flag), and it gives every other browser today — Safari, Firefox, Chrome and Edge without the trial, the WebView inside an app — a spec-shaped document.modelContext plus the assistant's discovery bridge, so the same code registers everywhere. Keep the integrity and crossorigin attributes exactly as given (the file is version-pinned). Never overwrite document.modelContext yourself and never stub it in tests: if the polyfill is present the API is there; if a browser is native the polyfill stands down.
  Honest limit, say it in your answer: a browser's built-in agent (Chrome's, Edge's) and ChatGPT Desktop only see the tools where the browser itself supports WebMCP. With the polyfill the tools work everywhere for cooperating assistants — your mate's widget and quick start, and any agent that reads the page or its bridge.
- Feature-detect after the tag anyway: const ctx = document.modelContext; if (!ctx) return; — a silent no-op for the one case where even the polyfill is absent (the script blocked, or a plain http page: the API exists only on https and localhost). (Older tutorials use navigator.modelContext; the spec moved to document.modelContext in July 2026 — target document; the polyfill also answers navigator.modelContext for older code, and only optionally fall back with ?? navigator.modelContext for older trial builds.)
- Annotations: readOnlyHint: true on lookups; consequentialHint: true on anything that books, pays, changes or deletes; untrustedContentHint: true when a result contains user-generated or third-party text.
- Consequential tools must NOT bypass confirmation: the browser or assistant asks the person before running them. Do not add any auto-confirm, do not skip the site's own confirmation step, and never mark a consequential tool readOnlyHint.
- Register with page state: register on mount, pass an AbortController signal in the registerTool options, and abort on unmount or navigation, so a tool the visitor cannot see is never offered.
- Reuse the site's existing functions, endpoints and permissions. No new backend privileges, no API keys or secrets in the browser, and never return personal data the signed-in visitor could not already see on the page.
- Return a short, verifiable result (under about 1,500 characters). On failure return a clear message, not a stack trace. Validate inputs in code; keep server-side validation and authentication exactly as they are.
- exposedTo: keep the default (same origin only). Add exposedTo only for a trusted embed origin you can name, such as the assistant's own iframe — for your mate that is exposedTo: ["https://busymate.ai"] (or my own assistant's address if it runs on its own domain); the polyfill's bridge answers exactly those origins and ignores every other window.
- Do not add a "tools" Permissions-Policy header or allow attribute unless a cross-origin iframe genuinely needs the tools.

Step 5 — The origin trial
For Chrome's own built-in agent to see the tools in Chrome 149 (and Edge 150) the page needs an origin-trial token: register the site at Chrome's WebMCP origin trial and place <meta http-equiv="origin-trial" content="..."> in the <head>. Tell me exactly where that goes on my platform. The token switches on the browser's NATIVE API; the polyfill covers every other browser and stands down where the token is active. Without the token or the local testing flag, Chrome has no native document.modelContext and the polyfill's registry serves instead — say in a code comment which of the two is serving.

Step 6 — Give me the test checklist, filled in for my site
1. Any browser, no flag — Safari, Firefox, plain Chrome: with the polyfill tag in place, document.modelContext is defined and (await document.modelContext.getTools()).length equals the number of tools you registered, and every name is a verb. Then Chrome 149 or newer with chrome://flags/#enable-webmcp-testing turned on (or the origin-trial token served): reload and check the same count from the browser's native API — window.busymate is undefined there, which means the polyfill stood down.
2. In the DevTools console, every tool's inputSchema and annotations read back exactly as written.
3. Execute one read-only tool with document.modelContext.executeTool(tool, JSON.stringify({ ... })) — Chrome's shape; the polyfill also accepts a plain object — and check the result is what the page shows.
4. Trigger one consequential tool through an assistant and confirm it ASKS before running.
5. Navigate away and back: the tools unregister and register again — no stale tools.
6. Run Lighthouse; the "Registered WebMCP tools" audit lists every tool.

Platform notes — apply the one that matches my site
- Shopify: every Liquid storefront already exposes Shopify's standard storefront tools (catalog, cart, checkout, policies) since August 2026, with nothing to install — those are native-only (Chromium). Custom tools need theme code (theme.liquid) and Shopify does not document extending its own set — propose only what theme JavaScript can reach, and put the polyfill tag in theme.liquid above your registration script.
- WordPress: a small plugin or code snippet can register tools; the WebMCP Bridge plugin already covers posts, menus, Contact Form 7 and the WooCommerce cart. Write actions go through WordPress nonces and the REST API. Enqueue the polyfill in the <head> before your snippet.
- Webflow: paste into Site or Page settings custom code (up to 50,000 characters; a Code Embed element allows 10,000) — the polyfill tag in the head code, your registration in the footer code. Only page JavaScript — the actions are Webflow forms and CMS pages.
- Wix (Settings → Custom Code, or Velo) and Squarespace (Website Tools → Code Injection, Business plans and up): only what the page's own JavaScript can reach; no server code. The polyfill tag goes in the header injection, the registration in the footer.
- If my platform lets me add only HTML, use the declarative form route.

Deliver, in this order: (1) the audit table, (2) the tool list with name, description, input schema and annotations, (3) the code for each tool with comments, with the polyfill tag first, (4) exactly where to paste it on my platform, (5) the test checklist filled in for my site. Keep it honest: if something is not possible on my platform, say so instead of inventing a workaround.

When you are done, I will paste the result back into your mate's quick start at https://busymate.ai/#quickstart to see my assistant use it.