Prefer an API or purpose-built connector when it exposes the required operation with clear identity, scoped access, and a result you can verify. Use browser automation when the task depends on the rendered interface, the workflow exists only there, or the available API does not cover the needed behavior. Evaluate the specific operation before choosing an interface for the whole application.
An agent updating a draft title and an agent checking whether that title wraps badly on a phone may need different tools. The first task concerns stored state. The second concerns what a reader actually sees.
Compare the contract available through each route
An API often gives an object identifier, structured fields, and explicit errors. Those features help only if the integration exposes and uses them correctly. A broad token and an undocumented endpoint can provide a worse boundary than a tightly constrained browser session.
A browser supplies the application's user-facing workflow, including visual feedback and steps absent from a public API. It also introduces page state: account selection, open dialogs, stale forms, loading indicators, and elements that move or disappear.
Anthropic's browser-use documentation describes operating through page structure as well as screenshots and coordinates. Its tool-combinations guide recommends narrower tools when they cover the task. Those are product-specific capabilities and guidance; they are not evidence that a browser or API wins every workload.
| Decision | API or connector route | Browser route |
|---|---|---|
| Identify the target | Stable ID, account, tenant, revision | Confirm account, page identity, and selected object |
| Read state | Request selected fields and pagination | Read current page state; inspect rendered content when relevant |
| Change state | Send a documented operation with explicit payload | Fill the actual form and inspect its current controls |
| Detect conflicts | Use supported version preconditions | Recognize conflict dialogs or stale form state; do not assume protection exists |
| Confirm the effect | Read the object after the operation | Reopen or refresh and inspect the saved value |
| Maintain the integration | Track API versions, schemas, and scopes | Track labels, navigation, layouts, and session behavior |
Neither route turns a proposed action into an authorized one. The account's technical permission and the user's intended scope remain separate.
Follow one edit through the API
Consider a fictional knowledge-base service. The user has authorized changing the title of draft doc-17 from “Export notes” to “Export retention,” leaving its body and publication state unchanged.
The API path starts by reading doc-17 in the expected workspace and verifying that it is still a draft. The executor prepares a narrow title update. If the service supports a revision precondition, the update includes the observed revision so another editor's intervening change can be detected.
HTTP's If-Match semantics in RFC 9110 define a standard conditional mechanism for services that implement it. An ETag in a response does not by itself establish that every write endpoint supports the intended concurrency contract. Check the endpoint documentation and exercise the conflict path in an authorized test environment.
After updating, read the draft again and confirm its identity, title, body preservation, and draft state. A successful transport response or queued operation is not necessarily the final saved state. If the connection fails before acknowledgment, reconcile before submitting another create or update operation.
This is a conceptual path. No knowledge-base account, API call, or title edit was executed for this article.
Follow the same edit through the browser
The browser path first establishes the account and workspace. It opens the draft and confirms a visible identifier or other sufficiently specific identity. A matching title alone may be ambiguous when several drafts share it.
Read the current form before choosing a control. If the title input is accessible through the page's semantic structure, use that observed reference. If the relevant distinction is visual, inspect the rendered view. Avoid carrying an old element reference through navigation or assuming a coordinate still targets the same button after a dialog opens.
Change the title, inspect the proposed value, and use the draft-save action. A neighboring “Publish” button has a different effect even if both controls look similar. Then reopen the object or reload the page and confirm the saved title and draft state. A transient toast can be supporting evidence; it is weaker than reading the saved object itself.
If a login challenge or approval step requires a person, preserve the prepared work and hand off that boundary clearly. Repeated blind clicks are not a recovery strategy for uncertain page state.
Use a mixed workflow when the evidence needs it
An API can save an article while a browser checks its rendered layout. A connector can find a record while a browser supplies a setting that the connector does not expose. Record which path performed the effect and which path verified it.
Avoid simultaneous edits through both routes. The browser may hold stale form values and overwrite an API change when saved. Refresh the state at the handoff and recheck the intended payload. For batch work, ensure the confirmation mechanism scales with the batch; opening one of a hundred updated records does not verify the other ninety-nine.
MCP can expose a server's operations to an agent, but it does not decide whether those operations come from an API or browser underneath. MCP's place between a server and an AI application is a separate architectural question from the interface selected here.
Make the pilot about accepted effects
Compare the two routes on representative authorized tasks. Record correct target selection, accepted changes, unexpected effects, retries, recoverability, human intervention, and maintenance failures. Include read-only tasks and writes with conflicts or lost acknowledgment. Keep a rendered-layout task in the set if visual correctness is part of the requirement.
Do not assume that fewer clicks means lower total cost or that a structured response proves correctness. Count setup and verification as part of the work. The useful choice is the route whose available contract makes the required effect easiest to constrain and confirm.
Documentation reviewed October 28, 2026. Both edit paths are conceptual; no browser/API performance comparison, authentication test, or remote mutation was performed.
