TL;DR An MCP server is a program that exposes tools, data, and actions to an AI model through the Model Context Protocol, a single open standard that any MCP-aware client can call. You write the integration once, and every model that speaks MCP can use it, so you stop building a new adapter for each app. A browser MCP server is one kind, and it hands a model a real browser it can drive.

Every model that wants to touch the outside world runs into the same wall. On its own it can only produce text. To read a database, call an API, or open a web page, it needs code that connects the model to that system, and until recently you wrote that glue by hand for every model and every tool you cared about. The Model Context Protocol collapses that work into one interface both sides agree on.

What is an MCP server?

An MCP server is the provider side of the Model Context Protocol. It advertises a set of capabilities to a client, and the client connects a model to them. Anthropic introduced MCP in November 2024 as an open standard, and the ecosystem has since grown to thousands of public servers.

MCP defines three kinds of capability a server can expose.

• Tools. Functions the model can call, like search_web or run_query. The model decides when to invoke them and with what arguments.
• Resources. Read-only data the client can load into context, such as a file, a document, or the current state of a page.
• Prompts. Reusable templates a server offers so a client can trigger a known workflow in one step.

The point of standardizing this is reuse. Before MCP, connecting a model to Notion, a database, and a browser meant three bespoke integrations, each tied to one model's function-calling format. An MCP server exposes those same capabilities once, and any client that speaks the protocol can consume them without new code.

How does an MCP server work?

A client and server exchange JSON-RPC messages over a transport. The client asks the server what it offers, the server returns its tools, resources, and prompts, and from then on the client can call any of them on the model's behalf and feed the results back into the conversation.

MCP supports two transports, and which one you pick depends on where the server runs.

• STDIO. The client launches the server as a local subprocess and talks to it over standard input and output. Best for servers that run on the same machine as the client.
• Streamable HTTP. The server runs as a remote service the client reaches over HTTP. Best for hosted servers you connect many clients to.

Most MCP clients read their servers from a config file. The block below registers a hosted server over Streamable HTTP, so the client connects to a URL instead of spawning a local process.

{
  "mcpServers": {
    "browserbase": {
      "url": "https://mcp.browserbase.com/mcp?browserbaseApiKey=YOUR_BROWSERBASE_API_KEY"
    }
  }
}

To run a server locally instead, point the same config at a command the client executes, and pass credentials through the environment.

{
  "mcpServers": {
    "browserbase": {
      "command": "npx",
      "args": ["@browserbasehq/mcp"],
      "env": {
        "BROWSERBASE_API_KEY": "your_api_key",
        "GEMINI_API_KEY": "your_gemini_api_key"
      }
    }
  }
}

What is a browser MCP server?

A browser MCP server exposes a real web browser as MCP tools, so a model can navigate to a page, click, type, and pull structured data back. It is the difference between a model that can only describe a website and one that can actually operate it.

The Browserbase MCP server is a hosted example. It gives any MCP client a cloud browser through a small set of tools, navigate, act, observe, and extract, backed by Stagehand. Once it is registered, you drive the browser in plain language from the client.

claude mcp add --transport http browserbase "https://mcp.browserbase.com/mcp?browserbaseApiKey=YOUR_BROWSERBASE_API_KEY"

The browser runs on managed cloud infrastructure rather than the client's machine, which is what lets the same model open hundreds of sessions in parallel and reach sites that turn away a bare data-center request. See the Browserbase MCP server docs for the full tool list and setup.

When should you use an MCP server?

Reach for an MCP server when you want a model to do something outside its own context and you would rather not hand-write the integration for every model you use. Because the protocol is shared, one server works across every MCP-aware client.

• Give an assistant a browser. A browser MCP server lets a model log in, fill forms, and read pages that have no API.
• Connect internal systems. Expose a database, a ticketing system, or an internal API as tools your team's agents can call.
• Share one integration across clients. Write the server once and use it from any MCP client without porting the glue code.

If you only ever call one model and one tool, a direct function-calling integration is simpler and MCP adds a layer you do not need. The protocol earns its keep the moment you have more than one client, more than one tool, or a plan to reuse either.

MCP server vs a direct API integration

A direct integration wires one model to one service in that model's own function-calling format. An MCP server wires a capability to the protocol once, and every client reuses it. The dimensions a developer actually compares are below.

Last updated August 4, 2026. Next, see what a browser agent harness is and how to run your first browser agent on a managed cloud browser.