基于MCP协议构建透明可控的AI编程助手文档检索系统

1. 项目概述：为你的AI编程助手构建一个透明、可控的文档检索大脑

如果你和我一样，日常重度依赖 Cursor、Claude Code 这类“AI原生”的 IDE 来写代码，那你肯定遇到过这样的场景：当你向助手提问一个关于某个框架（比如 LangGraph）的具体问题时，它有时能给出精准的答案，有时却会“胡言乱语”，或者干脆说“我不了解这个库的最新信息”。这背后的原因，很大程度上取决于它背后那个神秘的“文档检索”机制。这些 IDE 通常会内置一些工具来读取像llms.txt这样的网站索引文件，以获取上下文。但这个过程对开发者来说是个黑盒——你不知道它读了哪些文档，怎么读的，甚至读没读对。

今天要聊的这个开源项目mcpdoc，就是来解决这个痛点的。它是一个基于Model Context Protocol (MCP)的文档服务器。简单说，它让你能完全掌控你的 AI 助手在回答问题时，到底去查阅哪些文档、如何查阅，并且整个过程对你完全透明、可审计。你可以把它想象成给你的 AI 编程助手外挂了一个“自定义知识库查询引擎”，而且这个引擎的每一次“翻书”动作，你都能看得一清二楚。

它的核心价值在于：将文档检索的主动权交还给开发者。通过配置你信任的llms.txt文件（比如官方发布的 LangChain、LangGraph 文档索引），mcpdoc会暴露出标准的 MCP 工具（主要是fetch_docs），让你的 Cursor、Windsurf 或 Claude Desktop 等应用在需要时，通过调用这些工具来获取精确的文档片段，而不是依赖其内部不透明的机制。这对于需要精准、可靠技术支持的开发者，尤其是那些在复杂框架（如 AI Agent 开发框架）上进行构建的工程师来说，是一个游戏规则的改变者。

2. 核心概念与工作原理深度解析

要玩转mcpdoc，我们需要先理解几个关键概念，这能帮你更好地理解它“为什么”要这么设计，以及如何最大化其效用。

2.1 llms.txt：AI 的“网站地图”

llms.txt不是一个新概念，但它是这个项目的基石。你可以把它理解为一个专门为大型语言模型（LLM）优化的、机器可读的“网站地图”或“文档索引”。传统的robots.txt告诉网络爬虫哪里不能去，而llms.txt则是主动告诉 AI 助手：“如果你想了解我，请重点看这些页面。”

一个典型的llms.txt文件内容非常简单，就是一系列 Markdown 文档的 URL 列表。例如，LangGraph Python 的llms.txt可能包含了其官方文档中所有核心概念、API 参考和教程的链接。当 AI 助手需要回答关于 LangGraph 的问题时，它理论上应该优先从这个列表指向的页面中寻找答案，因为这些页面被维护者认定为是最相关、最权威的。

然而，问题在于，不同的 IDE 和 AI 应用（Cursor, Windsurf, Claude Code）实现读取和利用llms.txt的机制各不相同，且通常不向用户开放。你无法确认它是否真的使用了你期望的文档源，也无法在它给出错误答案时进行排查。

2.2 Model Context Protocol (MCP)：工具调用的标准化协议

MCP 是 Anthropic 推出的一种开放协议，旨在标准化 AI 应用程序（客户端）与外部工具、数据源（服务器）之间的通信。你可以把它类比成 AI 世界的USB 协议或HTTP 协议——它定义了一套通用的“插口”和“数据格式”，让不同的“设备”（工具服务器）可以轻松地接入不同的“主机”（AI 应用）。

mcpdoc就是一个 MCP 服务器。它实现了 MCP 协议，对外提供两个核心工具：

1. list_doc_sources: 列出当前服务器配置的所有llms.txt源（比如“LangGraph Python”、“LangChain JS”）。
2. fetch_docs: 根据给定的 URL（必须属于已配置的llms.txt文件中的链接），抓取并返回该 URL 对应的 Markdown 文档内容。

当 Cursor 这样的 MCP 客户端配置了mcpdoc服务器后，它就可以通过 MCP 协议调用这些工具。这取代了其内置的、不透明的文档检索逻辑。

2.3 mcpdoc 的工作流与安全边界

mcpdoc的工作流程可以概括为以下几步，理解这个过程对后续配置和排错至关重要：

1. 初始化与源加载：启动mcpdoc时，你通过命令行参数或配置文件指定一个或多个llms.txt文件的 URL。服务器会立即抓取这些文件，解析出其中包含的所有文档链接。
2. 构建安全域白名单：这是mcpdoc一个非常重要的安全设计。它不会允许fetch_docs工具抓取任意互联网 URL。
   • 如果指定的是远程llms.txtURL（如https://langchain-ai.github.io/langgraph/llms.txt），mcpdoc会自动将该 URL 的域名（langchain-ai.github.io）加入允许列表。
   • 如果指定的是本地文件路径，则不会自动添加任何域名，你必须通过--allowed-domains参数显式指定。
   • 你始终可以通过--allowed-domains参数额外添加域名，或者使用*通配符允许所有域名（极度不推荐，存在安全风险）。
3. 工具暴露与等待调用：服务器启动后，通过 SSE (Server-Sent Events) 或 stdio 等传输方式，将list_doc_sources和fetch_docs工具暴露给连接的客户端。
4. 客户端（如 Cursor）的查询过程：
   • 用户提问：“LangGraph 中有哪些类型的内存？”
   • Cursor 的 AI 代理根据预设的规则（Rules），决定调用mcpdoc服务器的工具。
   • 它首先调用list_doc_sources了解可用的文档集。
   • 然后可能调用fetch_docs获取llms.txt文件本身的内容，分析其中哪些 URL 可能与问题相关。
   • 接着，针对分析出的相关 URL（例如关于内存管理的文档页），逐个调用fetch_docs获取具体内容。
   • 最后，AI 代理综合这些检索到的文档内容，生成最终答案。

整个过程中，在 Cursor 的 MCP 工具调用面板或 MCP Inspector 中，你可以清晰地看到每一次fetch_docs被调用的记录、传入的 URL 以及返回的文档内容片段。这种透明性，是调试 AI 回答准确性的强大武器。

注意：安全与可控是第一要务这个白名单机制至关重要。它确保了你的 AI 助手只能从你明确授权的、可信的域名获取文档，防止了潜在的安全风险，比如被诱导访问恶意或无关的网站。在配置时，请务必确认你添加的llms.txt来源是官方或可信的。

3. 从零开始：环境搭建与 mcpdoc 服务器部署

理论讲完，我们动手实操。我会带你走一遍完整的安装和本地测试流程，并解释每个步骤背后的考量。

3.1 安装 uv：现代 Python 项目的打包与运行利器

项目推荐使用uv来安装和运行。uv是一个用 Rust 编写的、极其快速的 Python 包管理器和项目运行器，可以看作是pip、pipenv、virtualenv等工具的超集。用它来管理 MCP 服务器这类工具依赖，能避免污染系统 Python 环境，并且安装速度飞快。

# 使用官方安装脚本安装 uv curl -LsSf https://astral.sh/uv/install.sh | sh

安装完成后，重启你的终端，或者执行source ~/.bashrc(或source ~/.zshrc) 来让uv命令生效。你可以通过uv --version来验证安装。

为什么选择 uv？对于像mcpdoc这样可能被全局安装和频繁调用的工具，uv的uvx命令特别方便。uvx可以直接从网络（如 PyPI）下载并运行一个 Python 工具包，而无需先进行pip install。它会在后台自动管理隔离的虚拟环境和依赖，对用户完全透明。这比用系统pip安装要干净和安全得多。

3.2 选择并验证你的 llms.txt 源

在启动服务器前，你需要决定让mcpdoc加载哪些文档。这里以 LangGraph 和 LangChain 的官方文档为例，它们都是高质量、持续更新的源。

你可以直接在浏览器中打开这些链接，查看llms.txt的内容，感受一下它是什么：

• LangGraph Python: https://langchain-ai.github.io/langgraph/llms.txt
• LangChain Python: https://python.langchain.com/llms.txt

你会看到它们就是一系列 Markdown 文件的 URL 列表。这些就是mcpdoc将要建立索引并允许查询的文档范围。

3.3 本地测试运行 mcpdoc 服务器

在将其配置到 IDE 之前，强烈建议先在本地独立运行和测试服务器，确保一切正常。

# 使用 uvx 运行 mcpdoc，指定两个 llms.txt 源，并使用 SSE 传输在本地端口 8082 启动 uvx --from mcpdoc mcpdoc \ --urls "LangGraph:https://langchain-ai.github.io/langgraph/llms.txt" \ --urls "LangChain:https://python.langchain.com/llms.txt" \ --transport sse \ --port 8082 \ --host localhost

参数拆解与注意事项：

• uvx --from mcpdoc mcpdoc: 使用uvx从 PyPI 的mcpdoc包中运行名为mcpdoc的命令。
• --urls “Name:URL”: 这是指定源的主要方式。你可以为每个源起一个别名（如 “LangGraph”），方便在工具调用列表中识别。别名是可选的，但建议加上。
• --transport sse: 指定使用 Server-Sent Events 协议进行通信。这在独立测试时非常有用，因为它允许我们通过 HTTP 访问服务器状态。
• --port 8082 --host localhost: 将服务器绑定到本地的 8082 端口。

运行命令后，如果成功，终端会显示服务器已启动，并监听在http://localhost:8082。访问这个地址，你可能会看到一个简单的状态页或提示（取决于 MCP 服务器的实现），确认服务正在运行。

保持这个终端窗口打开，服务器会一直运行直到你按下Ctrl+C。

3.4 使用 MCP Inspector 进行工具测试

MCP Inspector 是一个官方提供的调试工具，可以连接到任何 MCP 服务器，并可视化地测试其提供的工具。这是验证mcpdoc是否正常工作、理解其工具调用方式的最佳途径。

# 全局安装 MCP Inspector (需要 Node.js 环境) npx @modelcontextprotocol/inspector

运行后，Inspector 通常会打开一个浏览器窗口或给出一个连接地址。在 Inspector 的界面中，你需要输入刚才启动的mcpdoc服务器的 SSE 地址：http://localhost:8082/sse（注意，SSE 端点通常是/sse）。

连接成功后，你应该能在 Inspector 的 “Tools” 面板看到list_doc_sources和fetch_docs这两个工具。

1. 测试list_doc_sources：点击调用，它应该返回一个列表，包含你刚才配置的两个源及其名称。
2. 测试fetch_docs：调用fetch_docs工具。你需要从之前浏览过的llms.txt文件中复制一个具体的文档 URL（例如，LangGraph 内存管理相关的某个页面链接）作为参数传入。如果一切正常，工具会返回该 URL 对应的 Markdown 文档内容。

通过 Inspector 的测试，你不仅验证了服务器的功能性，也直观地看到了 MCP 工具调用的请求和响应格式，这对后续在 IDE 中编写调用规则（Rules）非常有帮助。

4. 集成到主流 AI IDE：配置详解与实战

本地测试通过后，就可以将它集成到你的日常开发环境中了。下面我将详细讲解在 Cursor、Windsurf、Claude Desktop 和 Claude Code 中的配置方法，并分享一些关键的实操心得。

4.1 集成到 Cursor：打造专属的 LangGraph 专家助手

Cursor 是目前对 MCP 支持最完善、体验最好的 IDE 之一。配置过程主要涉及两个文件：MCP 服务器配置和全局规则。

步骤一：配置 MCP 服务器

1. 打开 Cursor，进入Settings(快捷键Cmd+,on Mac)。
2. 找到MCP标签页。点击后，Cursor 会自动打开（或创建）MCP 配置文件~/.cursor/mcp.json。
3. 将以下配置粘贴到该文件中：

{ "mcpServers": { "langgraph-docs-mcp": { "command": "uvx", "args": [ "--from", "mcpdoc", "mcpdoc", "--urls", "LangGraph:https://langchain-ai.github.io/langgraph/llms.txt LangChain:https://python.langchain.com/llms.txt", "--transport", "stdio" ] } } }

配置解析与避坑点：

• ”langgraph-docs-mcp”: 这是你给这个服务器起的名字，会在 Cursor 的工具列表中显示。
• ”command”: “uvx”: 告诉 Cursor 使用uvx命令来启动服务器。
• ”args”: 这里的参数和之前本地测试时几乎一样，关键区别是--transport stdio。在 IDE 集成场景下，通常使用stdio（标准输入输出）进行通信，这比 SSE 更高效、更稳定。
• 重要：注意--urls参数后面，两个源被合并成了一个字符串，用空格分隔。这是 Cursor 配置的常见写法。确保整个字符串格式正确，特别是 URL 没有多余或缺失的引号。

保存文件后，返回 Cursor Settings 的 MCP 标签页，你应该能看到langgraph-docs-mcp服务器显示为已连接（绿色或已加载状态）。如果显示错误，请检查终端是否有错误输出（Cursor 可能会在后台尝试启动服务器并报错），最常见的问题是uv未安装或不在 PATH 中。

步骤二：设置全局规则 (Rules)

仅仅连接服务器还不够，你需要告诉 Cursor 的 AI 代理“什么时候”以及“如何”使用这个服务器。这通过 Cursor 的Rules功能实现。

1. 在 Cursor Settings 中，进入Rules标签页。
2. 在User Rules（用户全局规则）区域，添加如下规则：

for ANY question about LangGraph, use the langgraph-docs-mcp server to help answer -- + call list_doc_sources tool to get the available llms.txt file + call fetch_docs tool to read it + reflect on the urls in llms.txt + reflect on the input question + call fetch_docs on any urls relevant to the question + use this to answer the question

规则编写心法：这条规则是一个简单的“提示工程”。它指示 AI 代理：当遇到任何关于 LangGraph 的问题时，应该走一个标准的检索流程。reflect指令是让 AI 在“内心”思考一下，llms.txt里有哪些 URL，用户的问题可能和哪些 URL 相关。这比直接让它“去查资料”更结构化，成功率更高。

步骤三：实战测试

1. 在 Cursor 中，用Cmd+L(Mac) 打开聊天面板。
2. 确保右下角选择了agent模式（这是能使用工具的模式）。
3. 输入测试问题：what are types of memory in LangGraph?
4. 观察过程：在聊天界面或右侧的工具调用面板，你应该能看到 Cursor 依次调用list_doc_sources和多次fetch_docs的过程。最终，它给出的答案应该非常精准，并且引用了来自 LangGraph 官方文档的具体内容。

实操心得：规则需要迭代第一次写的规则可能不完美。如果发现 AI 没有正确调用工具，或者调用顺序不对，可以修改规则。例如，如果问题涉及多个库，你可以将规则扩展为for ANY question about LangGraph OR LangChain...。规则的本质是引导 AI 的工作流，需要根据实际效果进行微调。

4.2 集成到 Windsurf

Windsurf（原名 Codeium）的配置流程与 Cursor 高度相似。

1. 配置 MCP 服务器：在 Windsurf 中，使用Cmd+L打开 Cascade 命令面板，输入Configure MCP并执行，这会打开配置文件~/.codeium/windsurf/mcp_config.json。将上述与 Cursor 相同的 JSON 配置粘贴进去。
2. 设置全局规则：在 Windsurf Settings 中找到Rules / Global rules，粘贴与 Cursor 相同的规则文本。
3. 测试：同样，在聊天框中提问关于 LangGraph 的问题，观察工具调用和回答。

4.3 集成到 Claude Desktop 与 Claude Code

Anthropic 官方的 Claude 应用也支持 MCP，但配置方式和规则应用略有不同。

Claude Desktop 配置：

1. 打开 Claude Desktop 应用，进入Settings->Developer页面。
2. 这里会显示配置文件路径：~/Library/Application Support/Claude/claude_desktop_config.json(Mac) 或类似路径。
3. 编辑该文件，添加mcpServers配置段，内容与 Cursor 的配置一致。
4. 重启 Claude Desktop应用以使配置生效。

Claude Desktop 规则应用的特殊性：截至当前（基于项目文档提示），Claude Desktop 的图形界面可能不支持全局规则的直接配置。变通方法是，在每次提问时，将规则文本包裹在<rules>标签内，并放在问题前面或后面。例如：

<rules> for ANY question about LangGraph, use the langgraph-docs-mcp server to help answer -- + call list_doc_sources tool to get the available llms.txt file + call fetch_docs tool to read it + reflect on the urls in llms.txt + reflect on the input question + call fetch_docs on any urls relevant to the question </rules> 我的问题是：what are types of memory in LangGraph?

Claude Code 配置：Claude Code 是命令行工具，配置更直接。

1. 在终端中执行以下命令，将服务器配置添加到当前用户全局：

   claude mcp add-json langgraph-docs '{"type":"stdio","command":"uvx" ,"args":["--from", "mcpdoc", "mcpdoc", "--urls", "langgraph:https://langchain-ai.github.io/langgraph/llms.txt", "LangChain:https://python.langchain.com/llms.txt"]}' -s local

   这条命令会更新~/.claude.json配置文件。
2. 验证：在终端启动 Claude Code (claude)，然后输入/mcp命令，应该能看到已配置的langgraph-docs服务器及其工具。
3. 规则应用：与 Claude Desktop 类似，目前可能需要在提问时手动附加<rules>标签。

重要提示：Python 版本兼容性问题如果你在 Claude Desktop/Code 中遇到uvx或 Python 环境问题，可以在配置中显式指定 Python 解释器的路径。这是解决此类问题最有效的方法。

{ "mcpServers": { "langgraph-docs-mcp": { "command": "uvx", "args": [ "--python", "/usr/local/bin/python3", // 替换为你的 python 实际路径，可通过 `which python3` 查看 "--from", "mcpdoc", "mcpdoc", "--urls", "LangGraph:https://langchain-ai.github.io/langgraph/llms.txt", "--transport", "stdio" ] } } }

5. 高级配置与管理：灵活运用 mcpdoc

除了基本的命令行运行，mcpdoc提供了更灵活、更适合生产环境的配置方式。

5.1 使用配置文件管理文档源

当你的文档源很多，或者需要团队共享配置时，使用 YAML 或 JSON 配置文件是更佳选择。项目仓库中通常会有sample_config.yaml或sample_config.json示例。

YAML 配置示例 (my_docs_config.yaml):

- name: "LangGraph 核心指南" llms_txt: "https://langchain-ai.github.io/langgraph/llms.txt" - name: "LangChain Python 全文档" llms_txt: "https://python.langchain.com/llms.txt" - name: "内部项目文档" llms_txt: "file:///Users/yourname/docs/internal-llms.txt" # 支持本地文件

JSON 配置示例 (my_docs_config.json):

[ { "name": "LangGraph 核心指南", "llms_txt": "https://langchain-ai.github.io/langgraph/llms.txt" }, { "name": "LangChain Python 全文档", "llms_txt": "https://python.langchain.com/llms.txt" } ]

使用配置文件启动服务器：

# 使用 YAML 配置 mcpdoc --yaml my_docs_config.yaml --transport stdio # 使用 JSON 配置 mcpdoc --json my_docs_config.json --transport stdio

混合使用配置文件和命令行参数：你可以组合多种方式，这对于在基础配置上临时添加一两个源非常方便。

mcpdoc --yaml base_config.yaml --urls “临时API文档:https://api.example.com/v2/llms.txt”

5.2 关键命令行参数解析

• --follow-redirects: 默认情况下，HTTP 请求不跟随重定向。如果您的llms.txt或文档 URL 发生了重定向（如 HTTP 到 HTTPS），需要启用此选项。建议在配置未知源时先开启，确认最终地址后再决定是否关闭。
• --timeout SECONDS: 设置 HTTP 请求超时时间，默认为 10 秒。如果文档服务器响应慢，或者网络状况不佳，可以适当调高此值（如--timeout 30）。
• --allowed-domains: 这是安全核心参数。
  • --allowed-domains “*.example.com” “api.github.com”: 允许example.com的所有子域和api.github.com。
  • --allowed-domains “*”:允许所有域名。仅在你完全信任所有llms.txt内的链接，且仅在安全隔离环境中测试时使用。

一个包含所有可选参数的完整示例：

uvx --from mcpdoc mcpdoc \ --json my_config.json \ --follow-redirects \ --timeout 20 \ --allowed-domains “langchain-ai.github.io” “python.langchain.com” \ --transport stdio

5.3 以编程方式使用 mcpdoc

如果你是 Python 开发者，或者希望将mcpdoc的功能集成到自己的自动化脚本或应用中，可以直接调用其 Python API。

from mcpdoc.main import create_server import asyncio async def main(): # 1. 创建服务器实例 server = create_server( sources=[ { "name": "My Custom Docs", "llms_txt": "https://my-domain.com/docs/llms.txt", } ], follow_redirects=True, timeout=15.0, allowed_domains=["my-domain.com", "trusted-cdn.com"] # 编程方式设置白名单 ) # 2. 运行服务器（例如，集成到 FastAPI 等异步框架中） # 这里以 stdio 模式为例，实际上你可以适配不同的传输层 async with server.run(transport="stdio") as client: # 此时服务器已启动并等待客户端连接 # 你可以在这里执行其他逻辑，或者只是保持运行 await asyncio.Future() # 永久运行，直到被中断 if __name__ == "__main__": asyncio.run(main())

这种方式给予了最大的灵活性，你可以基于mcpdoc的核心功能，构建更复杂的文档检索服务，例如添加缓存层、权限验证、或者将多个llms.txt源合并处理后提供统一的工具接口。

6. 常见问题、排查技巧与最佳实践实录

在实际部署和使用mcpdoc的过程中，你可能会遇到一些问题。下面是我总结的一些常见坑点及其解决方案。

6.1 服务器启动失败与连接问题

问题现象	可能原因	排查步骤与解决方案
运行uvx命令报错，提示命令未找到或安装失败。	1.uv未正确安装或未加入 PATH。 2. 网络问题导致uvx无法从 PyPI 下载mcpdoc。	1. 在终端执行which uv确认安装。重新执行安装脚本或手动添加 PATH。 2. 尝试使用pip install mcpdoc全局安装，然后在命令中直接使用mcpdoc而非uvx --from mcpdoc mcpdoc。
Cursor/Windsurf 的 MCP 配置显示服务器连接失败（红色或错误状态）。	1. 配置文件 JSON 格式错误。 2.uvx或mcpdoc命令在 IDE 的上下文中执行失败（如环境变量不同）。 3.--transport stdio参数缺失或错误。	1. 使用 JSON 校验工具检查~/.cursor/mcp.json等文件格式。 2. 在终端中手动执行配置中的完整命令（如uvx --from mcpdoc mcpdoc --urls ... --transport stdio），看是否报错。根据错误信息解决（通常是 Python 依赖或网络问题）。 3.确保在 IDE 配置中使用--transport stdio，SSE 通常仅用于本地测试。
MCP Inspector 无法连接到http://localhost:8082/sse。	1. 本地测试的mcpdoc服务器未启动。 2. 端口被占用或--host参数不对。 3. Inspector 连接地址错误。	1. 确认运行mcpdoc的终端未关闭且无报错。 2. 尝试更换端口，如--port 8083。 3. 确认连接地址是http://localhost:端口号/sse。有些 MCP 服务器根路径可能就是 SSE 端点，可以试试http://localhost:8082/。

6.2 工具调用无响应或返回空内容

问题现象	可能原因	排查步骤与解决方案
在 IDE 中提问后，AI 没有调用任何工具，直接回答了（可能不准确）。	1.规则 (Rules) 未生效或未正确编写。这是最常见的原因。 2. AI 代理（Agent）模式未开启。	1.仔细检查规则语法：确保规则指向的服务器名称与配置中的mcpServerskey 完全一致（如langgraph-docs-mcp）。规则描述要清晰，如for ANY question about LangGraph。 2. 在 Cursor/Windsurf 中，确认聊天面板右下角选择了agent模式，而不是composer模式。
工具被调用了（能看到调用记录），但fetch_docs返回错误或空内容。	1.域名不在白名单内。 2. 目标 URL 无法访问（404，超时等）。 3.llms.txt文件格式不正确。	1.重点检查：如果使用本地llms.txt文件，必须通过--allowed-domains添加域名。使用 MCP Inspector 测试时，传入完整 URL 看具体错误信息。 2. 手动在浏览器中打开fetch_docs尝试调用的那个具体文档 URL，确认可访问。 3. 检查llms.txt文件，确保其内容是纯文本，每行一个有效的 URL。
Claude Desktop/Code 中工具需要手动批准，无法自动调用。	这是 Claude 应用当前的安全策略。工具调用需要用户手动点击“批准”。	目前没有自动批准的设置。这虽然降低了效率，但提高了安全性。在提问时，注意观察界面右下角的工具调用提示，及时点击批准。

6.3 性能优化与最佳实践

1. 为不同的项目配置不同的服务器：不要把所有文档源都塞进一个mcpdoc配置。例如，你可以创建一个langgraph-mcp专门服务 LangGraph 问题，另一个internal-api-mcp服务内部 API 文档。这样规则可以写得更精准，AI 也不会在无关的工具列表中困惑。
2. 使用本地缓存的llms.txt：对于内部文档或访问速度慢的源，可以将llms.txt文件下载到本地，然后使用file://协议指定路径。这可以加快服务器启动速度，并避免因网络问题导致源加载失败。

   mcpdoc --urls “内部文档:file:///path/to/local/llms.txt” --allowed-domains “internal.company.com”

3. 编写更精确的规则：基础的规则可能对复杂问题效果不佳。你可以编写更细致的规则，例如：

   If the user asks about “memory”, “state”, or “persistence” in the context of LangGraph, then: 1. Use the langgraph-docs-mcp server. 2. First, call list_doc_sources. 3. Then, fetch the llms.txt and look for URLs containing “memory” or “state”. 4. Fetch those specific docs and use them to answer.

4. 定期更新llms.txt源：官方文档会更新，llms.txt内容也会变。定期检查你配置的源是否仍然有效，或者是否有新的、更全面的llms.txt文件发布。
5. 结合 IDE 项目级配置：除了全局配置，一些 IDE（如 Cursor）也支持项目级的.cursor/mcp.json配置。你可以在项目根目录放置此文件，定义只与此项目相关的文档源（如该项目特定依赖库的文档），实现更精细化的管理。

通过mcpdoc，你将文档检索的模糊地带变成了一个清晰、可控、可审计的管道。它不仅仅是连接了一个文档源，更是为你与 AI 助手之间的协作引入了一种可预测、可调试的新范式。当你下次再疑惑“为什么 AI 会给出这个答案”时，你可以打开工具调用记录，像查看日志一样追溯它的“思考”过程，这种掌控感对于进行严肃开发的工程师来说，是无价的。