Reclaim provider-authoring tools, running against the OLD DEVTOOLS backend —
intentionally reduced: no generated API tools, no organizations, no public
review flow. Only GET/POST requests can be captured into providers.

**A `provider` is a recipe for extracting a data point from a site. A
`verification` is an end-user session that proves a data point using one. Never
call a provider a "verification."**

**Provider versions are immutable.** Every recipe or configuration change
creates a new semantic version. Default to a patch bump; use a major/minor bump
or exact higher version when the user directs it. Never edit an existing
version.

**Use the guide as needed.** Call `how_it_works({})` for its topic index, then
fetch only the topic relevant to the next tool call.

**Ask who is doing the signing in, then offer a browser.** "Yourself, or does
someone else need to log in?" decides half of `attach_browser`'s list. Doing it
themselves → `dedicated` or `attach`, both local, neither shareable. Someone
else, or a phone-only site → `container` (the Reclaim runtime in Docker, free,
shareable with `share_browser_view`) or `builder` (hosted, no install,
**chargeable**). Say which costs money, and say `container` exists at all:
nobody guesses it.

**The flow:** `reclaim_authenticate` once → `attach_browser` (ask the developer
which browser source — local Chrome, the Reclaim runtime in Docker, a remote
Builder browser, or a CDP URL they supply) → `start_capture` ⇒ **`captureId`** →
drive the page (`navigate`,
`wait_for_page`, `eval_in_page`) → inspect (`list_requests`, `get_request`,
`find_requests_containing`) → `propose_provider` ⇒ **`draftId`** →
`replay_request(captureId, draftId)` → `run_proof(captureId, draftId,
ownerAddress)` → `create_provider_version_from_capture`.

`reclaim_authenticate` itself always uses a local Chrome over loopback CDP. It
never uses the container, remote Builder, custom-CDP, or shared authoring
browser; those choices begin only at `attach_browser` after dashboard sign-in.

**Publishing and ownership:** with NO `providerId`, publish REGISTERS A NEW
provider — re-running creates a duplicate. Pass a `providerId` from
`get_me_providers` (the only provider-listing tool here) to add a version to an
existing provider instead; you can only version a provider you own. For a
multi-request provider pass `providers: [draftA, draftB, …]` so each becomes a
parallel `requestData` entry on the one version.

**Two independent auth systems — don't confuse them.** `reclaim_authenticate`
authorizes everything in this mode; its Firebase token is short-lived (~1h), so
an auth error on publish or `get_me_providers` means re-run it.
`authenticate_builder` covers only two Builder-exclusive features: allocating a
remote browser (`attach_browser mode="builder"`) and
`list_builder_organizations`. It authorizes nothing else. `get_devtools_mode`
reports both.

**Never prove a public endpoint.** After `replay_request` succeeds, re-run it
with `withoutSecrets: true`. If the value still extracts, the endpoint is public
and the proof binds to nobody — find an auth-bound request instead.

**Templating:** bare `{{name}}` placeholders are extracted from the response.
Values the CONSUMER supplies at verification time use `{{context_<name>}}` —
this backend does NOT support the builder's dotted `{{context.<name>}}` form.

**Diagnosing a session:** `session_analytics_logs` returns a session's
milestone events; `session_logs` returns the log entries the SDK emitted, each
with its event type — that is where a failed match, redaction, or claim shows
up. Both take a `sessionId`; see topic `troubleshooting` for how to read them.

**Backend mode:** the BUILDER backend (generated API tools, orgs, verification
sessions, public review) is one switch away. `get_devtools_mode` reports the
active mode and why; `set_devtools_mode` persists a switch to
`~/.reclaim/config.json`, effective on the NEXT server start. An explicit
`USE_OLD_DEVTOOLS` env var wins over the persisted choice.