浏览器自动化还在写脚本？一个轻量MCP Server直接把它变成标准Tool

你有没有遇到过这种情况：想让AI Agent自动操作网页——填个表单、抓个数据、点个按钮——结果光是配置浏览器驱动、处理反爬、解析DOM就折腾半天？

更头疼的是，每个Agent框架的浏览器工具接口都不一样，今天用Playwright，明天换Puppeteer，后天又要兼容Selenium。代码写了一堆，复用率几乎为零。

问题的核心不是浏览器自动化难，而是它没有被"标准化"。

今天聊一个思路：用一个轻量MCP Server，把Puppeteer的浏览器能力封装成标准的MCP Tool，让任何支持MCP协议的LLM都能直接调用浏览器，就像调用一个API一样简单。

什么是MCP？为什么它能解决这个问题

MCP（Model Context Protocol）是Anthropic提出的开放协议，核心目标是：让LLM和外部工具之间的通信标准化。

打个比方：以前每个工具都像一个方言，Agent要学十种方言才能调用十个工具。MCP就是普通话——工具说MCP，Agent说MCP，大家就能对话。

所以，如果我们把浏览器自动化封装成一个MCP Server，那任何支持MCP的Agent（Claude、OpenClaw、龙虾等）都能直接"用"浏览器，不用关心底层是Puppeteer还是Playwright。

这个轻量MCP Server做了什么

这个项目的核心思路很清晰：用Puppeteer做底层驱动，通过MCP协议暴露结构化的浏览器操作能力。

它提供的不是一堆原始API，而是几个语义明确的工具：

tools:
  - navigate: 打开指定URL
  - click: 点击页面元素（通过可访问性描述定位）
  - type: 在输入框填写内容
  - screenshot: 截图并返回base64
  - get_page_content: 获取页面结构化内容

关键设计点有两个：

1. 结构化可访问性数据，不是原始DOM

传统做法是把整个DOM树丢给LLM，token爆炸不说，LLM还经常解析出错。这个Server的做法是：只提取可访问性树（Accessibility Tree）。

什么是可访问性树？就是浏览器为屏幕阅读器生成的语义化结构——按钮就是按钮，输入框就是输入框，链接就是链接。比原始HTML干净得多，LLM理解起来也更准确。

// 获取页面可访问性快照
const snapshot = await page.accessibility.snapshot();
// 返回的不是HTML，而是这种结构：
// { role: "button", name: "提交", children: [...] }

LLM看到的是"有一个叫'提交'的按钮"，而不是一坨<button class="btn btn-primary" data-action="submit">提交</button>。哪个更好理解，不言自明。

2. 可选视觉模式，处理复杂场景

纯文本的可访问性数据能覆盖80%的场景，但有些情况——比如验证码、图表、Canvas绘制的内容——文本描述不了。

这时候可以开启视觉模式，让Server截图并以图片形式返回给LLM。Claude这类支持多模态的模型可以直接"看"截图来理解页面状态，然后决定下一步操作。

// 视觉模式：截图 + 可访问性数据双通道
if (visualMode) {
  const screenshot = await page.screenshot({ encoding: 'base64' });
  const snapshot = await page.accessibility.snapshot();
  return { screenshot, accessibility: snapshot };
}

跨平台兼容怎么实现的

这个Server的跨平台能力来自Puppeteer本身的设计。Puppeteer支持Chrome、Firefox，甚至可以通过配置指向本地已安装的浏览器，不需要额外下载Chromium。

在MCP Server层面，它把浏览器启动配置做了抽象：

{
  "browser": "chrome",
  "headless": true,
  "executablePath": "/usr/bin/google-chrome"
}

不管你在macOS、Linux还是Windows上跑，只要指定好浏览器路径，Server就能启动。对于容器化部署（Docker），配合puppeteer官方镜像基本开箱即用。

实际应用场景：一个完整的自动化案例

假设你要做一个"自动比价Agent"：用户说"帮我看看京东和拼多多上iPhone 16的价格"，Agent自动打开两个网站、搜索商品、提取价格、返回对比结果。

用这个MCP Server，Agent的工作流是这样的：

Agent收到任务 → 调用navigate工具打开京东 → 调用type工具输入"iPhone 16" → 
调用click工具点击搜索 → 调用get_page_content获取商品列表 → 
重复上述流程访问拼多多 → 对比价格 → 返回结果

整个过程中，Agent不需要知道Puppeteer的API长什么样，它只需要调用MCP标准的工具接口。浏览器自动化变成了一个"即插即用"的能力模块。

对AI Agent生态的意义

这个思路的价值不只是"又一个浏览器工具"，而是它展示了一种模式：把复杂的基础设施能力，通过MCP协议封装成LLM可以直接消费的标准工具。

浏览器只是开始。同样的思路可以应用到：

• 数据库操作（SQL查询封装成MCP Tool）
• 文件系统（读写文件封装成MCP Tool）
• API调用（REST/GraphQL封装成MCP Tool）

当这些能力都变成标准的MCP Tool，构建Agent就不再是"从零写集成代码"，而是"像搭积木一样组合工具"。

下一步：动手试试

1. 克隆项目：git clone [项目地址]，跑起来看看它暴露了哪些工具
2. 接入你的Agent：如果你在用Claude或支持MCP的框架，在配置里加上这个Server的地址
3. 改造一个自己的MCP Server：把你常用的脚本（爬虫、数据处理、API调用）封装成MCP Tool，体验一下"工具标准化"的爽感

浏览器自动化不应该每个Agent都重写一遍。封装一次，到处复用——这才是MCP协议的正确打开方式。