MCP 这块我一开始也绕了不少弯路。后来我慢慢定下来一个比较稳的思路:MCP Server 负责把能力暴露出来,Skill 负责告诉 OpenClaw 什么时候该用、能用到什么边界。
这样做的好处是清楚。出了问题你知道该查 server、查配置,还是查提示词,不会全都搅在一起。
我的理解是:MCP Server 负责“能做什么”,Skill 负责“什么时候做、做到哪儿为止”。
一、先把结构想清楚
MCP Server:提供真实能力,比如文件系统、接口调试、知识库读取。
Skill:把触发场景、调用顺序和输出格式固定下来。
工作流里先别追求花哨,先让一条最小链路跑通。
二、我自己会先把 MCP Server 单独跑起来
{
"mcpServers": {
"docs-fs": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/srv/docs"]
}
}
}如果你之前已经在 Cherry Studio、Cline 或 VS Code 里配过 MCP,大多数情况下上面这类 command 和 args 可以直接复用。别重复造轮子。
三、再用一个 Skill 把调用边界收住
---
name: docs-reader
description: 读取本地部署文档和接口说明
metadata:
{ "openclaw": { "emoji": "📚", "requires": { "anyBins": ["npx", "uvx"] } } }
---
当用户询问部署步骤、接口字段、运行手册时:
1. 优先读取 docs-fs 暴露的文档目录。
2. 只在 /srv/docs 范围内检索,不越目录。
3. 输出时先列命中的文件,再给结论和建议。这里 Skill 的价值不是替代 MCP,而是把“何时触发、读哪儿、怎么输出”定死。这样你后面做自动化或者做团队复用时会稳很多。
我一般不会一上来就全量接多套 Server,先把一个本地目录型能力跑通再扩。
四、第一次调试,提示词尽量写得明确一点
请用 docs-reader 这个 skill 读取 /srv/docs 里的发布说明,
帮我整理 payment 服务的部署步骤、依赖项和回滚方法。排查阶段我很少依赖“自然触发”,而是直接把 Skill 名和目标说清楚。等这条链路稳定了,再慢慢放宽提示词。
五、如果接不通,我会优先查这三类问题
| 现象 | 优先排查点 | 处理建议 |
|---|---|---|
MCP Server 根本起不来 | command / args | 先在终端单独跑一遍命令,别直接把问题甩给 OpenClaw。 |
Server 起了但读不到东西 | 目录范围和权限 | 文件系统类 Server 最容易卡在路径范围,确认是不是指到了空目录。 |
能调用但回答不稳定 | Skill 指令不够清楚 | 把检索范围、输出顺序和禁止操作写进 Skill,本身会稳定很多。 |











还没有评论,来说两句吧...