This analysis compares Browser Use with MCP: Choosing the Right Level of Control, focusing on the decision each option supports, the evidence behind it and the trade-offs.
Read the evidence below as a decision trail: what changed, why it matters, which trade-offs shaped the result, and where the conclusion still depends on context.
Browser-Use (CUA) and MCP are the two hottest topics in the AI agent circle in 2025-2026 - but the discussions in the official courses are all in the same direction: neither is an "all or nothing" choice. CUA is suitable for dynamic UI and fixed structure, but Playwright is still needed; MCP solves tool connection, A2A between agents, and NLWeb at the web layer. This article breaks down the selection comparison and mixing strategies of Lesson 11 + 15.
Why should these two lessons be read together?
The three protocols of MCP/A2A/NLWeb in Lesson 11 and Browser-Use (CUA) in Lesson 15 appear to be different layers - the former is the communication agreement between the agent and the system/agent/website, and the latter is the agent's direct control of the browser. But two lessonsShare the same design judgment: Layer agent capabilities, choose the right layer, mix them, and don’t over-commit to a single solution.
In practice, this means: MCP is not a "universal API replacement" and CUA is not a "fully automated browser."Each tool has its best and worst scenarios, the selection issue is more important than the implementation issue. Remove the following 4 tools one by one.
MCP — 3 primitives and the “integrate once” fantasy
Model Context Protocol is a client-server architecture:
- Hosts: LLM application (VSCode and the like), initiate connection
- Clients: Components in the host maintain a 1-to-1 connection with the server
- Servers: Lightweight programs that expose capabilities (such as "weather server" and "e-commerce server")
MCP server 3 primitives:Tools(callable action, such as get_weather),Resources(read-only data, such as files, DB records),Prompts(predefined template). The clear layering of these three primitives is the highlight of MCP design - many people talk about MCP and only talk about Tool, leaving out Resource and Prompt. Resource is "read context for LLM", Tool is "execute action for LLM", and the security model is completely different.
3 benefits of MCP highlighted by Microsoft:
- Dynamic Tool Discovery: The agent dynamically asks the server "What tool do you have?" without hard-coding in advance.
- Interoperability Across LLMs: MCP is universal across LLMs and can be changed for model evaluation at will.
- Standardized Security: Standardized verification, no need for each API to have its own set.
The fantasy of "Integrate once": The first benefit is promoted as "write once, no need to change the code if the API changes". In fact: API changes still need to be changed, butPush from application side to MCP server side. The MCP server has to do versioning, backward compatibility, and breaking change management on its own. The pain points have not disappeared, they have just been pushed down to different teams. For the application side, it means "integrate once", and for the server maintainer, it means "continuous work".
This trade-off is important in organizational decisions—If your company is an MCP server provider, you need to calculate the long-term maintenance costs; if you are an MCP server consumer, you need to confirm that the server you are connected to is actually being maintained.. An unmaintained MCP server is as dangerous as an outdated API SDK.
A2A — 4 components and long wiring costs
Agent-to-Agent and MCP complement each other - MCP connects agent and tool, A2A connects agent and agent (cross-organization, cross-platform). 4 components:
- Agent Card: The agent’s “business card”—name, what it can do, what skills it has, endpoint URL, version, and capabilities. Other agents look at the card and decide whether to call.
- Agent Executor: Pass the user chat context to the remote agent and let the remote execute it with its own LLM + tool.
- Artifact: The result output after the remote agent is completed + description + text context. Disconnect after delivery.
- Event Queue: Handle updates, messages, and production. Important—prevent the connection from being disconnected before the task is completed.
A2A 3 benefits: cross-vendor/platform collaboration, each agent can choose its own LLM (unlike some MCP scenarios that tie a single LLM), and built-in verification.
The hidden costs of long connections: The purpose of Event Queue design is to "prevent the connection from being disconnected before the task is completed", implying that A2A tasks often run for a long time. Production The cost of maintaining long connections is not cheap - connection pool, heartbeat, reconnect logic, cross-organization firewall penetration. In practice, A2A is suitable for high-value/low-frequency tasks (cross-company bookings, cross-department approvals), but not suitable for high-frequency/low-value tasks (100 queries per second).
NLWeb — Turn websites into agent-consumable layers
NLWeb is the least mentioned among the three protocols, but the one with the most imaginative concept:Make the website itself into an interface that the agent can query using natural language. Contains:
- NLWeb Application: The core engine for processing natural language queries
- NLWeb Protocol:Basic interaction rules, return JSON (Schema.org format)
- MCP Server Endpoint：Each NLWeb is also an MCP server — This design is very important, allowing the website to automatically enter the agent ecosystem
- Embedding Models:Vectorize website content
- Vector Database: Save embedding, support Qdrant / Snowflake / Milvus / Azure AI Search / Elasticsearch
Actual operation: The travel website uses Schema.org to structure the products (flights, hotels, itineraries) → NLWeb ingest becomes embedding → the user uses chat to "find a Honolulu hotel that can take children and has a swimming pool" → NLWeb uses LLM understanding + vector search → returns real hotel information (no hallucinations) → External AI agents can also directly query this website through the MCP `ask` method.
NLWeb embedding pitfalls: Limitations of pure vector search - abstract preferences such as "cheap" and "family-friendly" can be matched, but precise conditions such as "room over 25 square meters" are easily missed. In practice, vector search (capturing semantics) + structured filter (capturing precise conditions) must be mixed, and embedding cannot be relied upon alone. It's no coincidence that Microsoft mentioned that it supports multiple vector databases - when choosing a DB, you should look at "whether it can be mixed with structured filters."
Browser-Use (CUA) — Agent + Actor mixed mode
The main focus of Lesson 15: Computer Use Agent is to use vision to see the screen and operate the browser like a human; Playwright is a traditional actor and is precisely controlled using CSS selector. Microsoft lesson directly gives the selection table:
| scene | Use Agent (CUA) | Using Actors (Playwright) |
|---|---|---|
| dynamic layout | ✅ AI adapts to changes | ❌ brittle selector is easy to break |
| known structure | ❌ agent is slower than direct control | ✅ Fast and accurate |
| Find element | ✅ Natural language is easy to use | ❌ Need precise selector |
| Timing control | ❌ Less predictable | ✅ Full control over wait/retry |
| complex workflow | ✅ Handling unexpected UI | ❌ Need to specify the branch |
Looking at the 5 dimensions,No "all-agent" or "all-actor" will win — The optimal choice is different for each dimension. So what Microsoft teaches is a hybrid architecture:
- Turn on CDP (Chrome DevTools Protocol) when Chrome starts and let Playwright and Browser-Use share the same browser session
- Browser-Use agent handles open navigation (open Airbnb, dismiss pop-up, search Stockholm)
- The current page is structured and extracted using Pydantic schema (listing title, nightly price, rating, URL)
- Python logic compares the extracted listings and finds the cheapest one
The core judgment of this architecture:Use agent vision in the "exploration period", and use actors to directly control and share browser sessions in the "execution period" to avoid state reconstruction.. The seven best practices given by Microsoft all revolve around this framing - start with agent for exploration, switch to direct page control when predictable, blend agent and actor patterns to get both flexibility and precision.
Comparison of 5 tools for selection
Compare these 4 tools (MCP / A2A / NLWeb / Browser-Use) with "direct call API" for selection comparison:
| scene | Best tool | why |
|---|---|---|
| Has a stable API and known endpoints | Direct API call (function calling) | The simplest, fastest and cheapest |
| There are multiple internal services and want to connect them in a unified way + dynamic discovery | MCP | 3 primitives are clearly distinguished and portable across LLMs |
| Cross-company/cross-department collaboration, different agents and different LLMs | A2A | Cross-organizational collaboration + each chooses a model |
| The website needs to be queried by the AI agent and wants to expose the content. | NLWeb (including MCP endpoint) | Schema.org + vector search + automatically enter the agent ecosystem |
| The target website has no API or UI dynamics | Browser-Use (agent + actor hybrid) | vision adapts to changes + actor precise control |
Judgment process:First ask "Is there an API?" → Don't ask again "Can I install NLWeb / MCP server" → Use Browser-Use only if it doesn't work.. Reversing the order is equivalent to hitting mosquitoes with a cannon (many teams see "Browser-Use is cool" and just jump on it, ignoring that the backend actually has an API).
My Observation — Why Mix Always Wins All-or-Nothing
The design of all 4 tools points to the same principle:"Fully automatic" is a myth, "precise layering" is the answer to production-grade. Reason:
- Every tool has cost-quality trade-offs. Agent is flexible but slow, actor is fast but brittle; MCP is unified but the server needs to be maintained; A2A crosses organizations but long connections are expensive; NLWeb automatically exposes but embedding has limitations; Browser-Use vision adapts to changes but tokens burn quickly. No single tool wins in all dimensions.
- Complementary failure modes. Actor is bad in dynamic UI, agent is weak in dynamic UI; agent is slow in tasks with fixed structure, and actor is fast in tasks with fixed structure. Mixed use, the failure modes of the two absorb each other, and the overall reliability is higher than a single solution.
- Different organizational decision-making levels. MCP is the tool layer connection, A2A is the agent orchestration, NLWeb is the website layer exposure, and Browser-Use is the execution layer. Different teams within the organization are responsible for different layers, and technical decisions should not be tied together. Hybrid means that each layer can independently select the most suitable tool and is not locked into a single framework.
This principle is consistent with my observations on multi-AI tool collaboration:It’s a good thing to let different tools do what they do best, let people make strategic decisions in the middle, and not assume “seamlessness”. When Microsoft clearly stated "blend agent and actor patterns" in the Browser-Use course, the essence is the same principle - layering + mixing + explicit strategic decision-making.
Practical questions and boundaries
What is the difference between MCP and traditional API? Why do I need an MCP?
The traditional API is "I hard-code the endpoint + authentication + schema. If the API changes, I change the code."; MCP is "I connect to the MCP server, and it tells me what tools and schema there are. If it changes, it tells me." The difference isWho is responsible for synchronizing schema changes? — Traditional API is client and MCP is server. It is over-engineering for a single stable API and MCP; it significantly saves maintenance costs for multiple internal services and MCPs that may change. Judgment criteria: How many times a year does your company’s backend API change? After more than 2 changes, MCP becomes more cost-effective.
What is the relationship between Browser-Use and Selenium/Playwright?
Browser-Use does not replace Playwright, it isThe vision agent layer on top of Playwright. The underlying Chrome control is still Playwright + CDP; the upper layer "look at the screen and decide the next step" is added by Browser-Use (using Azure OpenAI vision or other multi-modal LLM). Microsoft's hybrid architecture uses both, sharing the same Chrome session - not one or the other.
What is the difference between NLWeb and ordinary RAG websites?
Generally, RAG is "website articles are embed, and user queries are obtained in chunks and answered" - the core is content retrieval. NLWeb goes furtherThe website itself (including structured product catalog, tour list, etc.) is made into an interface that can be queried by natural language, and automatically is the MCP server. Difference: RAG servesUsers with chat UI; NLWeb servesUser + external AI agent. From the website owner’s perspective: RAG is a site search upgrade, and NLWeb is “allowing my website to enter the agent ecosystem.”
Original source: Microsoft AI Agents for Beginners — Lesson 11 Agentic Protocols（MCP / A2A / NLWeb）、Lesson 15 Browser-Use (CUA)
What to take away
The article's value is in the evidence and trade-offs behind browser Use vs. MCP: Choosing the Right Level of Control, not in treating the conclusion as universal.