OpenClaw 和 MCP 怎么接：把浏览器能力做成 Agent 可控工具
OpenClaw 这类浏览器能力，如果只是当成“让 AI 打开网页”的插件，很快就会遇到两个问题。
第一，Agent 每次都在临时描述任务，边界不稳定。第二，浏览器能做的动作太多，读页面、搜索、点击、输入、下载、提交都混在一起，权限很难管。
更稳的做法，是把 OpenClaw 能力拆成几个小工具，再用 MCP 这类协议接给 Agent。这样 Agent 看到的不是一个大而全的浏览器，而是一组边界清楚的工具：读网页、找链接、展开内容、提取字段、生成待确认清单。
先不要把“控制浏览器”做成一个工具
很多人接 MCP 工具时，会想做一个万能工具：
browser_control(action, url, selector, text)看起来灵活，实际很危险。因为这个工具几乎什么都能做：打开页面、点按钮、填输入框、提交表单、下载文件，甚至在登录状态里改配置。
对 Agent 来说，工具越万能，越容易乱用。它可能为了完成任务自己推断 action，也可能在 selector 不稳定时继续尝试别的按钮。最后你很难判断问题出在模型、工具参数、页面状态，还是任务本身写得太宽。
我更建议把浏览器能力拆小：
| 工具 | 允许做什么 | 不允许做什么 |
|---|---|---|
fetch_page | 读取公开网页正文 | 不执行登录态动作 |
search_web | 搜索候选页面 | 不把结果当事实 |
inspect_page | 读取页面标题、链接、按钮、表单结构 | 不点击提交类按钮 |
extract_fields | 按字段表提取可见内容 | 不补全没看到的信息 |
expand_readonly | 点击 FAQ、折叠面板、目录跳转 | 不保存、不发布、不发送 |
这样做的好处是：每个工具都能单独测试，也能单独限权。Agent 想做高风险动作时，工具层本身就不会给它入口。
MCP 工具参数要窄，不要让模型自由发挥
MCP 工具最容易踩坑的地方，是参数写得太宽。
比如你给 Agent 一个参数：
{"instruction":"你想怎么操作都写在这里"}这等于把安全边界交还给自然语言。模型当然能理解很多指令，但它也会误解、漏看、补全，尤其是在网页状态变化后。
我更喜欢把参数设计成这种结构：
{"url":"https://example.com/docs","mode":"read