content-knowledge-mcp

一个 MCP 服务器，让内容智能体能够访问公司的编辑知识：品牌规则、视觉模板目录，以及过往帖子的效果数据。这些知识以纯 Markdown 文件形式存放在公司自己的目录里，服务器只负责把它们暴露给客户端。

这是我关于 AI 智能体与工作流自动化的 BA 论文的技术核心。此仓库里是通用引擎，并附了一套虚构公司作为示例知识。

为什么不用向量数据库

最直观的做法是把知识做嵌入后再按相似度检索。这个服务器刻意没有这样做，原因有两个。

在这样的规模下，对整理好的文件做结构化检索更占优。 一家公司的编辑规则是几十个块，而不是几万个块。把它们切分成块再用余弦相似度检索，会增加一个索引环节、一个需要保持同步的存储，外加一类很难排查的故障，而且换来的召回率本来就通过词汇已经拿到了。

每条规则都带 ID，这正是关键。 规则有 R1、R17、R905；模板有 T901、T905；发布记录有 L1。智能体被要求引用它实际使用的 ID。这会让每个生成结论变成可被秒级审计的对象：审查者看到 rules_used: ["R920", "R903"]，就能精确知道这篇帖子来源于哪些规则。嵌入得到的是一段文本，不是一个可复查的论证。当目标是让人的把关真正可用时，可审计比花哨更好。

这条路径的代价也值得说明：检索是措辞层的，如果一条查询没有任何词与某条规则重合，就不会命中该规则。此时服务器返回 NO_MATCH，而不是装作命中——这正是评测用例要检查的行为。

Related MCP server: mcp-guide

架构

  Claude Desktop / Claude Code ──stdio──┐
                                        ├──▶ content-knowledge-mcp ──▶ KNOWLEDGE_PATH/
  n8n MCP Client Tool ──────────HTTP────┘         (3 tools)              guidelines/*.md   R# rules, L# launch records
       (host.docker.internal:8765)                                       templates/catalog.md   T# catalog
                                                                         past-posts/*.md        past posts and outcomes

三个工具、一层传输、完全无状态：

服务器自身不持有内容。把 KNOWLEDGE_PATH 指向另一个文件夹，它服务于另一家公司——这正是这份代码可在不改动的情况下公之于众的原因。

快速开始

git clone https://github.com/alessandro-martelli/content-knowledge-mcp
cd content-knowledge-mcp
python3 -m venv .venv && .venv/bin/pip install fastmcp

# run the twelve checks against the example knowledge
KNOWLEDGE_PATH=examples/knowledge .venv/bin/python smoke_test.py

# stdio, for Claude Desktop or Claude Code
KNOWLEDGE_PATH=examples/knowledge .venv/bin/python server.py

# HTTP on :8765, for the n8n MCP Client Tool
KNOWLEDGE_PATH=examples/knowledge .venv/bin/python server.py --http

examples/knowledge/ 下的知识全部是虚构的：一个虚拟的设计学校，包含规则、发布记录、模板目录，以及三条过往帖子。它存在的意义是让仓库对任何人都可运行、让测试有可调用的真实对象。

评估

冒烟测试：12/12。 每条用例都通过真实的 fastmcp.Client 走一遍，不走内部函数，因此工具注册或传输层的风险会直接暴露在这里。

智能体级协议：8 个场景，其中 5 个是对抗性的（规则互相冲突、请求越界、工具不可用、没有匹配模板、输入含糊不清）。2026 年 8 月针对两个智能体的 prompt 各跑了一遍：8 个中通过 6 个；所有输出首次都是合法 JSON；两个失败集中在测试夹具自身，且不是智能体的缺陷。两者都记录在 eval/test-log.md 中，并附有修复方案。日志就是不淡化的样子保留：一套只报通过的测试套件，本身没有任何考察力。

局限性

• 搜索是词法匹配，并按词频计算分数；它无法理解同义词，查询的语言没有出现规则的措辞时，就找不到它。

• 知识农布局固定（guidelines/、templates/catalog.md、past-posts/），且 catalog 路径硬编码。

• 没有写路径，也没有缓存：每次调用都会读一遍磁盘文件。这种体量可以接受，但到一万条以上就不行了。

• 评测中剩余两个已知缺陷在目前代码中还没有修补：rules_used 还不能引用 L#，而计划 schema 无法表达一个“渠道未知”的行。

许可

MIT，见 LICENSE。