ps这是一个未找到充分证据证明的问题可能跟最初模型分词训练有关也有可能是一个工程上的历史遗留问题。打算去问一下官方看看能不能给出一些回答目前能确认的是部分模型 API 的工具名规则比 MCP 更严格因此产生了工程兼容性问题。至于为什么特意排除英文点号.尚未找到明确的官方设计说明不能把训练、分词或历史兼容方面的猜测写成确定原因。下面按问题整理区分事实、证据和推测。1模型接口为什么要规定工具名称如果不限制字符会怎样工具名承担两个职责给模型看帮助模型理解和选择工具。给程序用将模型返回的调用对应到已注册的工具。名称规则定义了接口接受什么输入方便调用双方统一校验。但必须区分“需要明确的名称约定”不等于“技术上必须禁止点号”。如果放宽字符范围只要接口、模型调用链和执行端都能保留并按完整名称查找带点号的名称可以正常工作。唯一性、长度和错误处理仍然可以单独规定。普通 MCP 调用中的{ name: cad.drawing.check, arguments: { file_id: drawing-A } }这里的cad.drawing.check是字符串标识。协议不要求把它拼成 Python 表达式执行程序可以直接用它查找注册的处理函数。modelcontextprotocol.io2哪些接口允许点号哪些不允许以下是此前核对的具体接口文档规则不是所有模型的统一规则也不是逐家发请求测试的结果。具体接口允许.文档规定OpenAI Chat Completions 的函数工具不允许英文字母、数字、_、-。developers.openai.comClaude Messages 的普通自定义工具不允许^[a-zA-Z0-9_-]{1,128}$。platform.claude.comDeepSeek Chat Completions不允许英文字母、数字、_、-。api-docs.deepseek.com千问 Responses API不允许英文字母、数字、_、-。help.aliyun.comCohere 官方错误参考所列规则不允许英文字母、数字、_且不能以数字开头。docs.cohere.comAmazon Bedrock Converse 的工具定义不允许[a-zA-Z0-9_-]。docs.aws.amazon.comGemini Generate Content 的FunctionDeclaration.name允许字符范围包含_、:、.、-。ai.google.devMeta Model API 的函数工具有条件允许函数名最多一个点号命名空间外层名称不能包含点号。dev.meta.ai所以可以说很多主流接口不接受点号不能说“只有 Gemini 接受”或“所有大模型都处理不了点号”。3为什么 Google 允许点号却又建议不用Google 的 Generate Content 函数调用指南中确实建议名称应具有描述性并避免空格、点号和连字符。该页面目前标注为 Legacy。ai.google.dev这里需要区分三个问题层次回答的问题接口规则这种名称是否属于可接受的输入使用建议厂商推荐怎样命名实验结论在指定模型和任务上哪种命名效果更好“允许但不推荐”并不矛盾。但这段指南没有说明点号为什么不推荐也没有给出“点号与下划线”的对照实验因此不能据此推导“点号导致幻觉”。4MCP 为什么把点号放进建议字符范围MCP 所核对版本的工具规范建议长度为 1128 个字符。使用 ASCII 英文字母、数字、_、-、.。名称按大小写区分并在单个 Server 内唯一。示例明确包含admin.tools.list。这些条款使用SHOULD不能理解成所有 SDK 都必须用相同方式强制拒绝不符合建议的名称。modelcontextprotocol.ioSEP-986给出了明确动机支持层级式名称和命名空间兼容已有命名习惯同时容纳人工和机器生成的名称避免不必要地排除合理用法。例如cad.drawing.check 产品 → 资源 → 操作这是允许开发者表达层次不代表 MCP 会自动解析这些层次也不保证所有模型 API 接受这个原始名称。批注SEP 文本与后续规范在长度、斜杠等细节上存在差异。这里用 SEP 解释设计动机具体命名约束以所采用版本的正式规范为准。5哪些关于“禁止点号”的解释需要撤回或加以限定解释核对后的判断点号会使 JSON 不合法不成立。点号可以合法地出现在 JSON 字符串中普通 MCP 会把工具名直接拼成代码执行协议没有这个要求未找到普通调用链必须这样做的证据为符合 Python 函数名语法所以禁止点号解释不充分这些接口允许的-同样不是合法的 Python 函数标识符字符工具名里的点号会被当成正则混淆了“正则表达式”与“被匹配的名称”分词器无法处理点号不准确。切分不同不等于无法编码例如tiktoken明确支持可逆、无损的文本编码。github.com禁止点号是为了减少幻觉尚未找到证明这一设计动机的官方说明或直接实验另外两个曾经提到的例子也不能补上因果关系Programmatic Tool Calling确实会把工具暴露成可调用的 Python 函数但文档没有说明这就是普通工具名禁止点号的原因。Claude Platform DocsClaude Code Hooks中被按正则解释的是配置的matcher工具名是被匹配的值。不能因此说所有工具名称都被当作正则执行。Claude Code Docs6论坛和实际案例究竟证明了什么你提供的 Google 论坛中有用户报告在当时的gemini-1.5-pro-latest上声明mymod.find.theaters返回的名称却是find_theaters。这是一个名称没有原样保留的历史案例不能单靠最终输出判断究竟是模型生成、客户端处理还是服务端处理造成的。discuss.ai.google.dev回复者提出了分词和训练数据解释但明确承认属于猜测。官方论坛里的个人回复不等于厂商确认的原因。discuss.ai.google.dev微软 Semantic Kernel 的设计记录则记载声明foo-bar模型可能返回foo_bar或foo.bar。名称不一致会导致工具查找失败。将带点号的调用记录放入后续请求还可能触发 API 名称校验错误。这证明模型可能写错分隔符名称错误会影响调用可靠性但没有证明“输入带点号比输入下划线更容易出错”。Anthropic 关于前缀、后缀影响工具评测以及有意义的标识符改善检索的说明也只能支持命名设计会影响使用效果不能直接证明点号有害。www.anthropic.com7为什么很多厂商采用相似规则有哪些合理猜想以下都是待验证的解释猜想直观解释尚缺少的证据沿用已有 API 约定为方便已有 SDK、框架和应用迁移采用相似限制具体厂商是否因此继承了这条字符规则早期采用较小的白名单后来持续保留最初主要支持snake_case、kebab-case其他字符没有进入支持范围原始设计记录以及规则保留至今的理由与训练、评测范围保持一致如果相关样本主要覆盖下划线、连字符命名限制范围可能减少未验证行为实际训练分布以及不同分隔符的对照结果其中兼容需求本身有明确证据DeepSeek 和千问都公开提供兼容既有 API 的接口。但这还不能证明每一家采用相同正则的具体原因。api-docs.deepseek.com因此多家规则相同不等于多家独立研究都发现点号有害。8到底算不算历史遗留工程问题判断是否能够确定MCP 与部分模型接口存在命名兼容问题可以确定这些限制可能包含历史约定和兼容性因素合理推测点号在技术上不能支持不能成立为普遍结论已有接口支持原限制已经没有必要只是厂商一直没改不能确定原设计是错误的历史缺陷缺少依据不能直接定性准确名称应当是跨协议命名约束带来的工程兼容性问题可能包含历史兼容因素。9你的 Harness 应该怎样处理MCP 的 SEP-986 集成讨论Allow the period . in names in Function calling - Gemini API - Google AI Developers Forum已经直接指出MCP 名称经过命名空间处理后仍可能需要进一步适配模型 API。实现上应当保留原始 Server 标识和原始工具名。按目标模型接口生成合规的模型侧名称。处理转换后的重名和长度限制。保存模型侧名称到原始工具身份的映射。收到调用后根据映射找到连接向 MCP Server 发送原始名称。例如环节名称MCP Server 暴露cad.drawing.check提供给不接受点号的模型接口cad_drawing_check实际发送 MCPtools/callcad.drawing.check不能靠把下划线重新替换成点号来还原因为原始名称本身也可能包含下划线应使用保存的映射。对你的工程而言适配的直接依据是目标接口公开的名称约束不需要先假定点号会导致幻觉也不需要把整个问题定性为历史缺陷。 
长河君 · 2026/10/11 5:15:29 · 阅读 1.2k 为什么大多数模型接口不允许工具名带点号？
ps这是一个未找到充分证据证明的问题可能跟最初模型分词训练有关也有可能是一个工程上的历史遗留问题。打算去问一下官方看看能不能给出一些回答目前能确认的是部分模型 API 的工具名规则比 MCP 更严格因此产生了工程兼容性问题。至于为什么特意排除英文点号.尚未找到明确的官方设计说明不能把训练、分词或历史兼容方面的猜测写成确定原因。下面按问题整理区分事实、证据和推测。1模型接口为什么要规定工具名称如果不限制字符会怎样工具名承担两个职责给模型看帮助模型理解和选择工具。给程序用将模型返回的调用对应到已注册的工具。名称规则定义了接口接受什么输入方便调用双方统一校验。但必须区分“需要明确的名称约定”不等于“技术上必须禁止点号”。如果放宽字符范围只要接口、模型调用链和执行端都能保留并按完整名称查找带点号的名称可以正常工作。唯一性、长度和错误处理仍然可以单独规定。普通 MCP 调用中的{ name: cad.drawing.check, arguments: { file_id: drawing-A } }这里的cad.drawing.check是字符串标识。协议不要求把它拼成 Python 表达式执行程序可以直接用它查找注册的处理函数。modelcontextprotocol.io2哪些接口允许点号哪些不允许以下是此前核对的具体接口文档规则不是所有模型的统一规则也不是逐家发请求测试的结果。具体接口允许.文档规定OpenAI Chat Completions 的函数工具不允许英文字母、数字、_、-。developers.openai.comClaude Messages 的普通自定义工具不允许^[a-zA-Z0-9_-]{1,128}$。platform.claude.comDeepSeek Chat Completions不允许英文字母、数字、_、-。api-docs.deepseek.com千问 Responses API不允许英文字母、数字、_、-。help.aliyun.comCohere 官方错误参考所列规则不允许英文字母、数字、_且不能以数字开头。docs.cohere.comAmazon Bedrock Converse 的工具定义不允许[a-zA-Z0-9_-]。docs.aws.amazon.comGemini Generate Content 的FunctionDeclaration.name允许字符范围包含_、:、.、-。ai.google.devMeta Model API 的函数工具有条件允许函数名最多一个点号命名空间外层名称不能包含点号。dev.meta.ai所以可以说很多主流接口不接受点号不能说“只有 Gemini 接受”或“所有大模型都处理不了点号”。3为什么 Google 允许点号却又建议不用Google 的 Generate Content 函数调用指南中确实建议名称应具有描述性并避免空格、点号和连字符。该页面目前标注为 Legacy。ai.google.dev这里需要区分三个问题层次回答的问题接口规则这种名称是否属于可接受的输入使用建议厂商推荐怎样命名实验结论在指定模型和任务上哪种命名效果更好“允许但不推荐”并不矛盾。但这段指南没有说明点号为什么不推荐也没有给出“点号与下划线”的对照实验因此不能据此推导“点号导致幻觉”。4MCP 为什么把点号放进建议字符范围MCP 所核对版本的工具规范建议长度为 1128 个字符。使用 ASCII 英文字母、数字、_、-、.。名称按大小写区分并在单个 Server 内唯一。示例明确包含admin.tools.list。这些条款使用SHOULD不能理解成所有 SDK 都必须用相同方式强制拒绝不符合建议的名称。modelcontextprotocol.ioSEP-986给出了明确动机支持层级式名称和命名空间兼容已有命名习惯同时容纳人工和机器生成的名称避免不必要地排除合理用法。例如cad.drawing.check 产品 → 资源 → 操作这是允许开发者表达层次不代表 MCP 会自动解析这些层次也不保证所有模型 API 接受这个原始名称。批注SEP 文本与后续规范在长度、斜杠等细节上存在差异。这里用 SEP 解释设计动机具体命名约束以所采用版本的正式规范为准。5哪些关于“禁止点号”的解释需要撤回或加以限定解释核对后的判断点号会使 JSON 不合法不成立。点号可以合法地出现在 JSON 字符串中普通 MCP 会把工具名直接拼成代码执行协议没有这个要求未找到普通调用链必须这样做的证据为符合 Python 函数名语法所以禁止点号解释不充分这些接口允许的-同样不是合法的 Python 函数标识符字符工具名里的点号会被当成正则混淆了“正则表达式”与“被匹配的名称”分词器无法处理点号不准确。切分不同不等于无法编码例如tiktoken明确支持可逆、无损的文本编码。github.com禁止点号是为了减少幻觉尚未找到证明这一设计动机的官方说明或直接实验另外两个曾经提到的例子也不能补上因果关系Programmatic Tool Calling确实会把工具暴露成可调用的 Python 函数但文档没有说明这就是普通工具名禁止点号的原因。Claude Platform DocsClaude Code Hooks中被按正则解释的是配置的matcher工具名是被匹配的值。不能因此说所有工具名称都被当作正则执行。Claude Code Docs6论坛和实际案例究竟证明了什么你提供的 Google 论坛中有用户报告在当时的gemini-1.5-pro-latest上声明mymod.find.theaters返回的名称却是find_theaters。这是一个名称没有原样保留的历史案例不能单靠最终输出判断究竟是模型生成、客户端处理还是服务端处理造成的。discuss.ai.google.dev回复者提出了分词和训练数据解释但明确承认属于猜测。官方论坛里的个人回复不等于厂商确认的原因。discuss.ai.google.dev微软 Semantic Kernel 的设计记录则记载声明foo-bar模型可能返回foo_bar或foo.bar。名称不一致会导致工具查找失败。将带点号的调用记录放入后续请求还可能触发 API 名称校验错误。这证明模型可能写错分隔符名称错误会影响调用可靠性但没有证明“输入带点号比输入下划线更容易出错”。Anthropic 关于前缀、后缀影响工具评测以及有意义的标识符改善检索的说明也只能支持命名设计会影响使用效果不能直接证明点号有害。www.anthropic.com7为什么很多厂商采用相似规则有哪些合理猜想以下都是待验证的解释猜想直观解释尚缺少的证据沿用已有 API 约定为方便已有 SDK、框架和应用迁移采用相似限制具体厂商是否因此继承了这条字符规则早期采用较小的白名单后来持续保留最初主要支持snake_case、kebab-case其他字符没有进入支持范围原始设计记录以及规则保留至今的理由与训练、评测范围保持一致如果相关样本主要覆盖下划线、连字符命名限制范围可能减少未验证行为实际训练分布以及不同分隔符的对照结果其中兼容需求本身有明确证据DeepSeek 和千问都公开提供兼容既有 API 的接口。但这还不能证明每一家采用相同正则的具体原因。api-docs.deepseek.com因此多家规则相同不等于多家独立研究都发现点号有害。8到底算不算历史遗留工程问题判断是否能够确定MCP 与部分模型接口存在命名兼容问题可以确定这些限制可能包含历史约定和兼容性因素合理推测点号在技术上不能支持不能成立为普遍结论已有接口支持原限制已经没有必要只是厂商一直没改不能确定原设计是错误的历史缺陷缺少依据不能直接定性准确名称应当是跨协议命名约束带来的工程兼容性问题可能包含历史兼容因素。9你的 Harness 应该怎样处理MCP 的 SEP-986 集成讨论Allow the period . in names in Function calling - Gemini API - Google AI Developers Forum已经直接指出MCP 名称经过命名空间处理后仍可能需要进一步适配模型 API。实现上应当保留原始 Server 标识和原始工具名。按目标模型接口生成合规的模型侧名称。处理转换后的重名和长度限制。保存模型侧名称到原始工具身份的映射。收到调用后根据映射找到连接向 MCP Server 发送原始名称。例如环节名称MCP Server 暴露cad.drawing.check提供给不接受点号的模型接口cad_drawing_check实际发送 MCPtools/callcad.drawing.check不能靠把下划线重新替换成点号来还原因为原始名称本身也可能包含下划线应使用保存的映射。对你的工程而言适配的直接依据是目标接口公开的名称约束不需要先假定点号会导致幻觉也不需要把整个问题定性为历史缺陷。