When the Agent Leaves Its Core: MCP, Browsers, and Web Work
OpenManus's control model changes when a capability no longer lives entirely inside the agent process. This chapter follows that change through MCP, the project's Browser Use bridge, search, crawling, and browser state. The practical question is which web capability to use for discovery, extraction, or interaction—and what new assumptions about sessions, instructions, provenance, images, and cleanup enter the loop when the agent reaches beyond its core.
MCP turns an external service into a callable boundary
The Model Context Protocol, or MCP, gives OpenManus a way to make tools supplied by another process or service available through the same model-facing contract as local tools. The important operation is translation. The LLM does not need a separate reasoning language for a remote tool. The MCP client discovers the server's tools, wraps them as client-side proxies, and exposes names, descriptions, and parameter schemas to the ordinary tool-calling agent.
That convenience begins at startup. Manus is the composition root for the general-purpose agent: it starts with local Python, file-editing, human-interaction, and termination tools, then initializes configured MCP servers. In the current repository, it also has a default path for Browser Use CLI 3.0. Unless that server is already configured or explicitly disabled, the code starts uvx browser-use --cli-mcp over standard input and output. The README describes the same Browser Use integration and documents environment variables for local, cloud, or existing browser connections.
The startup choice has architectural consequences. Browser Use is not a library call hidden inside a browser tool; it is an external process with its own command, transport, environment, and persistent browser-harness session. OpenManus passes selected environment variables through, keeps Browser Use tool names unprefixed, and adds transport instructions explaining how browser skill code should be sent to browser_exec and when to use browser_screenshot. For other configured stdio servers, names are prefixed to reduce collisions. The model-facing tool set is therefore assembled at runtime and depends on deployment configuration.
The client side maintains this boundary explicitly. It can connect through stdio or server-sent events, initialize a session, list tools, and retain the original server-side name behind a sanitized local name. When the model calls the proxy, the client sends the arguments to the remote session and combines returned text into a standard tool result. If the server returns image content, the client preserves the first image as base64. To the agent, the result has the same broad shape as a local tool response; to the operator, it has crossed a process or network boundary and may have different latency, credentials, and failure behavior.