mcp-content-ops

一个让智能体处理 CMS 内容的 MCP 服务器。工具本身很无趣——搜索、读取、创建草稿、设置字段、发布。真正需要思考的是在这些操作运行之前发生的事情。

我们看过的大多数内容 MCP 服务器都是把 API 客户端和凭据交给模型，凭据拥有集成账户碰巧拥有的任何权限，而在 CMS 中这通常意味着全部权限。演示时一切正常。然后有人让智能体"整理一下产品页面"，它就发布了四十个草稿，因为系统中没有任何东西说它不能这样做。

作用域控制

四道关卡，按顺序执行，而且都不在工具模式（tool schema）中：

1. 参数验证，对照已发布的模式进行。未知属性会被拒绝而不是丢弃——模型发明了一个参数说明它误解了工具，而静默丢弃会掩盖这一点。

2. 默认拒绝。 除非配置开启，否则写入操作被禁用。Policy 中没有任何地方存在宽松的默认值。

3. 类型和字段白名单。 一个类型可读并不意味着它可写，一个类型可写也并不意味着它上面的每个字段都可写。

4. 结构化审计每次调用，无论允许还是拒绝，都记录原因。

调用所依据的类型来自存储的条目，而不是来自参数。让调用者断言它正在编辑的内容是什么类型，就等于让调用者选择应用哪个策略。

被拒绝的调用会作为正常的工具结果返回，并设置 isError，而不是 JSON-RPC 错误。模型应该看到被拒绝的原因并做出调整；协议错误意味着客户端出了问题，那是另一回事。

Related MCP server: ToolBridge

运行

pip install -e ".[dev]"
python -m content_ops.server policy.example.json
pytest -q

它背后的 CMS 是 cms.py 中的一个内存存根——四个方法，把它换成你的内容 API 即可。

它不做什么

没有删除工具，这是故意的。没有资源或提示词，只有工具。没有认证：这是一个 stdio 服务器，信任边界是启动它的进程。模式验证器只覆盖我们自己的工具模式所使用的子集，而不是整个 JSON Schema。

为什么不用 SDK

MCP Python SDK 很好，对于更大的服务器来说它是正确的选择。但这个只实现了 stdio 上的三个方法，而且线格式足够小，以至于依赖一个目前像 SDK 那样快速迭代的依赖才是更大的风险。