Test a WebMCP tool in a browser: registration, call and result

A WebMCP reference in source does not prove a successful tool call. Test three things separately: the page registers a tool, a controlled call returns the expected result, and the intended assistant uses it for the visitor's task. Check the public source first, then use the browser workflow below.

Prepare a browser and a small task

Follow the Chrome setup guide to enable WebMCP in an appropriate environment. Record the browser version, flag or origin-trial configuration, and test date. The API is evolving: methods in the current draft may differ from those available in a particular build.

Open the fictional opening-hours demo. Its only task is to return a predefined weekday schedule for a fictional help desk. It makes no network requests, changes no account data and cannot make a booking. Use the normal button first to establish the expected result.

Confirm registration

The demo feature-detects document.modelContext and reports whether registration resolved. If that interface is unavailable, check your browser setup and the API migration guide. Do not treat a missing browser feature as a failed source-level scan.

await document.modelContext.registerTool({
  name: "demo_opening_hours",
  description: "Return fictional help-desk hours for a weekday. Demo data only.",
  inputSchema: {
    type: "object",
    properties: { weekday: { type: "string", enum: ["monday", "friday"] } },
    required: ["weekday"],
    additionalProperties: false,
  },
  annotations: { readOnlyHint: true },
  execute: ({ weekday }) => JSON.stringify(readDemoHours(weekday)),
});

Make a controlled call and inspect the result

The demo's tool-test button uses getTools() and executeTool() when the browser exposes them. Otherwise it points you to Chrome's Model Context Tool Inspector. List the tools and call demo_opening_hours with weekday set to friday. These manual APIs are a test path; their availability does not establish which assistant clients support the page.

1. Confirm that the registered name and description match the tool you intended to expose.
2. Compare the result with the visible fictional schedule. Friday should return 09:00–16:00 and a demo: true marker.
3. Try a weekday outside the schema. Confirm it produces a validation error, not an invented schedule.
4. Reload the page and repeat. Check for stale registrations and console errors when adapting the example to an application.

Test the actual assistant task separately

In a client that supports your browser environment, ask for the fictional help desk's Friday hours. Observe whether the tool is called and whether the answer matches the returned data. A correct answer copied from visible page text is not evidence of a tool call. Record the client version, request, observed call and outcome; if you cannot observe a call, record that limitation.

For a client project, use the agency audit workflow to keep source findings, implementation changes and browser outcomes together. The imperative API guide explains the tool fields in more detail.