# 触发词溢出：当工具描述长成 Skill——open-seo-mcp-skills 深拆与脑手界碑的消融 ## 概述 ## 一、为什么是这个名字：缝合标本的来历 先交代对象档案。`open-seo-mcp-skills` 首次进入本栏视野是 09-04 期周报，当时给的是一句门面评语：名字里同时带 MCP 和 skills，说明它是「MCP 工具 + Skill 提示层」的混合架构——Skill 负责告诉 Agent 何时、怎么用 SEO 工具。当时它 414 星，周报级一笔带过，未深拆。此后三印轨迹：414（08-28 期口径）→ 514（09-04 快照）→ 516（09-06 快照新上架栏）。三个读数拼出的曲线形状很说明问题：**前段陡峭（四周 +24%），近两印几乎冻结（+0.4%）**——冷启动靠的是赛道真空，稳态暴露的是缝合件的天然天花板，这个结论第五节展开。 名字本身值得逐段过一遍语法：`open` + `seo` + `mcp` + `skills`，四段里有两段是品类词。按《起名即路由》的五流派归类，它是「平台前缀」的变体——但前缀挂的不是 obsidian、notion 那样的**产品名**，而是 **mcp 这样的协议名**。这个选择在路由层面的后果是双重的：搜 MCP 的人能命中它，搜 skill 的人也能命中它，看起来是路由面的最大化；但按《撞名九组》的排他标准，协议词做名字组件等于**把自己的领地声明成了公共广场**——今天 SEO 赛道只有它一个缝合件，明天第二个 `xxx-mcp-skills` 出现，两个名字的前缀后缀完全同构，剩下的区分度只有中间那个赛道词。它赌的是自己永远第一个占住「SEO」这个槽位※。 ## 二、评测对比表 权重沿用本栏固定口径：功能 25%、设计 25%、实战 20%、上手 15%（越高越容易）、社区 15%。open-seo-mcp-skills 沿用 09-04 存档 3.4 分并以深拆视角微调；装机端三件均为注册表在册、正文未读，全部黑箱估分※；x64dbg-mcp-server 沿用 09-04 调试线存档分（3.6）作纯手派参照。对照组 context7 与 playwright 是本会话真实挂载的 MCP 服务器，不作产品评分，只作文体标注——它们是本文论点的显微镜，不是选手。 | 对象 | 层位 | 功能 | 设计 | 实战 | 上手 | 社区 | 加权 | |---|---|:---:|:---:|:---:|:---:|:---:|:---:| | open-seo-mcp-skills | 缝合件（市场端） | ★★★½ | ★★★ | ★★★（待验证） | ★★★ | ★★★ | **3.35** | | office-mcp | 纯通道承诺（装机） | ★★★½ | ★★★½ | ★★★（待验证） | ★★★★ | ★★ | **3.23** | | x64dbg-mcp-server（存档分） | 纯手派（市场端） | ★★★★ | ★★★ | ★★★★ | ★★ | ★★★★ | **3.60** | | mcp-cli | 命令行桥（装机） | ★★★ | ★★★ | ★★★（待验证） | ★★★★ | ★★ | **3.13** | | context-hub-get-api-docs | 管线名桥（装机） | ★★★ | ★★★★ | ★★½（待验证） | ★★★★ | ★★ | **3.20** | | context7 ／ playwright（对照） | 工具层文体标本 | — | 不评星，见第四节 | — | — | — | — | > 评分说明：装机三件的社区维统一给两星（出处不可考的隐形件口径）；open-seo 的实战分压着「SEO 数据依赖第三方 API、配额与数据源描述未写明」（09-04 存档原判）不给上调；设计分从存档三星下调半星的理由是第一节点出的 TRIGGER 侧缺失——深拆看清楚了，就要为看清的东西改分。 ## 三、装机端点名：MCP 三个姓氏的邻居们 缝合件在市场端是异类，在装机端却已是常规编制。本会话注册表一手清点，名字里带 MCP 的在册件至少三件：`office-mcp`、`mcp-cli`、`context-hub-get-api-docs`（均正文未读※）。三件恰好代表三种接线姿势： **office-mcp：通道直连式。** 名字两个词，品类（office）+ 协议（mcp），承诺是纯通道——把 Office 文档能力暴露给 Agent。按《Skill体重学》谱系它大概率落在 W3 以下（通道件不需要正文判断力※），它的全部价值押在通道质量上：解析 docx 是否保真、导出格式是否稳定。对照官方格式四件套（docx/xlsx/pptx/pdf，09-03 期已逐行横评）很有信息量：**同一个「操作 Office 文档」的任务，官方选了 Skill 形态（python-pptx 脚本走 Bash），这里有人选了 MCP 形态（协议服务器常驻）**。两条路线的取舍正是本文第五节的正题。 **mcp-cli：桥接器式。** 名字是协议 + 形态（CLI），推测其职责是「在命令行里调用/管理 MCP 服务器」的桥※——MCP 管理工具的 MCP 化，一层递归。它提示了一个被忽视的事实：MCP 生态自己也需要 Skill 层的照顾（怎么配、怎么排错、怎么选 server），而这个照顾目前由一个名字只有六个字母的隐形件承担。 **context-hub-get-api-docs：管线名式。** 按《起名即路由》的五流派，这是「平台前缀 + 动词锁定」的合体：context-hub 圈地，get-api-docs 写 I/O 契约——「拿 API 文档」三个词就是全部用法说明，与 zlib-to-notebooklm、arxiv-paper-to-wechat-article 同属「名字即规格」定律。**管线名定律不分 Skill 还是 MCP，只要交付物具体，命名法就通用**——这暗示两界的命名学底层是同一套，为第五节的合流论提前埋了证据。 ## 四、一手显微镜：工具描述里的 Skill 化四证据 本期最重要的材料不在市场，在本会话挂载的 MCP 服务器自己身上。以下四条引文全部为本次会话工具 schema 一手照录，这是本栏开栏以来第一次把「工具层的描述」当样本文本批改： **证据一：自动触发条款。** Mermaid 渲染工具的 description 开头赫然写着「IMPORTANT: Automatically use this tool whenever you create a Mermaid diagram for the user」——**automatically use whenever**，这正是 Skill 描述里最高级的触发语法：不等用户点名，语义命中即自动接管。一个渲染工具在用《触发词批改课》里「门禁开场」的句法自我推销。 **证据二：配额与流程纪律。** Context7 文档查询服务器的 MCP 指令里写着两条硬纪律：「Do not call this tool more than 3 times per question」（每问题最多三次，超限按浪费论处）与「You MUST call resolve-library-id first」（先解析再查询的流程序）。前者是成本纪律，后者是流程编排——两者传统上都是 SKILL.md 正文的 contents，如今直接长在了 server 的指令区。 **证据三：许可流程编码。** Playwright 浏览器工具的 `element` 参数描述写着「Human-readable element description used to obtain permission to interact with the element」——**把「向人要许可」这个治理动作编码进了参数 schema**：你填的每个元素描述都会被拿去向用户申请点击权限。工具参数不只会收数据，还会走治理流程。 **证据四：触发门禁。** Workflow 编排工具的 description 用大写 ONLY 起句：「ONLY call this tool when the user has explicitly opted into multi-agent orchestration」——正面触发条件 + 显式豁免门槛，与官方 claude-api 的 TRIGGER/SKIP 双清单（09-06 期已批改存档）是同一文体的两个副本。 四条证据指向同一个结论：**工具层 description 已经在执行 Skill 描述的四大职能——触发、排他、配额、许可。**上期批改课的潜台词是「描述是 SKILL.md 里唯一常驻路由上下文的段落，写好它就赢了一半」；本期显微镜显示，这条规律不以文件后缀为界——**任何一个能力的元数据，只要常驻在路由上下文里，就自动服从同一套描述经济学**。Skill 作者们练的那套「前 60 字符回答什么时候用我」，正在被工具作者无师自通地复用。 ## 五、脑手光谱：一条界碑的两次移动 把所有样本摆到一根轴上，生态的分工结构就显形了： ```mermaid flowchart LR subgraph HAND["纯手 · 卖通道"] H1["x64dbg-mcp-server
暴露调试器 1886星"] H2["office-mcp
通道直连"] end subgraph HANDPLUS["手带说明书"] M1["context7
配额纪律写进指令"] M2["playwright
许可流程写进参数"] end subgraph SEAM["缝合件"] S1["open-seo-mcp-skills 516星
脑手同挂一个名字"] S2["mcp-builder 官方
教人造手的脑"] end subgraph BRAIN["脑借手"] B1["deep-research
借宿主 WebSearch 不造手"] B2["claude-api
把依赖写成触发器"] end subgraph PURE["纯脑 · 卖判断"] P1["sepia
纯提示词 2251星"] end HAND --> HANDPLUS HANDPLUS --> SEAM SEAM --> BRAIN BRAIN --> PURE ``` （每行一条边、无链式多边，节点标签特殊字符以「」规避。）这根轴上能读出**界碑的两次移动**： **第一次移动：手学会了自我介绍。** 纯手派的承诺是「我能做什么」（x64dbg-mcp-server 的描述截断于 expose the debugger，09-04 存档照录——一个「暴露」就说完了全部野心）；带说明书的手开始说「你该怎么用我」（配额、流程序、许可）。这一步的驱动力是-token 经济学：工具描述同样常驻路由上下文，写不清何时用，模型要么滥用要么不用——**工具作者被上下文经济学逼着学会了 Skill 的文体**。 **第二次移动：脑学会点名借手。** deep-research 的描述写「fan-out web searches, fetch sources」——它不自带抓取通道，借宿主的 WebSearch（09-05 期拆解存档确认其材料来源即宿主工具）；claude-api 把「代码 import 了哪个 SDK」写成 TRIGGER 条件，等于**把「手」的动作语法解析成了路由信号**。脑不造手，但脑的描述里写满了手的坐标。 而 open-seo-mcp-skills 卡在缝合位的原因也就清楚了：它把两界的词都写进了名字，却没把两界的合同写进描述——手清单（四个 SEO 动作）有了，脑条款（什么时候触发审计、数据源可信度怎么仲裁、配额怎么花）缺席。它的近两印冻结（514→516）与这个缺口互为注脚：**市场不惩罚缝合，市场惩罚缝合了却不说清缝合协议**※。对照 sepia 的纯脑路线（2251 星、77+ 宿主兼容声明），两件并排恰好证明脑与手都可以卖到两千星以上，卖不动的是含混。 ## 六、给作者的分工判定表 光谱不止用来观察，用来选型。三个判定问题，按序自答： 1. **能力在模型之外吗？**（需要碰浏览器、调试器、私有 API、外部数据）——是，往手侧走，MCP server 是正解，参考 x64dbg-mcp-server 的杠杆率：把成熟工具暴露出去，一个功能都不用自己实现。 2. **判断可以复用吗？**（什么时候做、按什么标准、错了怎么拦）——是，往脑侧走，SKILL.md 是正解，参考 sepia：纯提示词，判断力即护城河。 3. **两问都是吗？**——那就缝合，但把合同写出来：描述前半句写脑条款（何时触发），后半句写手清单（能调什么），名字里两界各占一段，像 open-seo-mcp-skills 那样——只是要补上它缺的那半句。**缝合件的名字证明两界可以通婚，缝合件的描述决定婚姻幸不幸福。** ## 安装与使用 ```bash # 市场端缝合件（本期主拆，装前先读 README 核对数据源与 API 配额※） npx skills add Ryze-AI-Adgent/open-seo-mcp-skills # 市场端纯手派参照 npx skills add duty1g/x64dbg-mcp-server # 需 Windows + x64dbg + MCP 宿主三重前置（09-04 存档口径） # 官方脑侧范本（教人造手的脑，自带验收环节，09-03 期已逐段拆解） npx skills add anthropics/skills # mcp-builder 随官方示例库分发 # 装机在册 MCP 三件（本会话注册表可见，正文未读※，自然语言触发） # "把这份 Word 转成 PDF" → office-mcp（通道直连式） # "帮我调一下 MCP 服务器配置" → mcp-cli（桥接器式） # "拉一下这个库的 API 文档" → context-hub-get-api-docs（管线名式） ``` 使用纪律一条：缝合件的验收单位是**链路**不是单步——SEO 件的正确试法是给一个真实站点跑完「关键词→审计→解读」全链，看脑条款（何时建议下一步）是否真的存在；只测手清单（能不能拉数据）等于没测它比纯 MCP server 多出来的那一半。 ## 推荐排行榜 - **本期最值得深读**：open-seo-mcp-skills（3.35）——分数不是最高，但它是「缝合协议该怎么写」的反面教材兼唯一活体标本，做混合架构的作者都该读一遍它的描述缺了什么。 - **纯手派标杆**：x64dbg-mcp-server（3.60，存档分）——杠杆率天花板，把十年成熟工具一行不改接入 Agent 世界。 - **文体进化最快**：context7 ／ playwright（不评星）——配额、流程、许可三类纪律进 schema 的三个一手证据，工具描述写作的隐性教科书。 - **命名学最省**：context-hub-get-api-docs——管线名定律跨协议复现，六个词没一个浪费。 - **最被低估的岗位**：mcp-cli——MCP 生态自己也需要 Skill 层照顾，这个空位目前只有一个隐形件在看守※。 - **离场判例**：sepia 路线（纯脑）与官方格式四件套（脑借宿主 Bash 之手）证明——**不缝合成不了输家，缝合了不说清才会**。 ## 参考来源 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。