DSTAR

Inspiration

AI agents can already generate polished documents and artifacts in seconds. The collaboration layer has not caught up: review gets scattered across chat transcripts, copied excerpts, replacement files, and format-specific tools. Reviewers lose the exact sentence and version they meant, while agents lose the live state of the page.

We built DSTAR so agents can create and revise, while people review, comment, and make the final decision in the document itself. DSTAR means document star: one HTML-based artifact model for anything an agent can create, with review built in.

What it does

DSTAR keeps one canonical artifact made of HTML, CSS, and local assets. The same Viewer renders conventional documents, rich interactive explainers, slides, and UI design specs. Reviewers can select exact text, open comment threads, and reply. An external agent can draft a comment or reply and can propose a complete new revision. Drafts remain editable, proposals remain pending, and only the Owner can explicitly accept or reject a revision.

Comments and revision decisions stay separate: accepting a useful update does not silently resolve the discussion that motivated it. Every proposal is immutable and based on an exact accepted revision.

Why WebMCP

A conventional MCP server can expose a stored document, but it does not know what the person is reviewing in the browser right now. DSTAR registers narrow page tools with document.modelContext.registerTool so the external agent receives the exact displayed revision, selection, focused comment, current role, and pending proposals.

That makes natural instructions such as “rewrite this” or “help me reply” possible without copying text, hashes, or comment IDs into chat. It also preserves the trust boundary: the agent can prepare an editable comment or reply draft and can submit a pending revision, but it has no tool to post, accept, reject, or resolve on the person's behalf.

The public demo exposes five tools:

• get_review_context
• read_document
• draft_selection_comment
• draft_comment_reply
• propose_revision

How we built it

The top-level Viewer owns WebMCP registration and renders authored documents in a restricted frame. The persistent implementation crosses a limited JSON bridge into a filesystem-backed TypeScript Engine with immutable revisions, keyed mutations, role-bound sessions, reopenable history, and exact Origin and resource checks. The public static deployment applies the same exact-revision and human-decision model with browser-local sample state, so every judge gets a clean, credential-free workspace.

We added one review model across four formats, a document library, comment threads, Owner and Reviewer capabilities, version review, slide thumbnails and keyboard navigation, scoped agent handoffs, and deployment tooling. The test suite covers unit, integration, security, conformance, real HTTP persistence, and process restarts. We also verified native WebMCP tool discovery and calls in the ChatGPT in-app browser without injecting a polyfill.

Challenges

The hardest part was keeping live page context useful without giving the agent invisible authority. Selections, focused comments, and revisions can all drift while an agent is working. We fail closed on those mismatches, bind proposals to an exact base revision, keep drafts explicit, and leave every consequential decision in the Viewer.

A second challenge was unifying documents, rich HTML, slides, and UI design without forcing authors into a parallel source format. Treating HTML as the portable artifact and adding presentation behavior in the Viewer gave us both expressive rendering and one consistent review layer.

What we learned

WebMCP is most valuable where transient browser state matters. The benefit is not merely another way to call a backend; it is a precise bridge between what a person is looking at and what an external agent can safely prepare. The page can carry context while still reserving posting, acceptance, rejection, and resolution for people.

Built With

• webmcp