Browserbase MCP Server vs LiteLLM MCP Server

Browserbase MCP Server and LiteLLM MCP Server are both MCP servers but differ in their categories and capabilities. Browserbase MCP Server (browser, api) is Browserbase MCP and Stagehand MCP are the same server under two names, and this catalog lists both because people search for both — this page is the platform view, /servers/stagehand covers the natural-language automation layer that runs inside it. What Browserbase supplies is the browser itself: a headless Chrome session running in Browserbase's cloud rather than on the machine your agent is on, which is the reason to use it at all. The session is a real, addressable browser with its own residential-proxy and stealth configuration and a recorded replay you can watch afterwards, so an agent's browsing survives being run from a datacenter IP, and a failed run is debuggable after the fact instead of being a black box. Nothing renders on the developer's machine, so a long-running agent is not tied to a desktop staying awake. Browserbase's recommendation is the hosted server at https://mcp.browserbase.com/mcp over streamable HTTP — they operate it and absorb the model inference that the instruction-following tools require. Clients without HTTP transport connect via npx mcp-remote https://mcp.browserbase.com/mcp. Self-hosting installs @browserbasehq/mcp-server-browserbase from npm and needs BROWSERBASE_API_KEY and BROWSERBASE_PROJECT_ID from your dashboard. Six tools are exposed — start and end for session lifecycle, navigate, act, observe and extract — and they are documented in detail on the Stagehand entry, because the act/observe/extract trio is Stagehand's model rather than Browserbase's. One thing to know before self-hosting: the browserbase/mcp-server-browserbase repository was archived on 2026-07-20 and its README now says it is kept for historical reference and should not be read as representative of the current production service. The npm package still installs and the star count on this page belongs to that archived repo; the hosted endpoint is the path Browserbase actually maintains. while LiteLLM MCP Server (ai, api, devops) is LiteLLM is not a single MCP server so much as an MCP Gateway: the MCP layer inside the LiteLLM AI Gateway (proxy), which puts one fixed `/mcp` endpoint in front of every MCP server your organisation uses and controls access to them by key, team and organisation. Start with the install trap, because it is the reason most people land here. There is no separate `litellm-mcp-server` package — that name is not published on PyPI, so any guide telling you to `pip install litellm-mcp-server` is wrong and the command will fail. The gateway ships inside LiteLLM itself, so the correct install is `pip install 'litellm[proxy]'` (litellm 1.95.0 on PyPI), from the BerriAI/litellm repository. Backing servers are registered either in `config.yaml` under `mcp_servers:` or from the LiteLLM UI under MCP Servers → Add New MCP Server; persisting them to the database needs `STORE_MODEL_IN_DB=True` (or `general_settings.store_model_in_db: true`, optionally narrowed with `supported_db_objects: ["mcp"]` so only MCP objects are stored). All three transports are supported for the servers behind it — streamable HTTP, SSE and stdio — so a stdio entry with `command`, `args` and `env` (say `npx -y @circleci/mcp-server-circleci`) sits behind the same gateway endpoint as a hosted URL. Auth per backing server is declarative: `auth_type` accepts `none`, `api_key` (sends `X-API-Key`), `bearer_token`, `basic`, `authorization` (verbatim, no prefix), `token` (GitHub style), `oauth2` — which must declare an `oauth2_flow` of `authorization_code` for interactive PKCE sign-in or `client_credentials` for machine-to-machine — `oauth2_token_exchange` for RFC 8693 on-behalf-of, and `aws_sigv4` for MCP servers hosted on Bedrock AgentCore. `static_headers` covers servers that just want fixed headers on every request, `extra_headers` names headers to forward from the client, and `${VAR_NAME}` server variables can be scoped Instance (shared) or Per-user. On the client side you connect to `http://<your-proxy>:4000/mcp/` with an `x-litellm-api-key` header, choose a server group with `x-mcp-servers`, and pass per-server credentials as `x-mcp-{server_alias}-{header_name}` — `x-mcp-github-authorization: Bearer gho_…` alongside `x-mcp-zapier-x-api-key: sk-…` — so a single connection carries different auth for each backing server instead of sharing one token across all of them. Tool names are namespaced by server, and `litellm_settings.mcp_aliases` maps a short alias onto a server name so tools read `github_create_issue` rather than `github_mcp_server_create_issue`. A direct REST path, `/mcp-rest/tools/list` and `/mcp-rest/tools/call`, lets you list and call tools with curl and no LLM in the loop. One version note: from LiteLLM v1.80.18 the gateway speaks MCP protocol 2025-11-25 and rejects new server names that do not comply with SEP-986; existing non-compliant names only warn for now..

Choose Browserbase MCP Server if you need browser capabilities and prefer npm installation. Choose LiteLLM MCP Server if you need ai capabilities and prefer pip installation. Consider your specific use case and integration requirements.

Yes, you can use multiple MCP servers together in Claude Desktop, Cursor, VS Code, and other MCP-compatible clients.Browserbase MCP Server and LiteLLM MCP Servercan complement each other if their capabilities don't overlap.