Preamble

• Proposer: Xiangfan Wu (Qi-anxin Technology Research Institute)
• Date: August 28, 2025
• Status: draft
• Version: 0.1.1 ( We may conduct additional experiments, provide more data, or revise the details of the proposal. )
• Competing Proposal: SEP-986 （SEP-986: Specify Format for Tool Names #986)

Abstract

The Model Context Protocol (MCP) ecosystem is facing systemic risks due to the lack of naming standards, including severe interoperability obstacles and consequent security vulnerabilities such as injection, service overriding, and DoS. Based on a deep empirical analysis of over 19 clients, 11 API gateways, 11 large language models, and mainstream parsing frameworks (vLLM, SGLang), and in conjunction with the discovery of more than ten high-risk security vulnerabilities for the first time, this proposal puts forward a comprehensive and rigorous set of naming conventions.
This proposal elaborates on the specific harms of naming chaos in the four key links—clients, API gateways, models, and parsing frameworks—and provides an in-depth risk assessment and attack vector analysis. Accordingly, we have designed a naming framework consisting of six core principles: reserving the system keyword to establish a core namespace, enforcing strict character and format constraints on server name to prevent spoofing attacks, unifying and clarifying length limits to eliminate cross-platform barriers, strictly prohibiting any form of implicit name transformation to ensure the uniqueness and integrity of tools, advocating and standardizing server identity verification to establish a chain of trust, and promoting fairness in model training to foster a healthy ecosystem.

Background and Motivation

As a critical bridge connecting Large Language Models (LLMs) with a vast array of external tools and services, the strategic value of the MCP is increasingly prominent. It aims to create a unified, programmable interface that enables LLMs to dynamically discover, understand, and invoke external capabilities. However, the realization of this grand vision is being hampered by a seemingly minor yet profoundly impactful foundational issue: the chaos and inconsistency in naming.
Currently, the MCP ecosystem's invocation chain involves multiple links with independent decision-making and implementation. We deconstruct this chain into four core links and analyze the specific problems caused by naming chaos in each:
● 1.1. Client-Side Registration: Clients (such as IDE plugins, CLI tools) are the "birthplace" of MCP tools. Developers define tool names here. Due to the lack of a unified standard, developers face a dilemma: if they use only concise names that comply with the strictest gateway limitations (e.g., only letters and numbers), they sacrifice the expressiveness and readability of the name; if they allow more descriptive names (e.g., containing ., _, or Unicode characters), they may be unusable on certain gateways or models. This uncertainty leads to a large amount of "defensive naming" and insecure "auto-fixing" behaviors on the client side (e.g., silent truncation, character replacement), laying the groundwork for subsequent security vulnerabilities.
● 1.2. API Gateway Enforcement: API gateways (such as the API endpoints of OpenAI, Google, Anthropic) are the enforcers of rules. However, the rule sets of various gateways are not only different (e.g., length limits range from 63 to 256 characters, and the allowed character sets are not clearly defined) but also often lack detailed public documentation. This "rule black box" forces client developers to guess the boundaries through trial and error, greatly increasing integration costs and posing a fundamental obstacle to the cross-platform portability of tools.
● 1.3. Model-Side Invocation: The LLM itself is the "user" of the tools. Our experiments reveal that the model is not neutral towards tool names. Its internal parsing capabilities and biases present in its training data affect its "affinity" for tools. Non-standard names may directly cause the model to fail to parse or refuse to invoke, while specific naming styles (e.g., brand names, generic words) unfairly influence the probability of a tool being selected. This model-side "preference" and "discrimination" undermine the principle of neutrality that MCP should uphold.
● 1.4. Framework-Side Parsing: Server-side inference frameworks (such as vLLM, SGLang) are the final "interpreters" of tool invocation requests. The tool_use requests generated by the model (usually in JSON or similar structures) need to be accurately parsed by these frameworks. When tool names contain special characters that conflict with the parser's syntax, catastrophic consequences can be triggered, such as the parser crashes or infinite loops we discovered, leading to DoS attacks.
Motivation Summary: The current naming problem in the MCP ecosystem is no longer a simple matter of style inconsistency but has formed a "problem chain" from definition, transmission, to parsing and execution. It systematically increases development friction, hinders functional innovation, undermines ecosystem fairness, and creates a real, exploitable security attack surface. Therefore, establishing a unified naming specification that covers the entire chain has become an unavoidable and urgent priority for practitioners to ensure the healthy development of the ecosystem.

Motivation

In our research, we discovered a large number of issues caused by non-standard naming, as detailed below:
Client-Side Registration: Poor Interoperability and Security Vulnerabilities Coexist
We conducted a statistical analysis of the MCP tool name specifications of over 20 mainstream clients (including OpenAI Codex, Gemini CLI, VS Code Copilot, etc., full list in Appendix A).
Case Conversion and Logical Overriding: Automatic case conversion of names by clients (e.g., forcing to lowercase) directly undermines their uniqueness. For example, two tools with completely different design intentions and permissions, API.PROD and api.prod, would create a naming conflict after conversion. This can lead to silent logical overriding and even unintended privilege escalation vulnerabilities.
Path Ambiguity and Namespace Injection: When clients allow separators like / in names, it introduces fatal parsing ambiguity. For example, combining server name: 'a' with tool name: 'b/c', and combining server name: 'a/b' with tool name: 'c', may produce the exact same internal identifier a/b/c after path concatenation on the server. This conflict can not only lead to accidental tool overriding or call hijacking but also allow an attacker to "inject" their malicious server into a trusted namespace, thereby breaking the trust boundary and bypassing prefix-based security policies.
Implicit Conversion and Semantic Loss: Character filtering or replacement for compatibility purposes damages the expressiveness and uniqueness of a name. For example, when a name calculate(π) is "sanitized" to calculate_, it not only loses the key semantics that make it understandable but also greatly increases the risk of naming conflicts with other tools.
Name Conflicts Caused by Length Shortening: The handling of overly long names by clients also lacks a standard, and two dangerous strategies exist. First, direct truncation: some clients (like Gemini CLI, VS Code) crudely truncate the name. This easily leads to conflicts, as different names may become identical after truncation, resulting in unexpected overriding. Second, hashing: other clients (like OpenAI Codex) hash long names (e.g., with SHA-1). This method not only introduces the potential risk of hash collisions but also makes the name opaque and unreadable.
In summary, due to the lack of unified standards for MCP naming, various clients have to implement complex name "fixing" and "compatibility" mechanisms on their own. These custom implementations, originally intended to improve compatibility, not only significantly increase technical complexity and ecosystem fragmentation but also inadvertently introduce serious security vulnerabilities such as logical overriding, namespace injection, and hash collisions.
This situation clearly indicates that delegating the interpretation of naming rules to individual clients is a dangerous and unsustainable practice. Therefore, establishing a globally unified, unambiguous naming specification is the fundamental prerequisite for solving the above problems at their root and ensuring the security of the ecosystem.

Problem Analysis and Risk Assessment
In our research, we discovered a large number of issues caused by non-standard naming, as detailed below:
Client-Side Registration: Poor Interoperability and Security Vulnerabilities Coexist
We conducted a statistical analysis of the MCP tool name specifications of over 19 mainstream clients (including OpenAI Codex, Gemini CLI, VS Code Copilot, etc., full list in Appendix A).

Case Conversion and Logical Overriding: Automatic case conversion of names by clients (e.g., forcing to lowercase) directly undermines their uniqueness. For example, two tools with completely different design intentions and permissions, API.PROD and api.prod, would create a naming conflict after conversion. This can lead to silent logical overriding and even unintended privilege escalation vulnerabilities.
Path Ambiguity and Namespace Injection: When clients allow separators like / in names, it introduces fatal parsing ambiguity. For example, combining server name: 'a' with tool name: 'b/c', and combining server name: 'a/b' with tool name: 'c', may produce the exact same internal identifier a/b/c after path concatenation on the server. This conflict can not only lead to accidental tool overriding or call hijacking but also allow an attacker to "inject" their malicious server into a trusted namespace, thereby breaking the trust boundary and bypassing prefix-based security policies.

Implicit Conversion and Semantic Loss: Character filtering or replacement for compatibility purposes damages the expressiveness and uniqueness of a name. For example, when a name calculate(π) is "sanitized" to calculate_, it not only loses the key semantics that make it understandable but also greatly increases the risk of naming conflicts with other tools.

Name Conflicts Caused by Length Shortening: The handling of overly long names by clients also lacks a standard, and two dangerous strategies exist. First, direct truncation: some clients (like Gemini CLI, VS Code) crudely truncate the name. This easily leads to conflicts, as different names may become identical after truncation, resulting in unexpected overriding. Second, hashing: other clients (like OpenAI Codex) hash long names (e.g., with SHA-1). This method not only introduces the potential risk of hash collisions but also makes the name opaque and unreadable.

In summary, due to the lack of unified standards for MCP naming, various clients have to implement complex name "fixing" and "compatibility" mechanisms on their own. These custom implementations, originally intended to improve compatibility, not only significantly increase technical complexity and ecosystem fragmentation but also inadvertently introduce serious security vulnerabilities such as logical overriding, namespace injection, and hash collisions.
This situation clearly indicates that delegating the interpretation of naming rules to individual clients is a dangerous and unsustainable practice. Therefore, establishing a globally unified, unambiguous naming specification is the fundamental prerequisite for solving the above problems at their root and ensuring the security of the ecosystem.

API Gateways: Inconsistent Rules, Varying Restrictions
API gateways are a major reason why clients are forced to adopt conservative naming strategies. We investigated the API gateways of 11 mainstream vendors and found 7 different sets of rules for tool name (details in Appendix B).
Risk Details: The fragmentation of gateway rules forces responsible developers to design their tools according to the "strictest one," a typical case of "bad money drives out good." For example, even if an advanced model can support a 256-character tool name with rich Unicode characters (hunyun, GLM, ernie), as long as there is one mainstream gateway in the ecosystem that only supports 64-character alphanumeric names, all tool developers may be forced to choose the latter for cross-platform compatibility, thereby suppressing the expressive power and innovation potential of the entire ecosystem.
Below is a distribution chart of successful API gateway calls.

Model Invocation: Inherent Biases and Risks of Abuse

Through experiments, we found that models are not entirely neutral when handling tool invocations; their behavior is influenced by the name (experimental data in Appendix C).
Conclusion:
Model Invocation Capability: Experiments show that current models often fail to successfully invoke tools with excessively long or specially-charactered names. Specifically, when a name exceeds a certain length threshold, the model will give up the invocation directly. When complex symbols are present, it may fail due to parsing errors. This indicates that the model's invocation capability is highly sensitive to name specifications, lacking robustness and fault tolerance. In a real-world environment, without a unified naming standard, overly long or non-standard tool names will significantly reduce the success rate of invocations, affecting overall system availability and reliability.

Name Preference: Experiments show significant differences in name preference among different models: kimi and deepseek clearly favor "big company/authoritative brand-style names," while qwen prefers "generic function names." This indicates that the naming style itself influences the model's selection tendency during tool invocation. Names of large companies and research institutions often imply "credibility/professionalism," while generic words are more neutral and may be seen by some models as a default or safe choice. The results suggest that in a multi-model environment, name design significantly affects the probability of a tool being invoked.
Order Sensitivity: The experimental results clearly show that tool invocation is strongly influenced by order. Almost all models showed a significant preference for the tool listed first in AB/BA comparisons, with kimi and deepseek reaching almost 100% "one-sidedness." qwen's preference was weaker but still significant, while ernie sometimes did not trigger at all. The order effect, combined with inherent name effects, causes the model's tool invocation to rely not only on task semantics but also to be disturbed by the presentation format. This finding reveals a bias in the existing LLM tool selection mechanism, which could lead to fairness and security issues, such as malicious actors manipulating invocation results through tool ordering or naming.

Language Sensitivity: The experimental results show that in a multilingual environment, once an English tool is introduced, the model will almost completely abandon tools in other languages, showing a significant English-first preference. In scenarios with only multilingual tools, the model can partially follow the prompt language to select the corresponding tool, but the addition of an English tool quickly leads to an imbalance, making non-English tools difficult to invoke.

In summary, the model invocation link exhibits multi-dimensional vulnerabilities in the absence of uniform naming. On one hand, overly long or specially-charactered names directly reduce the success rate of invocations, revealing the limitations of the model's parsing capabilities. On the other hand, the model's preference for specific naming styles, order, and languages further exacerbates the uncertainty of invocation results. These factors not only decrease the availability of tool invocations but also raise fairness and security issues. An attacker could influence the model's decisions by manipulating tool names or order to achieve overriding, misdirection, or even denial of service. Especially in a multilingual environment, the "suppression effect" of English tools is particularly prominent, making tools in other languages difficult to be invoked normally. These phenomena collectively demonstrate that without a unified, strict naming specification, the MCP ecosystem will face significant risks in cross-platform migration and security assurance, urgently requiring systematic governance at the protocol level.
Framework Parsing: New DoS Vulnerabilities
We conducted a deep audit of the tool use response parsing logic in the vLLM and SGLang frameworks and, for the first time, discovered 4 DoS vulnerabilities related to tool name parsing, with complexities ranging from O(N^2) to O(2^N) (currently not fully disclosed).
Conclusion: When a tool name contains specific characters, such as ;, [, ], {, }, etc., it may conflict with the delimiters of JSON or other structured data, causing the parser to fall into an infinite loop or crash abnormally, thereby triggering a DoS. Although these vulnerabilities will be fixed in the future, considering the diversity of inference frameworks and the complexity of their implementations throughout the ecosystem, the most prudent approach is to prohibit the use of such high-risk characters in names at the specification level.

Specification

Based on the analysis above, we formally propose the following six MCP naming specification recommendations:
Reserve the system Keyword

Rule 1.1: The keyword system is designated as a reserved word for the built-in MCP server. The server name for all tools provided by the system core or built into the protocol must be system.

Rule 1.2: The server name of any external or user-registered MCP server must not be system. This check must be case-insensitive (e.g., System, SYSTEM are also prohibited). Implementers must reject any registration request for such a name.

Rationale and Objective: This rule aims to establish a protected core namespace. system as a server name clearly identifies trusted, fundamental capabilities provided by the platform or protocol itself (e.g., core APIs, metadata queries). By prohibiting users from registering this name, it fundamentally prevents user tools from impersonating core functions, avoiding permission confusion and security deception.
server name Character Restrictions

Rule 2.1: The server name must not contain / (slash) characters.

Rule 2.2: The concatenation of the server name and tool name is done using a / (slash) .

Rationale and Objective: To prevent concatenation-related attacks, it's crucial to ensure that the server name acts as an atomic and indivisible identifier. The use of / is intended to prevent path injection attacks. If slashes were permitted in a server name, a combination like server name: 'a/b' and tool name: 'c' would create a critical path ambiguity with server name: 'a' and tool name: 'b/c'. This could lead to severe issues such as tool overriding.

Rule 3.1: The maximum length for both server name and tool name is restricted to 128 characters. Any name exceeding this length must be rejected.

Rationale and Objective: 128 characters strikes a balance between the expressive power of a tool name and the performance/security of the system. Excessively short names (e.g., 64 characters) limit the ability to describe complex functions, while an unlimited length would burden parsers, databases, and network transmissions, and could become an entry point for resource-exhaustion DoS attacks. A unified, reasonable length limit provides all implementers with a clear expectation for buffer sizes, simplifying memory management and reducing the risk of buffer overflows.

Rule 4.1: Implementers must not perform any form of implicit transformation or "fixing" on a tool name, such as changing case, or replacing or removing characters. The name must be processed as-is.

Rule 4.2: The tool name should support the full Unicode character set to ensure global compatibility and expressiveness.

Rule 4.3: If a tool name contains characters or formats unsupported by the implementer, the tool's registration request must be explicitly rejected with a clear error, rather than being silently modified.

Rationale and Objective: The core of this rule is to adhere to the design philosophy of "explicit is better than implicit." A name is a tool's unique identifier, and any silent modification to it undermines its integrity. This rule ensures that my-tool and my_tool are two completely different tools, and case sensitivity must also be respected. This eliminates the extremely difficult-to-debug "ghost bugs" caused by different systems' "opinionated" fixes and closes the security vulnerability of logical overriding by constructing tools that become identical after transformation.

Recommendation 5.1: Clients should proactively adopt strategies to verify the authenticity of a server name. For example, for a server name like mcp.google.com, verification can be done through DNS checks or other mechanisms to prevent spoofing and ensure that the user is interacting with a legitimate service.
Fair Model Training

Recommendation 6.1: When training models that support tool invocation, model vendors should make their best effort to ensure fairness and neutrality. This includes reducing bias towards tools with specific naming patterns (e.g., well-known brands) and ensuring that the model's selection is based on the tool's functionality and user intent, rather than its name.

Rationale and Objective: The model's biases directly affect market fairness. This recommendation aims to encourage model vendors to take on the responsibility of being "ecosystem gatekeepers." By introducing de-biasing techniques during the training phase (such as using functional descriptions instead of names as the primary decision-making basis, or anonymizing or balancing tool names in the training data), a more open and innovative ecosystem can be fostered, where the value of a tool is determined by its function, not the brand effect of its name.

Backward Compatibility

We understand that implementing a new specification requires a smooth transition path for the existing ecosystem. To ensure backward compatibility and encourage community adoption, we recommend a phased implementation strategy.

Phase One: Validation and Warning Period (Recommended Duration: 6 months)

Implementers of MCP clients, gateways, and frameworks should first introduce validation logic for the new naming specification.

For newly registered non-compliant names, the system should return a clear Warning, informing the developer that their name does not meet future standards and suggesting modification, but it should not reject the registration for the time being.

For existing non-compliant names, the system can record a Deprecation Log during invocation or management, allowing developers to audit and migrate.

Phase Two: Strict Enforcement Period (After Phase One)

In this phase, for newly registered MCP tools, all implementers MUST strictly enforce the specification of this proposal. Any non-compliant name will be explicitly rejected.

For legacy tools that existed before this phase, implementers may adopt a "grandfather clause," continuing to support their operation for a period, but should clearly mark them as "deprecated" or "pending migration" in management interfaces or documentation.
Through this gradual approach, we can give developers ample time to adjust and migrate their tools, minimizing the impact on existing services while steadily migrating the entire ecosystem to a safer, more unified new standard.

Security Considerations

Security was a core consideration in the design of each specification in this proposal. A unified naming standard not only solves interoperability issues but also fundamentally reinforces the security posture of the entire MCP ecosystem.

Preventing Name Spoofing and Impersonation: The normalization of server name (e.g., disabling /, :) and the verification recommendation (Recommendation 5.1) are key to defending against tool impersonation attacks. An unverified server name could be used by a malicious actor to imitate a legitimate, trusted tool (e.g., by setting the name to mcp.google.com.malicious-site.com), thereby tricking a model or user into executing dangerous operations or leaking sensitive data. Mandatory name verification and a clear namespace can significantly reduce such phishing and spoofing risks.

Eliminating Parsing-Level Vulnerabilities: The DoS vulnerabilities we discovered in frameworks like vLLM demonstrate that ambiguous characters are weak points that attackers can exploit. This proposal systematically eliminates such parsing vulnerabilities at the specification level by prohibiting the use of high-risk characters (e.g., ;, [, ], /, :) in server name and tool name. This is a "shift-left security" practice, avoiding common security pitfalls that downstream implementers might introduce at the protocol design stage.

Avoiding Tool Overriding and Permission Confusion: Prohibiting implicit name transformation (Rule 4.1) is crucial for maintaining system integrity and permission boundaries. If a system automatically handles case or replaces characters, an attacker could override an existing, possibly higher-privileged, tool by constructing a name that appears different but becomes identical after transformation (e.g., myTool vs my_tool). A strict name-matching principle ensures the uniqueness and immutability of each MCP tool, preventing permission confusion and unauthorized logical overriding.

Defensive Value of Unified Length Limits: Setting a clear 128-character maximum length (Rule 3.1), in addition to improving compatibility, also provides a safeguard against potential buffer overflow-type attacks. In some resource-constrained or less robustly implemented parsers, excessively long name inputs could lead to memory allocation problems. A unified and reasonable length limit simplifies the difficulty of secure implementation and code auditing.

Reference Implementation

Reference Implementation: A reference implementation will be completed before this SEP is accepted by the community and enters the "Final" state. We will provide an updated version of the Python SDK (modelcontextprotocol/python-sdk) that will fully implement all the specifications defined in this proposal and include examples and unit tests for compliance testing. It will serve as a benchmark for other language implementations of the new specification.
Additional Support: We are considering adding a corresponding MCP name detection feature to AI-Infra-Guard (an opensource security scanning tool for MCP). This feature will include checking which platforms or gateways do not support certain names, and in which clients multiple names might cause implicit conversion and overwriting issues. This will help current MCP developers become aware of potential non-support situations or security risks associated with their chosen names.

Conclusion and Outlook

Through a comprehensive analysis of the MCP ecosystem, this proposal reveals the serious problems caused by the current lack of naming specifications and puts forward a set of concrete, feasible standardization recommendations. We firmly believe that adopting these specifications will greatly enhance the interoperability, security, and robustness of MCP.
We welcome open communication with the MCP committee, the broader developer community, and model vendors to revise and improve this proposal. Our ultimate goal is to promote this proposal to become a standard followed by the industry, thereby fostering the common prosperity and development of the entire MCP ecosystem.