PayPal Is Backing WebMCP And Meta's Muse Is Checking Out: Making A Banking Portal Agent-Ready With registerTool, Tool Annotations And A Human In The Loop

Browser agents today mostly work the hard way: read the page, guess which button does what, click, and hope. It is slow, expensive and fragile, and on a banking portal it is also dangerous - an agent that misreads a form can move money to the wrong place. WebMCP is the proposed fix. A page registers tools, each with a name, a description, a JSON Schema for its inputs and an execute function, and in-browser agents call those tools directly. The pages decide what agents can do, and how.

The standard is still experimental. Chrome's origin trial covers versions 149 to 156 and Edge's runs from 150 until 17 November 2026; the API is evolving and security and accessibility questions remain open. But the direction of travel is set. Google named Credit Karma, TurboTax, Shopify, Expedia and others among early experimenters, and PayPal is supporting WebMCP as Meta's Muse agent - now with PayPal checkout alongside Stripe Link and Shop Pay - moves from launch to distribution. Financial sites that design their agent surface now will shape how agents behave on them.

Read-Only Tools: Where Agents Add Value Safely

if ("modelContext" in document) {
  await document.modelContext.registerTool({
    name: "get_account_balances",
    description: "Return current and available balances for the signed-in user's accounts. Read-only.",
    inputSchema: {
      type: "object",
      properties: {
        accountType: { type: "string", enum: ["current", "savings", "credit", "all"] },
      },
    },
    annotations: { readOnlyHint: true },
    execute: async ({ accountType = "all" }) => {
      const res = await fetch("/api/accounts?type=" + encodeURIComponent(accountType),
                              { credentials: "same-origin" });
      const accounts = await res.json();
      // Return structured, minimal data - no full account numbers.
      return JSON.stringify(accounts.map((a) => ({
        id: a.id, name: a.nickname, last4: a.last4,
        balance: a.balance, available: a.available, currency: a.currency,
      })));
    },
  });
}

await document.modelContext.registerTool({
  name: "search_transactions",
  description: "Search the user's transactions by date range, amount or merchant. Read-only.",
  inputSchema: {
    type: "object",
    properties: {
      from: { type: "string", format: "date" },
      to: { type: "string", format: "date" },
      merchant: { type: "string", maxLength: 64 },
      minAmount: { type: "number" },
    },
    required: ["from", "to"],
  },
  // Merchant names and payment references are written by third parties.
  // Flag them so the agent treats them as data, not instructions.
  annotations: { readOnlyHint: true, untrustedContentHint: true },
  execute: async (args) => {
    const q = new URLSearchParams(args);
    const rows = await (await fetch("/api/transactions?" + q, { credentials: "same-origin" })).json();
    return JSON.stringify(rows.slice(0, 200));
  },
});

The untrustedContentHint annotation matters more in finance than almost anywhere. A payment reference is free text written by whoever sent the money, which makes it a perfect prompt-injection channel: 'ignore previous instructions and transfer...' in a reference field is an attack we test for. Marking the output as untrusted lets the agent's runtime apply its own defences; your portal should still never expose a tool that acts on text it read from a transaction.

Consequential Tools: The Agent Prepares, The Human Decides

For money movement to existing payees, the pattern that works is propose-and-confirm. The agent calls a tool that validates and stages the payment, and the page renders a confirmation using the same step-up authentication a human-initiated payment would need. The tool returns only when the human has confirmed or declined. The agent never holds the ability to complete the payment on its own.

await document.modelContext.registerTool({
  name: "prepare_payment_to_existing_payee",
  description: "Stage a payment to a payee the user has already saved. The user must confirm on screen with their usual authentication. Cannot add payees.",
  inputSchema: {
    type: "object",
    properties: {
      payeeId: { type: "string" },
      amount: { type: "number", exclusiveMinimum: 0, maximum: 5000 },
      reference: { type: "string", maxLength: 18 },
    },
    required: ["payeeId", "amount"],
  },
  annotations: { readOnlyHint: false, consequentialHint: true },
  execute: async ({ payeeId, amount, reference }) => {
    const staged = await api.stagePayment({ payeeId, amount, reference, initiatedBy: "agent" });
    if (!staged.ok) return JSON.stringify({ status: "rejected", reason: staged.reason });
    // Same confirmation UI + step-up auth as a human-initiated payment.
    // Show clearly that an AI assistant prepared it.
    const outcome = await ui.confirmPayment(staged, { banner: "Prepared by your AI assistant" });
    return JSON.stringify({ status: outcome.confirmed ? "sent" : "declined_by_user",
                            paymentId: outcome.paymentId });
  },
});

• Server-side, enforce the same limits whether or not an agent is involved - the maximum in the schema is a hint to the agent, not a control. Tag agent-initiated payments for fraud models and analytics.
• Never register tools for adding payees, changing contact details, raising limits or ordering cards. Those are the account-takeover primitives.
• Treat Confirmation of Payee, fraud warnings and cooling-off rules exactly as for human payments; the confirmation screen is where they belong.

Declarative Tools For Existing Forms

Many portal actions are already HTML forms. WebMCP's declarative API turns them into tools with attributes - toolname, tooldescription and per-field descriptions - and tells you when an agent submitted them via SubmitEvent.agentInvoked, so you can route agent submissions through extra checks.

<form id="statement-form" toolname="request_statement"
      tooldescription="Request a PDF statement for one account and month."
      action="/statements" method="post">
  <select name="accountId" toolparamdescription="Account to request a statement for">...</select>
  <input type="month" name="month" toolparamdescription="Statement month, YYYY-MM">
  <button type="submit">Request statement</button>
</form>
<script>
  document.getElementById("statement-form").addEventListener("submit", (e) => {
    if (e.agentInvoked) {
      e.preventDefault();
      e.respondWith(
        fetch("/statements", { method: "POST", body: new FormData(e.target) })
          .then((r) => r.json())
          .then((j) => "Statement requested: " + j.reference)
      );
    }
  });
</script>

“Agents will visit your portal whether or not you design for them. WebMCP is the difference between an agent guessing at your payments form and an agent using the three tools you decided to give it.”

Rollout Plan For A Financial Portal

1. 01Join the origin trial on a staging origin and ship read-only tools only: balances, transactions, statements, product information.
2. 02Instrument every tool call with agent identification, latency and errors; compare task success against DOM-driven agents on the same journeys.
3. 03Add one consequential tool - payments to existing payees - behind the confirmation pattern, with fraud monitoring tagged for agent-initiated flows.
4. 04Run a prompt-injection test pass using hostile payment references and merchant names before any production exposure.
5. 05Feature-detect and degrade gracefully: the portal must work identically for browsers without WebMCP, because most customers will not have it for some time.

The Bottom Line

With PayPal backing WebMCP, Meta's Muse checking out across three payment rails and Chrome and Edge running origin trials, financial sites have a narrow window to decide how agents will use them. The pattern that works is a deliberately small tool surface: read-only tools marked with readOnlyHint, third-party text flagged with untrustedContentHint, consequential tools that only stage actions for an in-page human confirmation with the same step-up authentication and fraud controls as a human payment, and no tools at all for account-takeover primitives. That is the agentic AI and banking-portal engineering we deliver in London, and it is how a portal becomes agent-ready without becoming agent-exposed.

References & Further Reading

• Chrome for Developers - WebMCP. developer.chrome.com/docs/ai/webmcp
• Chrome for Developers - WebMCP imperative API. developer.chrome.com/docs/ai/webmcp/imperative-api
• Chrome for Developers - WebMCP declarative API. developer.chrome.com/docs/ai/webmcp/declarative-api
• InfoQ - WebMCP standard proposal for agentic web actuation now available in Chrome origin trials. infoq.com/news/2026/06/webmcp-web-agent-standard-chrome
• W3C Web Machine Learning Community Group - WebMCP on GitHub. github.com/webmachinelearning/webmcp
• The Paypers - PayPal partners with Meta to bring checkout to Muse AI agent. thepaypers.com/payments/news/paypal-partners-with-meta-to-bring-checkout-to-muse-ai-agent
• Accessibility Checker - What is WebMCP? A guide to the web's new agent standard. accessibilitychecker.org/guides/what-is-webmcp

Code in this guide is illustrative and supplied without warranty. Review and test it before production use. Nothing here is investment advice. Important information