OpenInquiry

OpenInquiry lets people bring their own AI agents to trusted publisher content while publishers decide exactly what those agents can use.

Comment

Problem

As a surgeon, I rely on journals, professional societies, and other trusted sources to make sense of complex evidence. Those sources need readers to return to the original work, where access rules, authorship, and updates remain visible.

People increasingly want their own AI agents to help them use that information. Today, the agent often has to interpret the page visually or depend on a separate integration. Neither approach gives the publisher a shared way to decide what the agent may search, what it may read, and what source information must travel with the answer.

Solution

OpenInquiry is a fictional medical journal and a working WebMCP reference implementation. The reader brings the agent, while the publisher decides what that agent can use.

The Journal of Guidelines publishes five synthetic articles and registers seven page tools. When an agent searches or retrieves material, the journal reads the signed site session, applies its rules on the server, and returns only the material permitted for that reader and use.

Every result preserves the author, publication status, access basis, use limits, and an exact link back to the supporting section.

Judges can ask the same question under four access conditions and watch the journal return a different result each time:

Reader access External credential recognized by the publisher What the journal returns
Guest preview No qualifying credential recognized Public abstract
Guest preview Zero-retention claim recognized Abstract and publisher summary
Full article access No qualifying credential recognized Complete question-relevant section
Full article access Zero-retention claim recognized Complete article text

OpenInquiry does not impose a universal character ceiling. The publisher chooses the representation and may still apply resource-, session-, use-, or caller-specific limits. In this fictional policy, the highest-permission state returns the complete provider-supplied article rather than a clipped passage.

The zero-retention setting is a judge-controlled simulation of a possible future assurance signal. In a production system, an independent issuer would govern that credential, and each publisher would decide whether to recognize it. The reader or agent could not award the credential to itself.

Why This Matters

WebMCP lets a website declare clear tools for the agent visiting that page, so the person and agent work with the same publisher, visible page, and signed-in session.

For a physician, the experience is straightforward: ask on the source website, receive the most complete material currently permitted, and open the exact supporting section for review. For a publisher, access remains a site decision. The publisher can authorize complete single-article delivery without exposing an unrestricted collection export.

OpenInquiry packages that interaction in a shared result format. Another publisher could use the same tool names and core fields while keeping its own content, policies, and website. OpenInquiry 0.1 is a working proposal, not an adopted standard.

How We Used AI

The reader asks the question and remains on the publisher's page. The agent can discover the journal, search its guidelines, check whether an article is current, retrieve the representation the journal permits, and open the exact supporting section.

The journal returns a consistent record containing authorship, publication status, access basis, use limits, supplied text, and source links.

OpenInquiry does not run another model on its server. It gives the user's existing agent a governed way to work with the website.

How We Used Codex

I used Codex throughout the project: to narrow the idea to one demonstration, write the OpenInquiry 0.1 proposal, build the Next.js application, connect the WebMCP tools to server-enforced policy, create the synthetic content, and test the public experience.

The hardest part was keeping the product story, interface, tool contracts, and access behavior aligned. Early versions still described bounded evidence after the highest-permission state had evolved to return the complete article. Codex helped me find those contradictions and test every state until the copy, interface, and server behavior agreed.

The project changed how I think about AI access to trusted information. Publisher control needs to be an explicit, inspectable decision about what the site supplies, with a durable path back to the source.

Key Features

  • Seven page-local WebMCP tools for discovery, access, search, retrieval, resolution, source opening, and publication status.
  • Four visibly different results for the same question, based on reader access and publisher recognition of a simulated external assurance signal.
  • Server-side access decisions derived from the signed site session rather than claims supplied by the agent.
  • Complete source context with authorship, status, use limits, and links to the exact supporting section.
  • Privacy-minimized receipts that omit the full prompt, raw query, login token, and permanent user identifiers.
  • A clear separation between working WebMCP behavior and the proposed future assurance layer.

Architecture

OpenInquiry uses Next.js 16, React 19, and TypeScript.

The journal registers seven tools with document.modelContext.registerTool when the browser supports WebMCP. Each page registers only the tools that belong on that page. The app removes those tools when the reader leaves the page.

The visible journal and the WebMCP tools use the same application services. A signed, HTTP-only cookie stores the fictional demo settings. The server reads that cookie and decides what the journal may return. The agent request does not contain an entitlement or data-policy flag.

After a protected retrieval, the server rotates the signed session cookie with a small ledger containing the provider, resource, representation, unit identifiers, and character counts. It stores neither the question nor the article text. Exact retries are idempotent, while distinct cumulative requests remain bounded.

The evidence inspector retains only the response already returned to the current browser tab and clears it when the judge changes the scenario.

Each tool returns a consistent JSON result with the source, the permitted material, the journal's decision, and the exact link back to the article. The short source record does not store the complete prompt, raw clinical query, credentials, login token, or a permanent user identifier.

On September 2, 2026, npm run check passed 90 tests in 17 files, 18 response schemas, four evaluator fixtures, five policy cases, 15 WebMCP runtime checks, seven profile-schema checks, and all 14 deterministic evaluator vectors. The production build passed its 18-asset protected-content scan, and 43 browser tests passed across all four policy states, five accessibility checks, route cleanup, exact source opening, and viewports from 320 to 1,440 pixels.

On September 3, 2026, the public ChatGPT Sites build was opened in Codex's in-app browser and exposed all seven page tools. knowledge_search found only the intended physical-activity guideline, and knowledge_status reported it as current. With full article access and the simulated credential recognized, a direct knowledge_retrieve call returned one full_text grant containing all 14,373 characters of the article, both exercise targets, and the final review section. The response preserved the publisher and canonical source while its minimized receipt omitted the question. An identical retry returned the same complete text, and knowledge_open moved and focused the visible page on #weekly-activity-recommendation. These results verify the fictional reference implementation on its public deployment. They do not establish publisher adoption, independent credential verification, or compatibility with every WebMCP client.

Known Limitations

  • OpenInquiry 0.1 is a working proposal, not an adopted standard or certification.
  • The journal, authors, access controls, and medical content are fictional or synthetic and are not for clinical use.
  • The demo does not connect to a real publisher, subscription, identity system, or independent assurance issuer.
  • Current WebMCP does not prevent an agent-capable browser from observing the visible reader page. A browser-enforced tool-only channel remains future work.
  • WebMCP does not govern how an agent stores, trains on, cites, or redistributes material after receiving it. The source record documents what the journal supplied; it is not proof of compliance or licensing.
  • The demo ledger covers sequential requests. A production publisher would need an atomic shared store to prevent simultaneous-request races and support operational monitoring.

Built With

Share this project:

Updates

Submission history