Skip to main content
  • 状态（Status）: Final
  • 类型（Type）: Standards Track
  • 创建（Created）: 2025-07-16
  • 作者（Author(s)）: kentcdodds
  • Issue: #986

​
摘要

模型上下文协议（MCP）目前缺乏工具名称的标准化格式，导致实现者和用户都面临不一致和混淆。本 SEP 为工具名称提出一个清晰、灵活的标准：工具名称应为 1–64 个字符、区分大小写，可以包含字母数字字符、下划线（_）、连字符（-）、点（.）和正斜杠（/）。这旨在最大化各 MCP 实现之间的兼容性、清晰度和互操作性，同时容纳广泛的命名约定。

​
动机

在没有规定的工具名称格式的情况下，各 MCP 实现采用了五花八门的命名约定，包括不同的分隔符、大小写和字符集。这种不一致可能导致混淆、工具调用出错，以及文档和自动化方面的困难。标准化允许的字符和长度将：
  • 使工具名称在各客户端之间可预测且可互操作。
  • 允许层级化和带命名空间的工具名称（例如使用 / 和 .）。
  • 同时支持人类可读的名称和机器生成的名称。
  • 避免可能阻断有效用例的不必要限制。

​
理由

社区讨论突显了工具命名需要灵活性。虽然某些约定（如小写短横线命名，lower-kebab-case）很常见，但许多工具和客户端使用大写、下划线、点和斜杠来做命名空间或提升清晰度。所提议的模式——允许 a-z、A-Z、0-9、_、-、. 和 /——基于主要客户端（例如 VS Code、Claude）所用的模式，并与编程和 API 中的常见约定一致。限制空格和逗号可避免解析问题和歧义。长度限制（1–64）对大多数用例足够宽松，同时防止滥用。

​
规范

  • 工具名称**应当（SHOULD）**在 1 到 64 个字符之间（含边界）。
  • 工具名称区分大小写。
  • 允许的字符：大写和小写 ASCII 字母（A-Z、a-z）、数字（0-9）、下划线（_）、连字符（-）、点（.）和正斜杠（/）。
  • 工具名称**不应当（SHOULD NOT）**包含空格、逗号或其他特殊字符。
  • 工具名称**应当（SHOULD）**在其命名空间内唯一。
  • 有效工具名称示例：
    • getUser
    • user-profile/update
    • DATA_EXPORT_v2
    • admin.tools.list

​
向后兼容性

对于使用了不允许字符或超出新长度限制的既有工具，此变更不向后兼容。为将干扰降至最低：
  • 既有的不符合规范的工具名称**应当（SHOULD）**作为别名至少支持一个主版本，并附带弃用警告。
  • 工具作者**应当（SHOULD）**更新其文档和代码以使用新格式。
  • **应当（SHOULD）**提供一份迁移指南，以协助实现者更新其工具名称。

​
参考实现

可以通过更新 MCP 核心库、在注册时强制执行新的工具名称校验规则来提供参考实现。既有工具可以更新，为其新的符合规范的名称提供别名，并对已弃用的格式发出警告。示例代码和迁移脚本可以包含在 MCP 仓库中。

​
安全影响

无。标准化工具名称格式不会引入新的安全风险。