Guide · Browser · HTTP API · MCP
Should a repeated task use the browser, an HTTP API or an MCP tool?
Short answer
Use the supported interface whose business contract and permissions you can verify. Browser steps fit tasks exposed through a UI; HTTP steps fit documented endpoints; MCP steps reuse tools with known inputs and outputs. Ritoko can combine these paths under one workflow and journal.
Updated
↔ Scroll to read all columns.
| Path | Useful when | Check before saving |
|---|---|---|
| Browser | The task is available in your authorized account UI | Unique controls, login state, commit and visible business evidence |
| HTTP API | A supported endpoint exposes the required operation | Authentication, request schema, result checks and any idempotency contract |
| MCP tool | A connected tool implements the operation you need | Input/output schema, side effects, compatibility and tool-provider charges |
When is the browser the practical choice?
Use the UI when it is the supported way to perform the task or when it supplies a necessary approval or business check. The direct runner connects to personal Chrome with remote-debugging permission, or an explicitly selected clean profile. Complete login and MFA in the selected browser.
Host browser replay requires a client that permits page-script execution. Current Codex computer-use evaluation is read-only and cannot execute that replay. API-only and connected MCP-tool host batches remain possible. Confirm the driver’s limits before recording a task that depends on iframes, keyboard presses or downloads.
Can I turn a browser recording into API calls?
Optional network capture supplies fetch/XHR metadata that can help investigate an API. Those hints are not an API contract and do not automatically create executable HTTP steps. Verify the supported endpoint, authentication, required fields and returned business result, then test one authorized row and save the replacement explicitly.
An HTTP step can check response status and JSON values, save returned IDs and feed later read-only checks. Environment-backed secret parameters keep credentials out of saved workflows. A stable Idempotency-Key is available when the receiving API documents support. Only eligible GET/HEAD requests before commit are automatically retried; a write with an uncertain outcome remains review.
What do I need to know about a connected MCP tool?
Check the tool’s schema and actual side effects. A declared read-only step is an author assertion, not a guarantee supplied by the protocol. Tool errors, timeouts and requests for more input fail the step; Ritoko does not automatically retry MCP calls. A timed-out write may still finish remotely.
A direct workflow can start or contact configured servers. Host {ref: "agent"} references reuse an existing agent connection. Direct-client protocol compatibility has limits; a modern-only server may be unsupported. An external MCP tool may itself invoke a model or a paid service even though Ritoko’s direct replay engine contains no LLM call.
How do I combine interfaces without duplicating a write?
For example, create a record through a documented API, save its ID, then retrieve its receipt with a read-only tool. Keep one irreversible commit per item and verify the intended effect after it. A workflow without browser steps does not need Chrome.
Do not switch to a browser submission automatically after an API write times out: that can submit the same record twice. Check the first outcome before changing paths. Split tasks with several independent writes into separate verifiable procedures. See the HTTP/MCP step reference for exact shapes, authentication and driver limits.