What is an MCP server? A browser as the example
What an MCP server is and how it works: 3 building blocks, 2 transports, the difference from an API, and a browser server with 68 tools as the example.
Davide Valli · Founder, Scalebrowser
Published Nov 15, 2026 · 6 min read
Short answer
Every agent framework now asks for an MCP server, and the name hides a small idea: a program that tells an AI application what it can do and then does it when the model asks. The protocol's own examples are calendars and flight searches. A browser is a harder example and a more useful one, because its tools act on a page that changes between two calls, and every tool it offers costs tokens on every request.
What is an MCP server?
An MCP server is a program that offers an AI application 3 kinds of building blocks over the Model Context Protocol (MCP): tools, resources and prompts. The application connects to the server, asks what it offers and hands that list to the model. The server does the work, and the model only decides which tool to call with which arguments.
| Building block | Who controls it | Protocol methods | Example from the MCP documentation |
|---|---|---|---|
| Tools | the model | tools/list, tools/call | search flights, send messages |
| Resources | the application | resources/list, resources/read | retrieve documents, read calendars |
| Prompts | the user | prompts/list, prompts/get | plan a vacation, draft an email |
Tools carry most of the weight in agent work. Each tool has a name, a description and an input schema written in JSON Schema, and each call returns content that the model reads as its next input. A server can offer only tools and still be a complete MCP server.
How does an MCP server work?
An MCP server works as one end of a dedicated connection that a host application opens for it. The MCP architecture overview names three participants: the host, an AI application such as Claude Code or Visual Studio Code; one MCP client per server, which the host creates; and the server, "a program that provides context to MCP clients". The messages follow JSON-RPC 2.0, "a stateless, light-weight remote procedure call (RPC) protocol": tools/list returns the tool definitions and tools/call runs one.
The same messages travel over 2 transports, and the transport decides where the server runs.
| Transport | How the server runs | Clients per server, typically |
|---|---|---|
| stdio | as a subprocess the host starts on the same machine | 1 |
| Streamable HTTP | as a service at an address, local or remote, over HTTP POST with optional Server-Sent Events | many |
The current revision of the specification, dated 28 July 2026, makes every request stand on its own: each one carries its protocol version and capabilities, and a client can ask any server what it supports with a single server/discover request. The MCP introduction calls the protocol "a USB-C port for AI applications" and names Claude, ChatGPT, Visual Studio Code and Cursor among the clients. The comparison holds in one sense: a server written once works in every host that speaks the protocol.
What does an MCP server for a browser do?
An MCP server for a browser gives the model tools that open a page, read what is on it and act on it, and it runs the real browser behind those tools. The model never touches the browser itself. Scalebrowser's server works in one loop of four steps:
lease_profilereserves a browser profile, starts it and returns a handle that every later call carries.open_pagenavigates and returns a page map: one line per element the agent can operate, each with a reference.click,type_text,press_keyorscrollact on a reference, and the answer lists only what changed.release_profileends the reservation and stops the browser.
A page map is flat text, not nested JSON. The reference in brackets is what the next tool call addresses:
URL: https://x.com/home | epoch 3 | snapshot #7
title: Home
[e_412] textbox "What is happening?"
[e_418] button "Post" (disabled)
[e_431] link "Notifications"How that map comes back after an action is where browser MCP servers differ most. On Hacker News, measured on 8 September 2026, one follow-up step cost 462 tokens with a server that answers with the difference and between 12,076 and 26,438 tokens with five servers that send the page again. The Puppeteer-based MCP server is covered in Puppeteer MCP server.
Why does a browser server serve 21 of its 68 tools?
A browser server serves 21 of its 68 tools because the model API is stateless: every tool definition travels with every request to the model, including the requests that call no tool. Scalebrowser groups its tools into five sets and serves only the first one unless the operator adds more in the daemon's configuration.
| Tool set | Tools | Served by default | What it covers |
|---|---|---|---|
| core | 21 | yes | reserve a profile, open, read, click, type, scroll, wait, screenshot |
| extended | 17 | no | hover, drag, upload, tabs, cookies, the measuring tools |
| management | 22 | no | the fleet by profile id: create, start, stop, tasks |
| workflows | 3 | no | record a routine and replay it |
| credentials | 5 | no | sign in with a stored login |
The 21 default definitions cost 5,267 tokens on every request. No argument a model sends can widen that set: a tool outside it is missing from tools/list and refused when called anyway. The tool reference lists all 68 with what each one does.
How is an MCP server different from an API?
An MCP server differs from an API in who reads the interface: a developer reads an API's documentation and writes code against it, while the model reads an MCP server's tool list during the conversation and decides each call step by step.
| Question | REST API | MCP server |
|---|---|---|
| Who reads the interface | a developer, from reference docs | the model, from tools/list |
| When a call is decided | when the code is written | at each step of a run |
| How an operation is described | endpoints and payloads | a name, a description and a JSON Schema per tool |
| Message format | HTTP requests per endpoint | JSON-RPC 2.0 over stdio or Streamable HTTP |
Many MCP servers are a thin layer over an API that already exists. Scalebrowser's daemon carries both: the REST API for code you write yourself, and the MCP server for an agent, working on the same browser profiles. How a browser agent takes the place of a recorded macro is covered in AI RPA with a browser agent.
What does an MCP server not decide for you?
An MCP server does not decide whether a tool call should happen at all; the protocol leaves that to the host application. The server concepts page says tools "may require user consent prior to execution" and lists approval dialogs, permission settings and activity logs as controls an application can implement. A server that operates real accounts has to be read with that in mind.
Scalebrowser's documentation puts it for a team running agents in production: treat every tool call as final, because there is no confirmation step, no dry run and no undo. What a server can do is narrow what exists. Scalebrowser's refuses a stale reference, an element that something else covers and an address outside the public web, hands out no DevTools endpoint and runs no JavaScript from the model. A read-only mode removes every tool that changes anything, and reserving a profile counts as a change, so an agent under it cannot start a browser at all.
The next step is a client. The MCP client guides show the configuration for Claude, Cursor, Codex and the other hosts, and the MCP server page covers both transports and the full loop.