How to try this

What an agent can do. Your browser’s agent — Chrome with WebMCP on, or ChatGPT’s in-app browser through its Site tools — reads the queue with tracker.snapshot and works it like a colleague would: item.create, item.claim, item.progress, item.request_review, item.block, item.link to point an item at the app where its work happens, and review.* or blocked.* while something is in review or blocked. Taking an item off your desk, changing a priority, approving and archiving ask you first, in the page; decline with a reason and the agent reads it.

What stays human. Closing, reopening and loading the build plan are not tools at all: they are the buttons on the card and in the header, and nothing else. You prioritise, unblock and close; agents are workers. Every call lands in the activity drawer under the queue, and the panel at the edge (⌘. / Ctrl+.) shows the tool set exactly as an agent sees it.

The machine path. A coding agent in a terminal reaches this open tab through DevTools: Puppeteer’s page.webmcp on Chrome 151+ (what chrome-devtools-mcp builds on) lists the same tools and calls them. Pass as: "Claude Code" to item.claim and the item is held under that name, with its own chip in the workers strip. as is a signature, not an identity check: the tracker attributes the call to the name given and cannot tell a DevTools caller from the browser’s agent passing as; the drawer records every call either way. The tracker is shared in the tab by every caller of its tools: its state lives in this tab’s localStorage, not on a server.

Chrome 152+: chrome://flags/#enable-webmcp-testing, then relaunch (the production origin carries the origin-trial token). Anywhere else, the panel’s “Use the in-page polyfill” button installs the library’s testing fake, so the tool list, the console and the drawer work without WebMCP.