> ## Documentation Index
> Fetch the complete documentation index at: https://mcp-zh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SEP-986：规定工具名称的格式

* **状态（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 仓库中。

## 安全影响

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