Your Agent Is an Infinite Canvas

How do you bring a visual reading experience to the places your audience already uses? Rachel Lee Nabors approaches that question through both browser engineering and comics. Their work spans Firefox DevTools at Mozilla, the W3C’s Web Animations API, Microsoft Edge, and React.dev and ReactNative.dev. After three years consulting with AI startups and browser companies, Nabors introduces a new role as Principal Developer Experience Engineer at Arize—with a practical reminder that prompt changes and model migrations can break agent flows, and evals help catch those failures.

Before that engineering career, Nabors made ad-supported webcomics for teenage girls on a site in the iVillage network. Nabors reports that the comics reached 400,000 weekly readers. Learning web development was a way to reach those readers where they were. The archive’s patterned backgrounds, illustrated announcements and goth-and-emo sensibility belong to the MySpace-era web of 2006.

The browser is more than a document reader. It can render video, audio and interactive experiences, with APIs that extend what a page can do. Nabors’s interactive Alice in Wonderland used the Web Animations API to explore that possibility. The same interest now runs through The Agentic Web newsletter and ASSA, the Antisocial Social Agent: an MCP app that places Twitter and Bluesky together without requiring visits to their sites or exposure to their recommendation algorithms. Existing browser primitives can also make an agent a canvas for interaction.

The concrete project starts with a neglected comic archive. Nabors assembled it around 2010, then moved on; eventually it accumulated 404s, broken images and infrastructure failures, including a failed CDN. Repairing it offered a chance to make the comics available in agents too. Women who grew up reading them still send fan mail, so the goal remains familiar: preserve the work and meet its audience where they are now.

Rachel the Great supplies the artwork for the demonstrations. Using their own comics avoids the complications of demonstrating with someone else’s copyrighted images. Nabors also describes treating the artwork with glazing to discourage training use and points readers toward the companion repository for more information.

The target is one server serving three client relationships:

The implementation proceeds through web-hosted MCP tools and transports, MCP apps, then WebMCP. Hosting matters: a server running locally on its developer’s machine is different from one readers can connect to on the web. Nabors predicts that MCP apps could become the next web pages; the archive tests that idea with an existing body of content.

An MCP transport determines how the client and server exchange messages. With stdio, short for standard input/output, the client launches the server as a local process. The user’s configuration supplies the command and its arguments; messages travel through stdin and stdout, and the process stays alive for the session. Nabors’s mnemonic is Phil Collins’s “Sussudio,” but the practical distinction is the process lifecycle and the setup it asks of users.

With HTTP, the server instead runs as a web service listening at an endpoint. Nabors focuses on POST requests and the fit with serverless hosting, naming Vercel and Cloudflare edge functions as places to run it. The Streamable HTTP specification also defines GET/SSE behavior and optional sessions; POST describes the client-to-server messages, not the transport’s entire behavior. Security and privacy design are outside this demonstration’s scope.

In Claude, the recorded setup follows these steps:

1. Find the connector settings.
2. Enter a name and the server URL, using the demonstrated /MCP endpoint.
3. Select Add.
4. Review the connector’s tool permissions.

The URL removes the local launch configuration, but the buried settings still create friction. Nabors chooses always-allow permissions because this particular server is their own, familiar server.

The first tools resemble the website’s navigation. They list comics, storylines and characters; search comic transcripts; and find pages featuring a particular character. Storylines retain the arcs, beginnings and endings that make the collection navigable. Character search answers a more personal request: show every appearance of the cat. These tools return structured JSON, except transcript retrieval, which returns Markdown.

That makes the collection accessible to the agent, but the tools-only demonstration is still verbose. Claude narrates its discoveries at length. Finding a comic and talking about a comic are not yet the same as giving someone a comfortable way to read it.

Collection-wide analysis exposes another limitation. Nabors describes a collection of 533 comics and wants their full transcripts available for analysis of themes and character arcs, rather than retrieved one comic at a time. MCP resources are the intended vehicle for supplying that reference context. In the clients Nabors tried, however, resources existed on the server without a usable way to access them in the interface. The resource specification defines contextual data while leaving interaction and context inclusion to applications; a server exposing resources does not guarantee that a client will make them useful.

Nabors reports a similar problem with documentation tools: coding agents can be reluctant to call an MCP tool merely to add Markdown documentation to context. The proposed alternative is application-driven preparation. When a harness switches into React work, for example, it could fetch the relevant React resources and prime the context before the agent needs them. That is a proposed harness behavior, distinct from the tools-only comic demonstration.

Tools can provide more than JSON, text or Markdown: they can lead to an interactive app. For comics, the obvious improvement is a reader with pictures instead of another wall of text.

Nabors compares chat’s role in agent interfaces to the command line’s role in software. Their mother, a COBOL programmer, insisted on opening games through DOS commands rather than double-clicking icons. An iPhone, by contrast, makes tapping the ordinary way to act. A blank chat box can similarly demand expertise that an interface could supply. Nabors calls it “starfish design”: it sits there while the user does the work.

A user who already knows Linear can arrive knowing it is a ticketing system and which information to request. Someone unfamiliar with a system has no such starting point. Without visual cues, discovery becomes a text adventure—an especially poor model for something like doing taxes. MCP apps provide inline rich interfaces using familiar HTML, CSS and JavaScript. Nabors bundles them into a single file, an approach that recalls DHTML more than it requires a new visual programming model.

The demonstration begins with a request to read Crow Princess. Claude locates it in the comics collection and invokes Get Page. The result is an embedded reader that can reveal creator commentary and reader comments, move forward and backward, and switch into text mode to display the transcript. It retains the website’s appearance and reuses its resources. The conversation finds the work; the reader supplies the controls for actually reading it.

Get Page has a description and an input schema requiring a comic ID, storyline ID and page number. Nabors notes that the storyline ID and page number should be enough and intends to remove the redundant comic ID. The important addition is UI metadata pointing to the app resource. The documented field is _meta.ui.resourceUri; a minimal metadata fragment looks like this:

{
  "_meta": {
    "ui": {
      "resourceUri": "ui://comic/reader.html"
    }
  }
}

The URI identifies the HTML resource the host retrieves and renders for the tool.

The reader runs in a sandboxed iframe. Nabors describes the demonstrated environment as an island: a single HTML file with embedded assets, including Base64 where needed, no usable local storage for carrying state across iframe instances, and server operations requested asynchronously through callServerTool. These constraints shape the app’s packaging and state management.

The economical build strategy is to reuse the website’s design system. Nabors shares fonts and CSS from the same server, configures resource access, and bundles the HTML and JavaScript components with Vite single file. An embedded reader can therefore retain the site’s visual identity without becoming a separately maintained frontend.

The remaining failures tend to appear at the boundary with the host:

• Links: Nabors uses the host-mediated appRef.current.openLink path rather than assuming window.open or ordinary anchor navigation will work.
• External assets: Fonts and images can be blocked by the app’s Content Security Policy. Missing assets are a reason to inspect CSP first.
• Network access: CSP and CORS are different checks. In the current MCP Apps documentation, resourceDomains permits asset origins and connectDomains permits connection origins; the destination server’s CORS policy separately governs cross-origin access.

The talk initially uses CORS terminology before identifying CSP. Its restrictive host experience should not be read as a universal requirement to Base64-embed everything or as a blanket prohibition on app networking: current documentation allows explicitly permitted external assets and connections.

Nabors contrasts MCP apps’ tool calling with MCP-UI, then applies it to the reader’s forward and backward controls. Some tools exist only to support the interface, not to produce a useful conversational response. For those, Nabors recommends app-only visibility—visibility set to app—so the model does not select an internal navigation tool and present its JSON as if that were the reading experience.

The third client relationship keeps the person’s agent in a browser. Browser agents often navigate by interpreting screenshots or traversing the DOM. Visual interpretation requires model computation; consuming markup spends tokens discovering something as simple as the next URL. The page already has the relevant functions and links. WebMCP exposes those actions directly, reducing the need to infer how the interface works.

Nabors describes this as making each HTML page a miniature tools server, but cautions against treating WebMCP as MCP implemented in a browser. The relationship is compared to JavaScript and Java: the names suggest more equivalence than the underlying specifications provide. WebMCP takes inspiration from MCP, and the specifications can diverge.

There are two authoring approaches:

The declarative example adds toolName and toolDescription attributes to a form. The imperative example uses navigator.modelContext.registerTool. Because the comic site has few forms beyond search, Nabors mostly uses imperative registration.

The registration procedure is straightforward: feature-detect modelContext, then supply a name, description, input schema and execution callback. For next-page navigation, the callback finds the page’s link[rel="next"] and returns the destination. This JavaScript follows the navigator-based API shape demonstrated in the recording:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "next_page",
    description: "Get the next comic page's navigation destination.",
    inputSchema: {
      type: "object",
      properties: {},
      additionalProperties: false
    },
    execute: async () => {
      const next = document.querySelector('link[rel="next"]');
      return {
        content: [{
          type: "text",
          text: next ? next.href : "There is no next page."
        }]
      };
    }
  });
}

The page supplies an explicit destination instead of asking the agent to discover and click a visual control. This callback returns the destination; it does not itself call location.assign. At the time of the talk, the standard was still developing. Later Chrome imperative API documentation uses document.modelContext.registerTool, while its declarative documentation spells the form attributes toolname and tooldescription and treats automatic submission separately through toolautosubmit.

To demonstrate this developing browser path, Nabors uses the MCP-B debugging extension. Its sidebar exposes the page’s tools and provides a chat window, approximating an experience that might appear in Gemini or another browser agent. A request to read the page returns the transcript. A subsequent request, entered with microphone input during the recording, asks for the next page. The model calls the exposed function, and the browser advances. The resulting screen shows page 2 of Four Simple Rules for Dating My Human Female.

Nabors recommends their interview with Alex Nahas, MCP-B’s creator and a contributor to WebMCP. That account traces the project’s origins to authentication problems at Amazon, including the difficulty of working with existing browser sessions. The developing standard offers a route to tools inside the page’s browser context, but browser support was still incomplete. Nabors points to the standards community and the interview’s accompanying resources as places to follow the work.

Nabors began exploring the agentic web roughly two years earlier with a provocative prediction that the browser would die. The point now is that the web is evolving: CSS and JavaScript are also the languages of interactive experiences inside agents. The closing demonstration makes that continuity audible. A reader speaks panel descriptions and dialogue, describing Brenda’s skeptical expression, Rachel’s explanation, and vegetation growing vigorously in the next panel.

The narration uses the browser’s Web Speech API. Its core operations are small enough to add directly to a reader:

function readTranscript(text) {
  window.speechSynthesis.cancel();
  const utterance = new SpeechSynthesisUtterance(text);
  window.speechSynthesis.speak(utterance);
}

function stopReading() {
  window.speechSynthesis.cancel();
}

Pass the reader’s transcript to readTranscript; connect a stop control to stopReading. Nabors describes the demonstration as a zero-dependency solution, dislikes the voice quality, and suggests ElevenLabs as a possible alternative. No separate speech SDK is needed for this browser API. The stronger spoken claim that no inference is required does not follow from API use alone: speech voices can use local or remote services.

Speech is only one of the browser capabilities available to these interfaces. Animation, audio, canvas, Wasm and CSS already provide ways to make content interactive. The comic archive connects those capabilities to agent access without giving up the visual and navigational qualities that made it worth visiting in the first place. The next experience can start with those same primitives.