11 posts tagged with "MCP"

MiniMax-Coding-Plan-MCP 让 Claude Code 一次性获得 web_search + understand_image 两个能力。

1. 核心定位：专为 Coding Plan 用户设计的 MCP 服务器，2 个工具：网络搜索 + 视觉理解。
2. 背景：纯文本模型（如 DeepSeek v4）原生不能看图，understand_image MCP 给纯文本客户端补齐视觉能力。
3. web_search：调搜索引擎返回有机结果 + 关联查询，替代手动查资料。
4. understand_image：用视觉语言模型分析图片（本地或 URL），支持 JPEG/PNG/WebP。
5. 接入方式：一行 uvx 起服务，Claude Desktop / Claude Code / Cursor 全家桶通用。
6. 关键陷阱：API Key 和 Host 必须同区，否则直接报 invalid api key。
7. 发布：2025-11-20 首发，MIT 协议，stdio / SSE 双传输。

bilibili-mcp 是把 B 站 27 个 高频操作打包成 MCP 工具的服务器。

1. 核心定位：B 站官方 API 之外的 AI 接入通道，覆盖 登录/采集/发布/分析/互动 五类场景。
2. 最大特色：登录由 AI 直接展示二维码，全程不需要切到终端。
3. 采集能力：搜索、评论、字幕、弹幕、视频详情一步到位，支持批量采集。
4. 发布能力：视频、图文动态、图文专栏（Opus）三类内容都能用 AI 代发。
5. 数据分析：热门视频、热搜词、每周必看、17 个分区排行榜、内置 UP 主画像。
6. 互动运营：私信、回复评论、未读消息、收藏夹查询。谨慎使用避免封号。
7. 接入成本：Python 3.10+，一个 git clone + pip install 就能跑。

Context7 把 AI 编码从"凭训练记忆"变成"实时查官方文档"。

1. 它是什么：Upstash 开源的 MCP 服务器，索引 3500+ 库的官方文档。
2. 核心痛点：LLM 训练数据落后于库迭代，AI 经常用旧版 API 或凭空幻觉 API。
3. 触发方式：在 prompt 末尾加 use context7，MCP 自动把最新版文档塞进上下文。
4. Token 友好：~1K token 工具开销，比 GitHub MCP 少一个数量级。
5. 成熟度：截至 2026-06 GitHub 57k+ Stars，覆盖 Cursor/Claude Code/Codex 全家桶。
6. 局限：私有仓库需 API Key，未收录的库 MCP 返空。
7. 结论：对不熟的库懒得翻文档，装它最划算。

Draw.io MCP 三种方案横评，方式 3 是唯一支持协作画图的解。

1. 方式 1（官方 drawio-mcp）：走 jgraph/drawio-mcp 远程生成，每次都是新文件，原图没法覆盖。
2. 方式 2（官方 Plugin + Desktop）：能本地覆盖原文件，但 不支持实时编辑，要手动 reload。
3. 方式 3（推荐，next-ai-draw-io）：本地起 localhost，真正支持实时编辑，Agent 改一步你能立刻看到。
4. 结论：想让 Agent 协作式画图，方式 3 是目前唯一解。

codebase-memory-mcp 是一款纯 C 编写的代码知识图谱 MCP 服务器，给 Claude Code / Codex / Open Code 装上"项目结构感知"能力。

1. 核心定位：用 MCP 把代码库索引成可交互的知识图谱，AI 改代码前能感知调用链、依赖与爆炸半径。
2. 架构特点：零依赖单文件二进制，不依赖 Node / Python 环境，下载即可跑。
3. 能力边界：支持 158 种语言、内置 20+ 语义关系、支持 OpenCypher 图查询。
4. 对比 CodeGraph：提取精度 / 调用图完整性 / 查询能力 三项领先，索引速度落后，平均分几乎持平。
5. 典型场景：快速上手陌生项目、PR 影响半径分析、死函数检测、跨语言特性迁移。
6. 代价：单次索引 20+ 分钟，MCP 集成会占用系统资源，且与 GitNexus 跨仓能力有差距。

Chrome DevTools MCP 特点是让 AI 编码助手直接接管 Chrome，复用登录态 + 拿到原生 DevTools 数据。

1. 定位：基于 Puppeteer 的 MCP 服务器，暴露 26+ 工具给 AI（点击、填表、截图、性能 trace、网络请求）。
2. 核心优势：无需重新登录，可直连你当前 Chrome 会话；AI 能调起完整 DevTools 面板。
3. 三种连接模式：默认独立实例 / --autoConnect 复用会话 / --browser-url 远程调试端口。
4. 关键陷阱：远程调试端口无鉴权，同机任何应用都能连；MCP 客户端可读浏览器全部数据。

agent-browser 和 Playwright CLI 的区别不在"谁更好"，而在谁在做决策——是 LLM 自己看着办，还是人写好每一步指令。

1. agent-browser 目标驱动：给自然语言目标，LLM 自己规划并执行
2. Playwright CLI 步骤驱动：open → click → fill，每一步都得人写清楚
3. agent-browser 用 Accessibility Tree + @ref，Token 仅为完整 DOM 的 5%
4. Playwright CLI 交互结果写磁盘，Agent 按需读，Token 比 MCP 方案省更多
5. agent-browser 直连 CDP 复用登录会话；Playwright CLI 默认隔离上下文
6. 容错逻辑相反：agent-browser LLM 语义兜底，Playwright CLI ref 变就挂
7. 两条路都能走，走反了就是纯烧 Token

Playwright MCP 和 Chrome DevTools MCP 不是竞品——一个负责"开"，一个负责"修"。

1. Playwright 做浏览器自动化（干活），DevTools 做性能诊断（找问题）
2. Playwright 基于 Accessibility Tree，Token 仅为原始 DOM 的 20-30%
3. DevTools 基于 CDP，能拿到网络瀑布、Lighthouse、堆快照等完整运行时数据
4. Playwright 支持全平台浏览器；DevTools 仅 Chromium
5. DevTools 独有 Trace 自动分析、Lighthouse 审计、V8 堆内存快照
6. Playwright 独有 Auto-wait、跨浏览器测试、结构化定位

一句话：日常交互用 Playwright，需要性能/网络排查时切 DevTools。

agent-browser 把浏览器从"给人用的 GUI"变成了"给 AI 用的 API"。

1. 定位：专为 AI Agent 设计的浏览器操控工具，自然语言输入、结构化结果输出。
2. 两种实现：Vercel agent-browser 是 Rust CLI（二进制 7MB），browser-use 是 Python 框架。
3. 核心差异：传统自动化写死每一步，agent-browser 是目标驱动——只关心"做到没有"。
4. 底层原理：CDP 直连 + Accessibility Tree 快照，context 用量比完整 DOM 少 90%。
5. 实际数据：WebVoyager 成功率 91.3%，单任务成本不到 $0.09。
6. 2026 趋势：MCP 集成、本地优先、反 Bot 对抗升级三条主线。