WebMCP tool patterns: what to expose, by industry

The hard part of WebMCP isn't the API — registerTool() takes minutes. The hard part is tool design: choosing which capabilities to expose, naming them so an LLM knows when to call them, and drawing the line between read-only tools, action tools, and sensitive tools. This cookbook collects the patterns we use in our audits, organized by business type.

Three rules before you register anything

1. Expose tasks, not UI. An agent doesn't need click_next_button; it needs search_products. Wrap outcomes your visitors want, not the widgets that deliver them.
2. Mark read-only tools. Set annotations: { readOnlyHint: true } on anything that only fetches. Browsers and agents treat these with less friction.
3. Keep sensitive actions confirmable. Checkout, payments, cancellations: return a confirmation step in your tool result rather than completing irreversible actions in one call. The human stays in the loop by design.

E-commerce stores

document.modelContext.registerTool({
  name: "add_to_cart",
  description: "Add a product to the shopping cart. Use after confirming the product and variant with the user.",
  inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string" },
      variantId: { type: "string" },
      quantity: { type: "number", default: 1 }
    },
    required: ["productId"]
  },
  async execute({ productId, variantId, quantity = 1 }) {
    const cart = await window.store.addToCart(productId, variantId, quantity);
    return { success: true, cartTotal: cart.total, itemCount: cart.items.length,
             checkoutUrl: "/checkout" };
  }
});

Restaurants, salons & booking businesses

• check_availability — read-only: dates, times, party sizes. The tool agents call first.
• book_table / book_appointment — action: creates the reservation in the user's session; return the confirmation details.
• get_menu / get_services — read-only: items, prices, dietary flags.
• get_hours_and_location — read-only: sounds trivial, kills the #1 class of agent hallucination about your business.

Booking forms are also the perfect fit for WebMCP's declarative API — annotate your existing reservation form with tool attributes and it becomes an agent tool with no JavaScript at all (this is exactly what Chrome's "Le Petit Bistro" demo does).

SaaS products

• get_pricing — read-only: plans, limits, and what's included. Agents comparison-shop; make your answer canonical.
• start_trial_signup — action: begin signup with pre-filled context; let the user confirm.
• search_docs — read-only: your documentation as a queryable tool beats hoping the agent's crawl was fresh.
• get_service_status — read-only: uptime/status without a screenshot of your status page.
• For logged-in apps: expose your core workflow verbs (create_project, invite_member) — the agent works inside the user's authenticated session, which is WebMCP's structural advantage over a public API.

Local service businesses

• get_service_area — read-only: "do you serve ZIP 07030?" answered precisely.
• request_quote — action: structured intake (service type, address, timing) straight into your lead pipeline.
• get_pricing_estimate — read-only: even ranges beat silence; agents skip businesses they can't price.
• book_consultation — action: calendar slot booking.

Publishers & content sites

• search_articles — read-only: query your archive with filters (topic, date, author).
• get_article_summary — read-only: return your own canonical summary — you control how you're quoted.
• subscribe_newsletter — action: one clean conversion tool.

Anti-patterns we see in audits

• Tool soup: registering 30 tools nobody designed. Agents pick badly from bloated tool lists; 4–7 sharp tools outperform.
• UI-shaped tools: open_modal, set_filter_dropdown. Wrap the outcome instead.
• Descriptions written for humans: the description field is a prompt. Write it for the model: when to call this tool, what it returns, what it must not be used for.
• Irreversible one-shot actions: a cancel_subscription that executes instantly with no confirmation step is how you end up in an incident report. Sensitive tools should return a confirm-step.

Want this designed for your specific site? The deep audit ships a custom tool blueprint — names, LLM-ready descriptions, JSON schemas, and wiring notes matched to your actual pages. Platform-specific how-tos: Shopify, WordPress, Next.js.