APIs, MCP, or Browser Agents?

Should an AI agent use an API, MCP server, or browser? Use a stable API first for repeatable system reads and writes. Use MCP when a useful capability should be discoverable and reusable across compatible AI hosts, usually while the MCP server calls a governed API underneath. Use browser interaction only when the required work has no dependable machine interface. A browser agent is a fallback, not an upgrade: it carries more state, more failure modes and more maintenance.

Start with the interface, not the AI label

The integration method determines how a workflow identifies an operation, passes data, proves authority, detects failure and recovers. The model may decide which bounded capability to request, but it should not blur the difference between an API transaction, an MCP tool call and a sequence of screen actions.

1. APIs: the default for dependable transactions

An API exposes operations directly to software. A well-designed business API can name the operation, validate a typed request, enforce scopes, return a structured result and distinguish errors with explicit status and response fields. The OpenAPI Specification provides a machine-readable way to describe HTTP APIs, including paths, operations, parameters, security requirements and schemas.

This makes APIs the natural first choice for jobs such as retrieving an assigned customer, creating a draft order, checking inventory or posting an approved status change. They are not automatically safe: an overly broad API key, undocumented side effect or ambiguous retry can still create damage. The advantage is that the control points can be explicit and tested without interpreting a screen.

Use the provider's supported API when it covers the needed operation. Wrap it with a narrow internal service when the raw surface is too broad, when several systems must be coordinated, or when business policy needs to be enforced before the call.

2. MCP: a standardized AI-facing capability layer

Model Context Protocol standardizes how an AI host and an integration server exchange requests. MCP servers can expose tools, resources and prompts; hosts and servers negotiate capabilities, and current HTTP authorization guidance uses resource-bound authorization rather than treating any bearer token as valid everywhere.

MCP does not replace the business API. A common production design is AI host → MCP server → internal policy service or vendor API. The server gives AI clients consistent discovery and schemas while the downstream system remains the source of record. This is valuable when several supported AI clients need the same governed capability, or when a team wants to separate AI orchestration from system-specific adapters.

Do not add MCP merely to rename one API call. It creates an additional component to secure, version, observe and operate. The benefit should come from reuse, portability, clearer tool boundaries or host interoperability. The business MCP explainer covers server responsibilities and authorization in more depth.

3. Browser agents: useful when the screen is the only interface

Browser automation acts through the rendered web application: find a control, read a page, enter data, click and verify the resulting state. Modern frameworks improve reliability. Playwright, for example, resolves locators against the current page and waits for actionability conditions such as visibility, stability and enabled state before performing an action.

Those checks do not turn a UI into a stable transaction contract. Labels move, layouts change, sessions expire, pop-ups appear, loading states race and success may be visible only as text. A browser flow therefore needs explicit checkpoints: confirm the account and record, validate every value before submission, capture the before state, detect the exact success state and stop on ambiguity.

Reserve UI automation for systems without a supported API, a required workflow step that exists only in the UI, or a short-lived bridge while a better interface is built. Prefer accessible roles and labels over brittle coordinates or DOM paths, and require human confirmation for consequential actions.

Six-factor selection matrix

The matrix compares interfaces, not vendors. An undocumented API can be worse than a carefully maintained browser workflow. An MCP server backed by a fragile screen scraper inherits that fragility even if its tool schema looks clean. Always inspect the full path to the system of record.

Permissions must survive every layer

Separate what the model may propose from what the authenticated user may do and what the integration credential can execute. For an API, apply scopes plus tenant, record and field rules. For MCP, validate the user at the host and server, bind tokens to the intended resource, and use separate downstream credentials. For browser automation, constrain the user account, allowed origin, permitted records and available actions.

A tool description is not authorization. Neither is a button being visible. High-impact changes should use proposal, review and commit stages. The AI agent permission design guide provides a five-level authority matrix for matching controls to consequence.

Reliability is about known outcomes

Design for four terminal states: succeeded, rejected, failed before execution and unknown after a timeout. The last state is the dangerous one. If a create request times out after reaching the system, a blind retry may create a duplicate. Use an idempotency key or external reference, then reconcile the system of record before retrying.

For browser flows, verify the result on a fresh page or through a read-only API when available. Do not treat a click, a closed dialog or a navigation as proof of completion. Preserve the proposed inputs, authorization result, action attempt and observed outcome in an audit record without logging secrets.

Hybrid designs are normal

MCP over APIs

Expose narrow AI-facing tools through MCP while calling stable vendor or internal APIs beneath them. This provides client portability without giving the model an unrestricted API catalogue.

API for truth, browser for the last mile

Read identifiers and current state from an API, then use the browser only for the single UI-only step. Re-read the final state through the API. Keep the browser credential less privileged than a human administrator account.

Browser now, API later

Use UI automation as a temporary adapter with monitoring and an explicit replacement trigger. When volume, breakage cost or consequence crosses the agreed threshold, build or procure a supported interface instead of endlessly repairing selectors.

The integration-method decision chart

1. 1. Does the system already provide a supported API for the exact read or action?
2. 2. Will the same capability be useful from more than one compatible AI host?
3. 3. Can permissions be enforced for the user, tenant, record, field and operation?
4. 4. Can the integration detect the difference between success, rejection, timeout and unknown outcome?
5. 5. Can a retry be made idempotent so it cannot create a duplicate external action?
6. 6. Who owns breakages when the source system, protocol or screen changes?

If the first answer is yes, start with the API. If the capability must travel across AI hosts, consider an MCP layer around the governed implementation. If there is no machine interface, use controlled browser automation and record the debt. If the owner, permission boundary or success signal is unclear, stop before selecting any method.

Primary sources checked

Checked 15 September 2026. The three-interface map, selection matrix and decision chart are Shuhaib's practitioner synthesis.

• Model Context Protocol — 2026-07-28 protocol overview
• Model Context Protocol — authorization specification
• OpenAPI Initiative — current OpenAPI Specification versions
• Playwright — actionability and auto-waiting
• Playwright — resilient locators