把六个站的资产全塞进一个 MCP 之后最近大半个月的 AI 编码体验确实有点回到应该是什么样的意思。背景是这么回事我手上长期维护着六个内容站点有纯静态博客、有文档站、还有一个带商品目录的展示型站点另外两个是定期更新活动页的小站。以前做任何跨站改动基本流程都是开浏览器逐站登录后台、导出内容、整理成 Markdown 或 CSV、再喂给 Claude 或 Cursor 去做分析。一次两次能忍次数多了就发现这完全是反人类操作。后来我花了几个晚上把六个站的内容全部索引进了一个自定义的 MCP server统一暴露给 Claude Code、Cursor、Cherry Studio 这些支持 MCP 的客户端。现在我在任何一个 AI 工具里都能直接让模型去查某个站点的某篇文章、对比两侧文档差异、统计商品数据变化甚至按需触发出站内容更新。这篇文章就是把搭建过程和踩坑记录整理出来给想走同样路子的朋友做个参考。1. 为什么要做这件事MCP 到底解决了什么1.1 内容分散带来的真实痛点六个站看似独立其实内容之间互相引用得很厉害。博客里写产品功能产品站要同步参数文档站要更新教程活动页要引用博客素材。以前内容变一次要同步的地方可能有三四处。我试过不少工具来解决这个问题比如统一出口的 CMS、RSS 订阅再处理、甚至写过定时脚本把各站内容抓下来存成 SQLite 再人工查询。但这些方案都有一个共同毛病它们都停留在我能查到数据的层面没有真正进入AI 能自己用数据的层面。举个例子我需要让 Cursor 在我写新文章时引用老文章做链接。传统做法是我把老文章链接复制进对话或者让 Cursor 读某个 sitemap。每次只读一个 URL模型能看到的上下文极其有限。真要跨站找素材只能手动开多个标签页复制粘贴。这几年的 AI 工具确实能写了但在主动触达数据这件事上一直缺一个标准接口MCP 正好补上了这个环节。1.2 MCP 协议为什么刚好能接住这个需求MCP全称 Model Context Protocol是 Anthropic 在 2024 年底开源的一种标准化协议目标很简单让 AI 应用以统一的方式连接外部数据和工具。你可以把它理解成一个 USB 接口——以前每家设备都用自己的充电口现在大家约定一个通用协议插上就能用。协议的核心概念主要有三块resources、prompts、tools。resources 是只读的数据源比如文件内容、数据库查询结果prompts 是预设的提示模板让模型在特定场景下调用tools 是 AI 可以主动调用的函数比如查询某个接口、写入某个文件。我需要跨站查内容、比数据本质上就是做一堆只读/写入工具让模型能主动发起调用而不是等我复制粘贴。还有一个关键点MCP 是双向的。AI 客户端发起请求MCP server 响应数据并返回结果模型拿到结果后再决定下一步。这个让模型自己决定要不要查数据的能力才是它比先查好再贴给 AI高效得多的根本原因。我不需要预先知道这次对话要查几个站模型会根据用户问题自动选择调用哪个站点的检索工具。1.3 六合一的方案选型横切还是分装刚开始我面临一个选择是做一个总 MCP内部集成六个站还是每站一个 MCP server、客户端配六个两者的差异在运维成本和使用体验上差别很大。每站一个 server听起来更干净但客户端要配置六次工具命名跨站搜索时也会很混乱——比如六个站都有search_content这个 toolAI 不知道该调哪个。反之一个 server 聚合六个站工具签名可以显式带site_id参数或独立命名空间AI 的选择路径非常清晰配置也只做一次。我最终选了单 server 方案理由有三条。第一本地维护负担轻只跑一个进程第二工具命名可以统一规划建出跨站检索能力第三后续要加向量检索、全文索引只需在这个 server 内部做升级不用动客户端配置。副作用也有就是单点故障——但 MCP server 本身是本地进程挂了重启就好影响面可控。2. 六个站的内容建模与工具设计2.1 先摸清六站的资产类型动手前我先花了一天全面盘点内容建了一张资产清单这里直接列出来供参考站点内容类型数量级更新频率主要用途技术博客Markdown 文章300每周文章写作、历史素材引用文档站Markdown/HTML 页面200每周说明书、版本更新记录产品目录JSON/CSV 结构化数据150每周商品查询、参数对比活动页站JSON 配置HTML 模板50每周新活动上线、老活动修改图片素材站元数据 JSON500每月图片来源、版权信息查询站点统计页面 PV/UV 数据90天滚动每天流量分析、数据导出事实上真正需要高频访问的是前三个博客、文档、产品数据。活动页和图片素材站属于低频但偶尔要查站点统计则是每天变化做进 MCP 之后能省掉不少临时报表工作。2.2 统一检索层给每个站一个命名空间六个站的数据格式相差很大博客是 Markdown 文件文档站有 HTML 和 MDX产品目录是 JSON统计是数据库表。所以我不可能用一个工具吃遍所有格式必须做统一的数据抽象。最后的做法是在 MCP server 内部给每站分配一个命名空间数据统一落进 SQLite 和文件系统按site_id区分。每个站点对外暴露一组同构的工具只是工具内部查询的数据源不同。比如search_site_content(site_id, query, limit)在所有站点内容里做全文搜索get_page_details(site_id, page_id)获取单页详情list_site_pages(site_id, offset, limit)列出站点页面列表get_product_info(product_id)产品数据专用接口get_site_stats(site_id, date_range)站点统计查询这样模型在对话里收到查博客里关于 MCP 的文章这类指令时能自动推断出site_idblog再走search_site_content就好。工具名虽然是统一的但参数带着明确的语义AI 不会混淆。2.3 工具的返回格式设计这一块容易翻车。我最初把所有工具都设计成返回完整内容结果 Claude 在一次对话里读取了三四篇文章后上下文窗口就被塞满了。之后改了策略所有列表类工具只返回标题、路径、摘要、更新时间这四要素详情类工具返回正文且支持max_length截断。摘要字段不是简单的前 N 个字而是用脚本提取每个页面的首段标题关键词保证模型拿到列表后能先判断哪个页面值得展开读再按需调用详情。这种做法非常关键直接决定了模型在跨站查询时是用 5 次工具调用解决问题还是被上百个字符的长文本淹没。另外对于产品目录这类结构化数据工具返回统一转成 JSON字段名用英文id、name、price、category、updated_at避免模型在中文字段名和英文提示词之间来回翻译。3. 搭建一个 MCP server 的实际过程3.1 技术栈选择Python 还是 TypeScript主流的 MCP SDK 提供 Python、TypeScript 两套选择取决于你已有的内容处理链路。我这边内容清洗、索引、向量化脚本本来就用 Python 写的所以选用 Python SDK 顺理成章。如果你是前端为主的工作流或者要接 Node 生态的数据源TypeScript SDK 会更顺手。安装 MCP SDK 的命令也很简单pip install mcp # 或者 TypeScript 项目 npm install modelcontextprotocol/sdk构建 server 时核心就是注册工具、定义参数 schema、实现处理逻辑。我用的是 FastMCP 类启动后会自动创建 stdio 输出通道支持客户端通过标准输入输出通信。值得一提的一点是MCP 新版已经支持 Streamable HTTP 传输但我个人认为本地开发用 stdio 最省心不需要处理端口和 CORS 问题客户端配置也很简单。3.2 内容索引与预处理这一步是体力活也是整个系统的地基。我的数据来源有三种文件系统、数据库、线上接口。文件系统的处理最简单直接遍历目录读文件数据库用 SQL 查询导出成 JSON线上接口则写脚本定时拉取。不管哪种来源最终我都统一转成三份数据contentMarkdown/HTML 原文、metadata标题、路径、日期、标签、search_index做过分词和摘要的纯文本索引。一个心得必须分享数据清洗远比建 server 费时间。文档站的 HTML 里有一堆导航栏、侧边栏、页面头尾的公共部分如果不清理AI 每次读到正文都会被干扰。我写了一个extract_main_content函数基于几个常见 HTML 结构规则做正文抽取清洗后的正文再推给 MCP。SQLite 是我存储的主力。因为数据总量不大六个站加起来也就几百 MBSQLite 完全够用还能用 FTS5 做全文搜索。启 FTS5 很简单建表、建索引、插入数据然后查询就能用MATCH语法CREATE VIRTUAL TABLE pages_fts USING fts5(site_id, page_id, title, body, content); INSERT INTO pages_fts(site_id, page_id, title, body) SELECT site_id, page_id, title, body FROM pages; SELECT site_id, page_id, title FROM pages_fts WHERE pages_fts MATCH MCP ORDER BY rank LIMIT 10;注意content这个参数很重要它表示外部内容表避免 FTS 索引表和数据表重复存储节省了一半磁盘空间。3.3 核心 server 代码骨架下面是我 server 里最核心的一段逻辑删减掉业务细节后暴露工具的写法大概是这样的from mcp.server.fastmcp import FastMCP mcp FastMCP(mysixsites-server) mcp.tool() async def search_site_content(site_id: str, query: str, limit: int 5) - list[dict]: 在指定站点中搜索内容返回标题列表、路径和摘要。 rows db.execute( SELECT page_id, title, path, summary FROM pages_fts WHERE site_id ? AND pages_fts MATCH ? ORDER BY rank LIMIT ? , (site_id, query, limit), ).fetchall() return [{page_id: r[0], title: r[1], path: r[2], summary: r[3]} for r in rows] mcp.tool() async def get_page_details(site_id: str, page_id: str, max_length: int 2000) - dict: 获取页面详情返回正文内容。 row db.execute( SELECT title, body, updated_at FROM pages WHERE site_id ? AND page_id ?, (site_id, page_id), ).fetchone() return { title: row[0], body: row[1][:max_length] if max_length 0 else row[1], updated_at: row[2], } if __name__ __main__: mcp.run(transportstdio)mcp.tool()装饰器会自动根据函数签名生成 JSON SchemaAI 客户端读取到工具描述后就知道在什么场景下调用哪个函数。这个描述信息写得好不好直接决定了模型调工具时的命中率后面细说。3.4 配置客户端Claude Desktop、Cursor、Cherry Studioserver 跑起来之后下一步就是把客户端指向它。不同的客户端配置方式略有差异但核心都是指定command和args。Claude Desktop 的配置在claude_desktop_config.jsonWindows 路径一般是%APPDATA%\Claude\claude_desktop_config.jsonmacOS 是~/Library/Application Support/Claude/claude_desktop_config.json编辑成如下格式{ mcpServers: { mysixsites: { command: python, args: [/path/to/your/server.py], env: { DATABASE_PATH: /path/to/data.db } } } }Cursor 则是在项目设置里找到MCP Servers一项新增 server 时同样填command和args也可以直接在.cursor/mcp.json文件里配置。Cherry Studio 的入口不太一样它在应用界面上直接提供添加 MCP 服务器表单拉到底一般能在一个面板内完成。如果你和我一样有测试的需求npx mcp-inspector这个工具强烈推荐。它会开一个可视化面板你可以模拟客户端向 server 发请求查看每个工具是否正常返回、参数 schema 是否正确比反复改配置重启客户端效率高得多。4. 调试、权限与性能问题4.1 工具返回超时的排查思路MCP 本质上是本地进程间的通信理论延迟应该很低。但我在第一次集成时遇到过几次客户端等了十几秒才返回结果的情况。排查后发现问题不是出现在工具本身而是出现在启动时数据库连接和全文索引加载环节。解决方法有两个。一是把重量级的初始化动作挪到 server 启动阶段并且做条件加载不要每次调用工具时都重新初始化二是把耗时超过 3 秒的查询任务改成异步任务先返回查询中状态再用回调或轮询拿结果。对于我这种六站文本检索场景调整后单个查询基本都在几百毫秒内完成。还有一个容易忽略的地方如果你用了 Windows 下的 WSL路径映射可能会导致工具找不到文件。把路径统一改成绝对路径并在env里显式传入DATABASE_PATH能少踩很多坑。4.2 内容更新的冲突处理六个站的内容不是静态的每周都要更新。最初我偷懒每次更新都全量重建索引结果到了更新当天server 明显卡顿。后面改成了增量更新策略每个数据源文件记录自己的last_modifiedMCP server 启动时和定期调度时只扫描变化过的文件更新对应条目。对数据库来源的数据我在 SQL 查询里加了WHERE updated_at ?条件每次只拉增量数据。对线上接口则用ETag或If-Modified-Since做条件请求减少不快文件传输。顺带一个教训更新索引和供查询用的数据库表一定要分开。如果客户端正在查询时你去重建表SQLite 会给查询进程抛 database is locked 错误。我后来把所有更新操作都放到备用数据库上做完再切换主库引用或者用 SQLite 自身的 WAL 模式缓解锁竞争。4.3 索引膨胀与查询性能优化MCP server 跑了一周之后发现 FTS 索引文件比预期大了不少。原因是 FTS 索引默认会把 content 表中的所有文本都存一份副本即使我用外部内容模式也还是会保存索引词。如果某篇文章正文特别长索引体量也会上升。我的优化策略是三层。第一建立 FTS 索引前先做内容清理和摘要抽取把正文前 2000 字 全文分词结果分开存储索引字段只存摘要和标题第二查询时限制limit避免一次拉回大量无用的完整内容第三把最常用的几个查询如按分类筛选、按日期过滤从 FTS 改成普通 SQL 条件查询减少全文检索的开销。还有个非常实用的技巧所有工具参数都做类型校验。比如limit如果传的是字符串FastMCP 虽然会帮你转但有时会静默失败。我在工具函数开头加了简单的类型判断保证错误能尽早暴露。5. 实测效果与可以继续扩展的方向5.1 变成全站可对话之后的几个经典场景这次改造最满意的部分是原来需要我手动整理的素材现在只需一句话了。比如查一下产品目录里价格超过 500 的产品有哪些统计三个月博客访问量最高的 10 篇文章把文档站里所有提到 MCP 的段落找出来——这些对话过去至少要一小时现在十几秒搞定。我突然意识到一个更深层的变化以前 AI 能用的知识局限于模型参数和我在对话里喂的东西现在它多了一个挂在旁边的数据外挂可以直接按需调用而且这个外挂每天跟随我的数据更新。这个模式的想象空间比单纯做一个AI 聊天框要大得多。5.2 嵌入向量检索下一步计划目前的 FTS 全文搜索是关键词匹配同义词、语义相似度的处理能力有限。我正计划把六个站的内容全部跑一遍 embedding生成向量索引并增加一个semantic_search_site_content工具。这样的话用户说找一下讲模型上下文协议那篇文章即使文本里没有完整出现MCP这个词也能通过语义相似度找回来。技术选型上我倾向于用 SQLite 加sqlite-vec扩展做向量存储而不是引入单独的向量数据库毕竟数据量不大轻量方案足够。如果后续内容量上到百万级再迁移到专门向量库也不晚。5.3 多智能体协作与写入能力MCP 大多在读取层面让我获得收益但它的能力边界不止于此。下一步我想让 MCP server 增加写入能力比如通过工具生成新文章的草稿到某个站点或者把分析结果直接写入一个待发布的缓存文件。多智能体也是一个方向。我打算把 MCP server 作为所有 agent 的统一数据层每个 agent 只负责自己的业务逻辑比如内容更新 agent负责爬数据SEO 分析 agent负责做关键词发布 agent负责生成导出报告它们都通过 MCP 拿到同一份数据。不过这还是一个规划因为要保证多个 agent 并发访问同一份数据时不会互相覆盖写入锁和事务处理需要仔细设计。另外一个值得做的优化是给 server 增加一个批处理接口让 AI 在一次工具调用里传递多个查询参数而不是反复调同一个工具。比如用户问对比博客、文档、产品站三者关于 XX 功能的说法一次调用就能拿到三个站的数据上下文占用和时间都会明显下降。6. 踩坑与心得首先是工具描述信息一定写清楚。AI 是靠你的 docstring 决定调用哪个工具的描述写得模糊模型容易在多个工具间反复试错。我后来给每个工具都写了类似当用户询问某站点文章内容时使用这样明确的使用场景准确率明显提升。其次是不要把整个体系设计得太重。MCP server 本质是个轻量接口如果你把复杂的业务逻辑都堆在里面后续维护会非常痛苦。我的原则是server 只做数据的暴露和简单加工复杂的清洗入库逻辑全部放在外部脚本里这样 server 的责任边界很清晰。再一个心得是数据版本管理。现在的 server 引用了六站内容任何一站的改动都可能影响整体。我在 server 日志和外部脚本里都加了版本号每次更新数据后记录版本出了奇怪问题时第一时间能还原到上一个版本。最后如果你计划做的规模比我小或者只准备接一两个网站也完全不用照搬整套方案。MCP 的好处之一就是渐进式采用你可以先只暴露一个搜索工具让 AI 能搜到你博客的内容跑顺之后再慢慢加其他站点。上手的关键是先跑通一个最小闭环不要让架构设计占了真正动手的时间。就我个人感受来说把六个站塞进同一个 MCP 更像是一次数据权限的转移——从我个人的手动调取变成了 AI 的按需使用。它没有改变内容本身却改变了 AI 和内容之间的距离。以后再有新的站点大概率也就是往同一个 MCP server 里加一个配置的事。