Research-Devices WebMCP

Faster, traceable instrument comparison through four read-only WebMCP tools.

Comment

Inspiration

Researchers can spend substantial time choosing equipment because specifications, pricing conditions, source context, and limitations are spread across different pages and formats. Research-Devices organizes information for more than 1,500 instruments in its separate production service. This challenge build explores how a WebMCP-capable browser can retrieve decision material as structured evidence instead of piecing it together from page text.

Research-Devices already offered a human-facing research-equipment information service before the challenge. For the challenge, I built a separate interaction model: the page gives a browser AI four read-only functions it can discover and call directly.

What it does

Research-Devices WebMCP exposes four read-only tools:

  • search_devices searches eight fictional demonstration records.
  • compare_devices compares two to four instruments in the same category using the same field names and units.
  • get_price_range returns fictional price records without mixing currencies, pricing conditions, or configurations.
  • get_literature_signal returns device-name mention counts from twelve fictional research records created for this demo, with explicit interpretation limits.

Every response includes a concise summary, stable demo-record URLs, source references, a dataset version, and limitations. Missing values remain missing. Fictional price records with different conditions are not combined. Device-name mention counts are not described as papers, citations, verified use, or proof of performance. The tools expose evidence and trade-offs; the researcher makes the decision.

The public challenge build uses only purpose-built fictional records such as RD-SYN qPCR A and RD-SYN qPCR B. They demonstrate the workflow and data contracts; they are not claims about real commercial products. The build contains no production catalog, member data, user submissions, account information, or confidential material.

Why WebMCP improves the experience

A conventional browser agent must inspect page layout, infer which controls matter, move through several interface states, and extract facts from visual results. WebMCP replaces that guesswork with discoverable functions, constrained JSON inputs, predictable outputs, and read-only annotations. The agent can retrieve structured evidence while the researcher can inspect the inputs, sources, dataset version, and limitations.

The interface distinguishes three activities:

  • ordinary human interactions;
  • a deterministic on-page preview using the same processing logic; and
  • tool executions that reach the page through WebMCP.

The preview is never presented as an AI-agent call.

What people and agents can do together that was difficult before

Without structured WebMCP tools, an agent helping with instrument selection must reconstruct a comparison from rendered pages. It can lose a pricing condition, misread what a mention count represents, or silently fill a missing specification.

Here, a compatible client calls structured functions and receives values together with currency, pricing condition, configuration, dataset version, source URL, and limitations. The page records each WebMCP tool execution with its exact input and result, while making the same source URLs clickable for the researcher. It shows which tools reached the page without claiming to identify the calling AI feature.

That combination — structured page-provided capabilities plus a human-readable activity record in an ordinary static web page — is the core WebMCP benefit.

Why WebMCP rather than a server-side MCP server

The same four functions could be served by a remote MCP server. Three properties appear when the page itself is the tool provider:

  • No site-specific connector step. In a WebMCP-capable browser, the capability travels with the URL; no separate connector or site-specific API key is required.
  • One shared surface. WebMCP tool activity appears in the same document the researcher is reading.
  • Sources the human can open. Every product and source URL handed to the agent points to a page within this demo site, so the agent's source and the researcher's next click resolve to the same document.

How judges can test it

Native WebMCP is exposed only by a supporting browser. In the latest ChatGPT desktop app, open the built-in browser and enable Settings > Browser > Permissions > Enable site tools; current availability is listed in the OpenAI Site tools guide. For local Chrome testing, enable chrome://flags/#enable-webmcp-testing and restart Chrome; Chrome documents its origin trial separately in the official WebMCP guide. To confirm the API is ready, evaluate typeof document.modelContext?.registerTool; it should return function.

Then open the live demo and give the agent this request:

Compare fictional RD-SYN qPCR A and B for a 96-well workflow that needs 6 detection channels, up to 6 multiplex targets, an audit-trail capability, and a ¥6,000,000 ceiling. Use all four Research-Devices WebMCP tools. Compare specifications using the same field names and units, check the fictional JPY price records without mixing currencies or pricing conditions, and report device-name mention counts in 12 fictional research records created for this demo. Include record URLs, all source links, and every limitation, and explain the trade-off without choosing a universal winner.

All four tools should run, and the on-page WebMCP activity panel should show four tool executions. In a browser without WebMCP, the site still works and the inspector buttons run the same processing logic, but the WebMCP activity panel correctly remains empty. A deterministic local equivalent is npm run verify, followed by npm run dev and npm run eval:webmcp:smoke; see docs/TESTING.md.

Representative workflow

The main workflow compares RD-SYN qPCR A and RD-SYN qPCR B. The client first locates the two demonstration records. It then compares specifications using the same field names and units, retrieves separately identified fictional price records, and checks device-name mention counts across twelve fictional research records.

Neither record meets every constraint. B has six detection channels, supports six targets, and has an audit-trail capability, but its single fictional price record is ¥6,900,000. A is within the ¥6,000,000 ceiling based on two fictional price records, but has four channels, supports four targets, and has no audit-trail capability. WebMCP makes the conflict, sources, and limitations visible; the researcher decides.

How I built it

The application is a static bilingual site built with HTML, CSS, JavaScript modules, and checked-in JSON data. The English and Japanese interfaces share the same four tool definitions, JSON Schemas, processing logic, runtime guards, and fictional dataset.

The page registers its tools through document.modelContext.registerTool(). Inputs have explicit limits, outputs and URLs are validated at runtime, and compact responses stay within the browser-agent response budget.

The application has no backend, authentication, cookies, analytics, persistence, arbitrary remote fetching, or write operations. Automated tests cover domain behavior, input and output validation, localization, static-build safety, and Native WebMCP discovery and execution.

What existed before the challenge, and what is new

Area Existed before the challenge Built during the challenge
Research-Devices Human-facing research-equipment information service and its internal catalog workflow Separate WebMCP challenge application
Agent tools None Four read-only WebMCP tool contracts and handlers
Public challenge data None Research-Devices-owned fictional demonstration records and release boundary
Interface Existing production website New bilingual agent console, guided preview, and WebMCP activity record
Safety Existing production access controls Runtime input/output guards, URL validation, response limits, and static security policy
Verification Existing site testing WebMCP discovery/execution cases and challenge-specific automated tests
Hosting and repository Existing production infrastructure Dedicated public repository and isolated challenge deployment

Verifiable challenge files include:

  • src/webmcp.js — WebMCP contracts, compact agent responses, and registration;
  • src/tools.js and src/data-store.js — read-only handlers and dataset validation;
  • src/app.js — bilingual console, on-page inspector, and WebMCP activity record;
  • tests/webmcp.test.mjs and tests/webmcp-evals.json — discovery and execution verification.

The production Research-Devices application, hosting, DNS, authentication, databases, full catalog, and member functions are neither included nor modified.

Challenges

The hardest problem was preserving meaning at the boundary between an agent and evidence. One fictional price record is not automatically a range. A device-name mention count from fictional research records is not proof that an instrument was used or validated. A missing specification should not be guessed. These constraints shaped both the tool contracts and the visible limitations.

A second challenge was proving what happened without overclaiming. The page can verify that a registered WebMCP tool ran, but it cannot infer which AI feature initiated that call. The interface therefore reports only the tool name, input, result, and limitations it can verify.

Accomplishments

I built one coherent four-tool journey that connects discovery, specification comparison, fictional price records, and device-name mention counts without hiding uncertainty.

The same implementation supports English and Japanese, remains useful as a normal website when WebMCP is unavailable, and stays completely separated from the existing production service.

What I learned

Agent-native UX is not simply a faster interface. Reliable agent tools need constrained inputs, predictable outputs, sources, explicit uncertainty, and a clear boundary between retrieval and decision-making.

I also learned that visible proof matters. A deterministic preview helps a judge understand the workflow, but it must remain clearly distinct from an actual WebMCP tool execution.

What's next

Future work could apply the same read-only pattern to the separate production catalog of more than 1,500 instruments after a dedicated public-data and source review. That integration is not part of this eight-record challenge demo.

Built With

Share this project:

Updates