先交代对象档案。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 的在册件至少三件：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，只要交付物具体，命名法就通用——这暗示两界的命名学底层是同一套，为第五节的合流论提前埋了证据。
本期最重要的材料不在市场，在本会话挂载的 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 字符回答什么时候用我」，正在被工具作者无师自通地复用。
把所有样本摆到一根轴上，生态的分工结构就显形了：
flowchart LR
subgraph HAND["纯手 · 卖通道"]
H1["x64dbg-mcp-server<br/>暴露调试器 1886星"]
H2["office-mcp<br/>通道直连"]
end
subgraph HANDPLUS["手带说明书"]
M1["context7<br/>配额纪律写进指令"]
M2["playwright<br/>许可流程写进参数"]
end
subgraph SEAM["缝合件"]
S1["open-seo-mcp-skills 516星<br/>脑手同挂一个名字"]
S2["mcp-builder 官方<br/>教人造手的脑"]
end
subgraph BRAIN["脑借手"]
B1["deep-research<br/>借宿主 WebSearch 不造手"]
B2["claude-api<br/>把依赖写成触发器"]
end
subgraph PURE["纯脑 · 卖判断"]
P1["sepia<br/>纯提示词 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+ 宿主兼容声明），两件并排恰好证明脑与手都可以卖到两千星以上，卖不动的是含混。
光谱不止用来观察，用来选型。三个判定问题，按序自答：
# 市场端缝合件（本期主拆，装前先读 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 多出来的那一半。
[!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 等场景全覆盖。