Server Instructions：为 LLM 提供服务器的使用手册

我们许多人仍在探索 MCP 的各个角落，学习如何最好地使用协议的构建块来增强智能体和应用程序。有些功能，如 Prompts，在 MCP 生态系统中经常被实现和使用。其他功能可能看起来有些晦涩，但对智能体与 MCP 服务器交互的能力有很大影响。Server instructions 属于后者。

问题背景

想象您是一个大语言模型（LLM），刚刚收到了来自数据库服务器、文件系统服务器和通知服务器的工具集合来完成一个任务。它们可能已经被仔细预选，或者可能更像车库工作台上的样子——一堆最近使用的工具。

现在假设数据库服务器的开发者对如何最好地使用他们的工具有先验知识或偏好，以及有关驱动它们的基础系统的更多背景信息。

一些示例包括：

• “始终使用 validate_schema → create_backup → migrate_schema 进行安全的数据库迁移”
• “使用 export_data 工具时，需要文件系统服务器的 write_file 工具来存储本地副本”
• “数据库连接工具限制为每分钟 10 个请求”
• “如果 create_backup 失败，在尝试发送警报之前检查通知服务器是否已连接”
• “仅在支持启发式询问时使用 request_preferences 来询问用户设置。否则，回退到使用默认配置”

现在我们的问题变成了：分享这些上下文知识的最有效方式是什么？

解决方案

一种解决方案可能是在服务器提供的每个工具描述或提示中包含额外信息。然而，回到物理工具的类比：只有足够的空间来描述它们时，您才能依赖"标记"每个工具。模型的上下文窗口是有限的——您只能将那么多信息放入该空间。

或者，依赖提示来提供通用指令意味着：

• 提示总是需要由用户选择，并且
• 指令更容易在其他消息的混乱中丢失。

这就是 server instructions 的用武之地。Server instructions 为服务器提供了一种注入 LLM 应始终阅读的信息的方式，以了解如何使用服务器——独立于各个提示、工具或消息。

实现差异说明

因为服务器指令可能会被注入到系统提示中，所以应该谨慎和勤奋地编写它们。没有指令比糟糕的指令更好。

此外，MCP 宿主使用服务器指令的确切方式取决于实现者，因此不能保证它们总是被注入到系统提示中。

真实示例：优化 GitHub PR 审查

我使用官方 GitHub MCP 服务器 测试了服务器指令，看看它们是否能改进模型处理复杂工作流的方式。

问题：详细的 Pull Request 审查

我认为指令可能有帮助的一个常见用例是要求 LLM “审查 pull request #123”。如果没有更多指导，模型可能会决定过度简化并使用 create_and_submit_pull_request_review 工具在单个注释中添加所有审查反馈。

解决方案：工作流感知指令

我在 GitHub MCP 服务器中测试的一个解决方案是基于启用的工具集添加指令：

func GenerateInstructions(enabledToolsets []string) string {
    var instructions []string

    // 通用上下文管理 - 始终存在
    baseInstruction := "GitHub API 响应可能会溢出上下文窗口。策略：1) 始终尽可能优先使用 'search_*' 工具而非 'list_*' 工具，2) 分批处理 5-10 项的大数据集，3) 对于摘要任务，首先获取最少数据，然后深入具体细节。"

    // 仅加载已启用工具集的指令
    if contains(enabledToolsets, "pull_requests") {
        instructions = append(instructions, "PR 审查工作流：对于具有特定行注释的复杂审查，始终使用 'create_pending_pull_request_review' → 'add_comment_to_pending_review' → 'submit_pending_pull_request_review'。")
    }

    return strings.Join(append([]string{baseInstruction}, instructions...), " ")
}

衡量有效性：定量结果

对于此会话样本，我得到以下结果：

这些结果表明，虽然有些模型自然地倾向于最佳模式，但其他模型从明确指导中受益匪浅。

实施服务器指令：给服务器开发者的一般建议

良好指令的一个关键是关注工具和资源没有传达的内容：

1. 捕获跨功能关系

{
  "instructions": "在任何 'fetch_*' 工具之前始终调用 'authenticate'。'cache_clear' 工具会使所有 'fetch_*' 结果无效。"
}

2. 记录操作模式

{
  "instructions": "为了获得最佳性能：1) 对多个项目使用 'batch_fetch'，2) 在批量操作之前检查 'rate_limit_status'，3) 结果缓存 5 分钟。"
}

3. 指定约束和限制

{
  "instructions": "文件操作限制在工作区目录。超过 10MB 的二进制文件将被拒绝。速率限制：所有工具每分钟 100 个请求。"
}

4. 编写模型无关的指令

保持指令的事实性和功能性，而不是假设特定的模型行为。

应避免的反模式

不要重复工具描述：

// 坏 - 重复了 tool.description 中的内容
"instructions": "搜索工具搜索文件。读取工具读取文件。"

// 好 - 添加关系上下文
"instructions": "在 'read' 之前使用 'search' 来验证文件路径。搜索结果在 10 分钟后过期。"

不要包含营销或优越性声明：

// 坏
"instructions": "这是满足您所有需求的最佳服务器！优于其他服务器！"

// 好
"instructions": "专用于 Python AST 分析。不适合二进制文件处理。"

不要写手册：

// 坏 - 太长和太详细
"instructions": "此服务器提供...的全面功能 [500 字]"

// 好 - 简洁和可操作
"instructions": "GitHub 集成服务器。工作流：1) 'auth_github'，2) 'list_repos'，3) 'clone_repo'。"

服务器指令不能做的事情

• 保证特定行为：与您给 LLM 的任何文本一样，您的指令不会总是以相同的方式被遵循
• 考虑次优工具设计：工具描述仍然会在 LLM 需要采取行动时决定它们如何使用您的服务器的成败
• 改变模型个性或行为：服务器指令用于解释您的工具，而不是用于修改模型通常如何响应或行为

给客户端实现者的说明

如果您正在构建支持服务器指令的 MCP 客户端，我们建议您向用户公开指令，并提供关于服务器向上下文注入内容的透明度。

当前支持的宿主应用程序

有关支持服务器指令的宿主应用程序的完整列表，请参阅 MCP 文档中的 客户端 页面。

有关服务器指令的实际演示，您可以使用 Everything 参考服务器。

总结

清晰和可操作的服务器指令是 MCP 工具包中的关键工具，提供了一种简单而有效的方式来增强 LLM 与服务器交互的方式。我们鼓励您在我们的讨论中分享您的示例、见解和问题。

资源

• MCP 文档: Server Instructions 规范
• GitHub MCP 服务器: github.com/github/github-mcp-server
• Everything 参考服务器: modelcontextprotocol/servers

致谢

这篇博客文章的部分内容来源于与 MCP 社区、贡献者和维护者的讨论。