mcp-server-browserbase 实操:六个动词让 AI 驱动云端浏览器
上一站聊过 Bright Data 的抓取型 MCP,这次换个相反的路数:mcp-server-browserbase(GitHub 仓库 browserbase/mcp-server-browserbase,Apache-2.0 协议)不追求工具多,只给六个动词,让 AI 用自然语言驱动一台真正的云端浏览器。这篇带你把托管端点接进客户端、分清六工具与本地包十七工具的差别,并看清"仓库已归档"这件事意味着什么。同类 MCP 实操合集见 站点总纲。
六个动词是什么
这个服务器背后的执行引擎叫 Stagehand(同公司开源的浏览器自动化框架),云端跑的是 Browserbase 托管浏览器。README 的工具表相当克制:

六个工具覆盖开会话、导航、动作、观察、提取、关会话;schema 来自 2026-10-18 托管端点实测
设计上 act 吃自然语言("点击登录按钮"),observe 先看清楚页面上有什么可点的,extract 按指示抽数据。一次典型流程:start 开会话 → navigate 到目标页 → observe 找元素 → act 执行 → extract 拿结果 → end 收摊。六个动词之间传 sessionId 就能复用或重连会话。
放到真实对话里,你对 AI 说"去 example.com 找到登录入口,用 demo@example.com 和密码 123456 登录,然后把首页第一屏的商品名和价格抄下来",客户端会把这句话拆成一串工具调用:先 start 拿 sessionId,navigate 到目标域,observe 问"页面上有哪些可输入的元素",再分两次 act——"在 email 输入框填入 demo@example.com"、"点击 type 为 submit 的按钮",最后 extract 带一句"instruction: 提取商品名称与价格"收数据,end 关会话。每个动作的粒度有讲究,本地包实测拿到的工具描述里有一句写作建议值得照抄:
Act actions should be as atomic as possible.
动作拆得越原子(一次只填一个框、只点一个按钮),Stagehand 的命中率越高;一个 act 里塞三件事,失败了你也不知道卡在哪一步。同理,observe 的 instruction 也写具体些——"找出页面上的筛选控件"比"看看这页有什么"返回的 ref 列表干净得多。
两条接入路线
官方推荐托管版,理由写在 README 第一段:We recommend using the hosted version for the easiest setup——他们连 Stagehand 用的 Gemini 模型推理费都替你出了。托管端点是:
https://mcp.browserbase.com/mcp
客户端支持 SHTTP 就直接填这个 URL;不支持的(如老版 stdio-only 客户端)用 mcp-remote 桥接:
{
"mcpServers": {
"browserbase": {
"type": "http",
"url": "https://mcp.browserbase.com/mcp"
}
}
}
走本地 stdio 则需要 Browserbase 账号的 BROWSERBASE_API_KEY、BROWSERBASE_PROJECT_ID 和一个 GEMINI_API_KEY 三个环境变量:
{
"mcpServers": {
"browserbase": {
"command": "npx",
"args": ["@browserbasehq/mcp"],
"env": {
"BROWSERBASE_API_KEY": "",
"BROWSERBASE_PROJECT_ID": "",
"GEMINI_API_KEY": ""
}
}
}
}
自托管路线还有 clone 后 npm install、Docker build 两种跑法,配置结构相同。注意 npm 包名有两代:@browserbasehq/mcp-server-browserbase(最新 2.4.3)对应仓库里的完整服务器,@browserbasehq/mcp(最新 3.0.0)是官方现在主推的入口。
免 Key 能走多远:一次实测
托管端点对未登录用户出乎意料地开放。不带任何凭证发 JSON-RPC 握手,直接返回正常应答:

2026-10-18 实测:握手与 tools/list 免 Key 返回,tools/call 创建会话被拒
三段分别是:initialize 拿到 serverInfo(名字是 stagehand-api,版本字段是一串构建哈希);同一会话 tools/list 返回六个工具与完整 JSON Schema;到 tools/call 真要开浏览器会话时,端点返回 -32000 Invalid query parameters——翻译过来就是:看菜单免费,点菜要凭证。对接客户端前拿 curl 这么探一遍,能在不注册账号的情况下确认端点活着、工具清单对不对。
本地包的真相:17 个工具
有趣的地方来了。把选题快照对应版本的本地包拉下来跑 stdio(Node 20 环境,慢速 stdin 喂 JSON-RPC):
npx -y @browserbasehq/mcp-server-browserbase@2.1.1
握手正常,serverInfo 自报 Browserbase MCP Server 2.0.0,但 tools/list 吐出来的不是六个动词,而是 17 个长名字工具:单会话的 browserbase_session_create、browserbase_stagehand_navigate、browserbase_stagehand_act、browserbase_screenshot 一族,加一套 multi_browserbase_stagehand_session_create 开头的多会话并行族(独立 cookie、独立状态,面向并行抓取、多账号、A/B 测试这类场景)。试着按 README 的名字调 start,返回 MCP error -32602: Tool start not found。
也就是说:README 写的六工具对应托管端点(实测一致),本地 2.x 包的工具面是另一套扩展过的命名。想在本地配置里精确控制,先跑一次 tools/list 看自己那版到底暴露了什么,别照着 README 抄工具名。启动时若看到 Warning: BROWSERBASE_API_KEY environment variable not set. Using dummy value.,说明环境变量没传进 MCP 配置的 env 块——实测中这三条警告不影响握手和工具清单,但真调用会失败。
自托管的调节旋钮
本地包支持一排命令行开关,从视口尺寸到换模型:

13 个开关只对自托管生效;默认模型 google/gemini-2.5-flash-lite,换 Claude 等模型须带 --modelApiKey
值得留意的三个:--browserWidth / --browserHeight 默认 1024×768,截图或响应式断点相关的任务记得按需调;--verified 是反检测身份验证,但官方注明仅 Scale 套餐可用,旧名 --advancedStealth 已弃用只是别名;--keepAlive 适合长流程任务防会话中途被收。换模型的两条参数必须成对出现,且模型要在 Stagehand 支持列表里(docs.stagehand.dev)。
归档仓库怎么用
这个仓库的 README 顶上有一段不加掩饰的声明:
This repository is archived and no longer maintained. It was originally published as a reference implementation and is retained for historical purposes. It should not be interpreted as representative of Browserbase's current production services or implementation.
官方归档的原因写在同一页:自托管版是"参考实现",官方希望你用他们托管的 mcp.browserbase.com/mcp(功能相同的正式服务),仓库本身不再演进。写稿时核实:GitHub 显示 archived 状态、最后一次 push 停在 2026-07-20,star 3399。这不是"项目死了"——托管端点实测活跃,npm 包也还在发版——而是"代码冻结成参考样本"。
对使用者的影响实际很小:走托管端点照常工作;要自托管的话,这个仓库的代码是只读起点,深度定制前先掂量没人修 bug 的代价。浏览器自动化 MCP 的官方文档入口在 docs.browserbase.com/integrations/mcp/introduction。
来源与延伸
本文依据 browserbase/mcp-server-browserbase 官方 README(Apache-2.0)与托管端点、npm 包实测整理,实测记录时间为 2026-10-18;工具清单以你实际拿到的 tools/list 为准。