每个页面一个上下文：MCP-B智能导航神器

banq

如今的人工智能自动化就像是用机器人读取你的屏幕并点击按钮一样。MCP-B 则能让人工智能直接访问你网站的功能。

添加 50 行代码，AI 助手的工作速度可提高 1000 倍，且无需任何配置。

5分钟内试用

1、安装扩展：Chrome 网上应用店

2、添加到您的网站：

npm install @mcp-b/transports @modelcontextprotocol/sdk zod

3、公开一个工具：


import { TabServerTransport } from '@mcp-b/transports';
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';

const server = new McpServer({
  name: 'my-app',
  version: '1.0.0'
});

server.tool('sayHello', 'Says hello', {
  name: z.string()
}, async ({ name }) => ({
  content: [{ type: 'text', text: <code>Hello ${name}!</code> }]
}));

await server.connect(new TabServerTransport({ allowedOrigins: ['*'] }));

4、访问您的网站并单击 MCP-B 扩展，转到 MCP 服务器选项卡并单击您的工具

如果一个网站想要公开“删除所有用户数据”工具，那是他们自己的事。这和在页面上放一个大大的红色删除按钮没什么区别。MCP-B 只是让 LLM 也能使用这些功能。我计划尽快添加对引导功能的支持。

好的网站是Context工程
最近有个特别火的概念叫"上下文工程"，说白了就是让AI只关注跟手头任务相关的东西。举个栗子，这就好比给你100种工具让你做桌子，但其实只有锯子、锤子、钉子这几样有用——其他90多种工具不仅帮不上忙，反而会让你手忙脚乱。就像老师让你做手工，结果把整个文具店都搬到你面前，还不如直接给你需要的剪刀胶水来得方便呢！

而MCP-B这个技术最牛的地方在于：它能像智能导航一样，根据AI在网站里走到哪一步，只给它展示当前需要的工具。就像我们刷手机APP时，不会把所有功能都堆在一个页面，而是分成不同标签页——你要点外卖就看美食页，要打车就切换出行页。这样AI就不会被无关信息干扰，就像你不会在写作业时突然看到游戏广告一样分心啦！➡️

简单来说，MCP-B 本来只需要 TabTransports（网页内通信）就能工作，但现在的扩展插件同时用了两种通信方式。你可以把 MCP-B 扩展服务器 想象成一个“工具调度中心”：

  1. 它收集所有网页（标签页）里的工具，就像一个管理员把所有工具箱里的螺丝刀、锤子、扳手都登记在册。
  2. 当某个工具被调用时，它就像快递员一样，把请求精准送到对应的网页（标签页）和网址。
  3. 扩展层还负责一些杂活，比如缓存工具（把常用工具放手边）、自动打开对应网页（如果工具所在的标签页没开，就帮你新开一个）。

两种通信方式（就像两种对讲机）：

  1. TabTransports（网页内对讲机）
    • 用 postMessage（网页内传小纸条）让 MCP服务器 和 客户端 在同一个标签页里聊天。
    • 比标准协议更灵活：比如服务器加载慢了，客户端会耐心等它，还会主动打招呼“嘿，我在这儿！”
  • ExtensionTransports（扩展插件对讲机）
    • 用 Chrome 的 runtime messaging（插件内部对讲机）让 侧边栏、弹窗、后台脚本 互相通信。

    实际运行流程（就像侦探办案）：

    • 当你访问一个带 MCP服务器 的网站时，扩展插件会悄悄往网页里 注入一个客户端（派个小侦探）。
    • 这个小侦探会：
      1. 主动寻找网页里的 MCP 服务器（喊：“服务器大哥在吗？”）。
      2. 把找到的工具都上报给扩展的调度中心（“我发现这个网页有锤子和锯子！”）。
      3. 随时待命，接收扩展的指令（“快用锤子！”）或者服务器的更新（“现在锤子升级成电动的了！”）。
    这样，MCP-B 就能精准控制工具，不会让你在“拧螺丝”时突然掏出一把菜刀！ →❌


    为什么不用 Computer Use或浏览器自动化？
    Dwarkesh Patel 最近写了 一篇关于我们对计算机使用的看法的文章：
    “它一开始很好用，直到完全不起作用。然后就比没用更糟糕了。”

    他做了基准测试：一个简单的搜索需要 44 秒，花费 4-5 美元。这根本算不上什么工具，而是一个非常昂贵的派对技巧。

    Playwright MCP 是这群人中最聪明的——他们使用可访问的“树"而不是像素。但问题是：他们都押注了同一匹必输的马。他们假设模型最终会非常优秀，以至于他们……能够自己搞定一切。导航任何 UI，理解任何布局，每次都能点击到正确的按钮。

    这又是通用人工智能的幻想。我们构建工具是为了我们渴望拥有的模型，而不是为了我们实际拥有的模型。

    Dwarkesh 对此做出了如下评价：
    “计算机有 API。计算机调用 API。这就是计算机所做的。”

    那么，我们为什么要教它们扮演人类点击按钮呢？
    思考一下这些方法真正要求的是什么：

    • 计算机使用：“解析这些像素并确定要点击的内容”
    • Playwright MCP：“这是可访问性树，弄清楚该点击什么”
    • MCP-B：“这里有一个名为的函数addToCart()，调用它”

    MCP-B 承认了通用人工智能 (AGI) 并非明天就能实现。如果我们真的想实现部分白领工作的自动化，就需要为此构建基础设施。LLM 最适合处理文本和函数调用，而不是假装人类操作鼠标。MCP-B 为 LLM 奠定了基础，使其能够像计算机那样通过 API 实现浏览器的自动化。

    MCP-B 扩展附带一个聊天客户端，可以访问所有 MCP 扩展工具，以及一个模型检查器类型的 UI，允许您查看活动工具列表并使用手动输入的参数调用它们。


    极客辣评

    这给网站所有者带来了负担。如果我费力地为我的网站创建并发布 MCP 服务器，我假设我可以通过某种目录或方法与消费者（浏览器和其他客户端）进行沟通。如果能够自动化 MCP 的创建和维护，对网站所有者来说将更有价值。

    我认为这是切实可行的方法。网站所有者（或者更确切地说是网站建设者，因为如果你运行的是 WordPress，我们可以假设 MCP 会包含在软件包中）已经负责跨多种设备的人机界面，以及搜索引擎界面（robots.txt、sitemap.xml、metatags）。如果能有一个标准来规范 AI 所见的内容以及它如何与用户互动，那将大有裨益。

    我认为两者都有发展空间：一个是更通用的工具，可以自行解决问题；另一个是精简的工具，可以访问网站的导航。当然，还有不需要浏览器或用户界面的后端服务，但正如他所描述的，这会带来身份验证方面的复杂性，我猜想这会增加可发现性。

    像 wordpress、shopify 等平台很可能会推出 MCP 扩展来支持各种用例。如果能搭配类似 llms.txt 的发现标准，我认为这也会很有帮助。我唯一的理由是，这类平台也是最“模板化”的设计，而且 AI 已经很容易驾驭它们了（因为 DOM 结构的差异很小）。

    我认为更大的挑战是如何轻松地为 SaaS 和其他传统门户构建 MCP。我看到一些 OpenAPI 方面的推动，这很有前景，但需要对现有应用进行重大更改。或许 Web 框架（例如 Rails、Next、Laravel 等）可以就一个标准达成一致。


    MCP-B 的前提是，如果您仅仅依赖 DOM 遍历或计算机视觉，那么使用 LLM 可靠地浏览网站实际上并不容易。
    当涉及到身份验证和读/写操作时，我认为您需要来自 MCP-B 之类的可靠性和控制力，而不是仅仅相信 LLM 来解决问题。

    Wordpress 和 Shopify 都允许用户高度自定义前端，因此如果他们愿意（或者不知道更好的方法）的话，可能会生成一堆垃圾 HT​​ML + CSS。如果我想实现自动购买或其他涉及信任和/或敏感数据的操作，我当然不想依赖 LLM 来解析任意 HTML。

    为什么需要 MCP-B？——因为光靠 AI 自己“看”网页太不靠谱了！  

    想象一下，你让一个 AI 去网购，但它只能像人一样盯着网页瞎猜：  
    - “这个按钮是‘加入购物车’吗？还是广告？”  
    - “这个输入框是密码栏，还是‘搜索商品’的框？”  
    - “这个页面加载完了吗？还是卡住了？”  

    如果网页的代码写得乱七八糟（比如 WordPress 或 Shopify 用户随便拖拽生成的 HTML），AI 就更懵了——就像让你在一堆乱涂乱画的纸条里找密码，太容易出错了！  


    MCP-B 的厉害之处：给 AI 装个“精准遥控器”  
    MCP-B 不是让 AI 自己“猜”网页，而是直接告诉它：  
    1. “这里有个‘购买按钮’，它的功能是 X，调用方式是这样的……”（而不是让 AI 自己找按钮）  
    2. “这个输入框是‘信用卡号’，必须加密传输，别乱填！”  
    3. “这个页面需要登录，账号密码走安全通道，别泄露！”  

    这样，AI 就不用瞎蒙了，而是像用自动化工具一样精准操作，避免：  
    - 买错东西（因为误点了广告按钮）  
    - 泄露密码（因为把密码填到了评论框）  
    - 操作失败（因为网页结构突然变了，AI 不认识了）  


    总结：MCP-B 是 AI 浏览网页的“安全带”  
    - 普通 AI 浏览网页 = 蒙着眼睛在雷区走路  
    - MCP-B 控制的 AI = 拿着地图和防爆装备，安全完成任务 ✅  

    如果你想让 AI 帮你自动购物、管理账户、处理敏感操作，你肯定不希望它靠“猜”来执行，对吧？MCP-B 就是来解决这个问题的！ ️


    问：感觉就像浏览器上的 Selenium
    回答：两者相似但又截然不同。Playwright 和 Selenium 都是浏览器自动化框架。Playwright-MCP 服务器可让您的代理使用 Playwright 进行浏览器自动化。
    MCP-B 则采用了一种不同的方法。网站所有者在其网站内部创建 MCP 服务器，而 MCP-B 客户端则通过浏览器扩展程序注入，或包含在网站的 JS 中。
    您获得的不是像 Playwright 那样的视觉解析，而是标准的确定性函数调用。
    您可以在博客文章中查看代码示例：https://mcp-b.ai/blogs