benchrThe playbook
A site with no API to a daily feed you own
Drive the browser once to learn the path, freeze it into a connector, and check one record against the page yourself before it runs unattended.
6 stages Set up once, checked by hand, then unattended Claude API · MCP servers · Claude Code Complete
Every stage names what goes in, what to do, why it sits here and what comes out, and the chain says where it breaks.
benchr has not run these capabilities itself. Each stage points at a record describing what a provider documents, read on the date shown.
- You start with
- The page URL, the values you want each day, and an isolated container or VM behind a network-level domain allowlist
- Why this stage
- This is the only stage where nobody knows the path yet. That is what the model is here for, not for reading the same page every morning.
- Do this
- Have the agent find the data by reading the accessibility tree, and record the exact click path and element references it used.
- You end with
- The click path, recorded as element references
What goes wrong here
- You start with
- The recorded click path, and the page still open
- Why this stage
- Element references go stale as soon as the tab navigates, and a recorded path is a sequence of navigations. A name survives a layout change; a position does not.
- Do this
- Rewrite each step as the target's accessible name and role, then replay the list in a fresh tab to confirm every name still reaches its target.
- You end with
- A path written in accessible names, replayed once from a fresh tab
- You start with
- The frozen path and the values it reaches on the page
- Why this stage
- The alert at the end of the chain has nothing to measure a record against but this. Written after the connector works, it describes the page instead of specifying the feed.
- Do this
- Define the record shape the feed will publish, before automating anything.
- You end with
- The feed's schema
What goes wrong here
- You start with
- The frozen path, the schema, and the credentials the site needs
- Why this stage
- The docs are organized by dated spec revision and the spec revises, so pin the one you build against here. Nothing later in the chain rebuilds the server.
- Do this
- Wrap the frozen path as a read-only server, so a client that speaks the protocol can call it without driving a browser.
- You end with
- A connector with credentials on the server side
- 05
Compare
Your work- You start with
- The connector's first record, and the page it was read from
- Why this stage
- A record read off the neighbouring row satisfies the schema and clears the alert, so nothing upstream catches it. It sits after the wrapping, so what you check is what the feed will publish.
- Do this
- Open the page yourself and read the connector's record against it, field by field, on a row that is not the top one.
- You end with
- One record you have confirmed against the page by eye
- You start with
- The connector, the schema, the record you checked by hand, and — for a cloud or mobile handoff — a claude.ai subscription, with some handoffs limited to macOS and x64 Windows
- Why this stage
- A schedule has no reader, so finished has to be something a machine can decide. Where a model fills the record, a refusal, a safety rejection or hitting max tokens can still produce no usable object, and none of the three is a schema violation.
- Do this
- Schedule the run and alert on schema violations rather than on content changes.
- You end with
- A daily feed and a failure alert
What goes wrong here