Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Xray MCP Server create a VLESS server with REALITY on port 443"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server for generating Xray-core configurations using natural language. This server allows LLMs to create server and client configurations for various proxy protocols.
Protocol Support: VLESS, VMess, Trojan, Shadowsocks
Transport Support: TCP, WebSocket, gRPC, XHTTP
Security Support: None, TLS, REALITY
Automatic Key Generation: UUID, X25519 key pairs, Short IDs, Passwords
Configuration Validation: Syntax and semantic validation
Example Configurations: Ready-to-use templates
Documentation: Built-in protocol, transport, and security documentation
Related MCP server: surge-mcp-server
npm install
npm run buildAdd to your Cursor MCP settings (~/.cursor/mcp.json):
{
"mcpServers": {
"xray-mcp": {
"command": "node",
"args": ["/path/to/xray-mcp/dist/index.js"]
}
}
}generate_server_configGenerate Xray server configuration with specified protocol, transport, and security options.
Example:
Generate a VLESS server with REALITY on port 443generate_client_configGenerate Xray client configuration for connecting to a proxy server.
Example:
Create a client config for VLESS+REALITY server at example.com:443generate_uuidGenerate a new UUID v4 for VLESS/VMess authentication.
generate_x25519_keypairGenerate X25519 key pair for REALITY (returns private and public keys).
generate_short_idGenerate a random short ID for REALITY authentication.
generate_passwordGenerate a random password for Trojan or Shadowsocks.
generate_ss2022_keyGenerate a base64 key for Shadowsocks 2022.
validate_configValidate an Xray configuration for syntax and semantic errors.
list_protocolsList all supported proxy protocols with descriptions.
list_transportsList all supported transport types with descriptions.
list_securityList all supported security types with descriptions.
list_reality_targetsList recommended target sites for REALITY.
xray://docs/protocols - Protocol documentation
xray://docs/transports - Transport documentation
xray://docs/security - Security documentation
xray://examples/server-vless-reality - VLESS+REALITY server example
xray://examples/client-vless-reality - VLESS+REALITY client example
xray://examples/server-vmess-ws-tls - VMess+WS+TLS server example
xray://examples/server-trojan-tls - Trojan+TLS server example
xray://examples/server-shadowsocks-2022 - Shadowsocks 2022 server example
User: Create a VLESS server with REALITY on port 443, targeting microsoft.com
Assistant: (calls generate_server_config with appropriate parameters)
User: Generate a client config to connect to this server
Assistant: (calls generate_client_config with server details)
User: Generate a new UUID and X25519 key pair for REALITY
Assistant: (calls generate_uuid and generate_x25519_keypair)
Protocol | Description | Auth Type |
VLESS | Lightweight, supports XTLS Vision | UUID |
VMess | Classic V2Ray protocol | UUID |
Trojan | HTTPS-mimicking | Password |
Shadowsocks | Simple and fast | Password |
Transport | CDN Support | REALITY Support |
TCP | No | Yes |
WebSocket | Yes | No |
gRPC | Partial | Yes |
XHTTP | Yes | Yes |
Security | Certificate Required | Description |
None | No | No encryption |
TLS | Yes | Standard TLS |
REALITY | No | Advanced camouflage |
# Install dependencies
npm install
# Build
npm run build
# Run in development mode
npm run devMIT
Generate Xray client configuration for connecting to a proxy server.
| Name | Required | Description | Default |
|---|---|---|---|
| server_address | Yes | Server address (IP or domain) | |
| server_port | Yes | Server port | |
| protocol | Yes | Protocol type | |
| uuid | No | User UUID (for VLESS/VMess) | |
| password | No | Password (for Trojan/Shadowsocks) | |
| transport | No | Transport layer | tcp |
| security | No | Security layer | none |
| tls_server_name | No | TLS server name (SNI) | |
| tls_fingerprint | No | TLS fingerprint | |
| reality_public_key | No | REALITY public key | |
| reality_short_id | No | REALITY short ID | |
| reality_server_name | No | REALITY server name | |
| ws_path | No | WebSocket path | |
| grpc_service_name | No | gRPC service name | |
| socks_port | No | Local SOCKS5 proxy port | |
| http_port | No | Local HTTP proxy port | |
| routing_mode | No | Routing mode | global |
| ss_method | No | Shadowsocks encryption method | |
| vless_flow | No | VLESS flow control |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'generates' configuration, implying a read-only operation that produces output, but doesn't clarify if this requires specific inputs, what format the output takes, or any side effects. For a tool with 19 parameters and no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly states what the tool does ('Generate Xray client configuration') and why ('for connecting to a proxy server'), with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (19 parameters, no output schema, no annotations), the description is minimally adequate. It clarifies the tool's purpose but lacks details on output format, error handling, or dependencies. With high schema coverage, the description doesn't need to explain parameters, but it should provide more behavioral context for such a multifaceted tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema itself (e.g., 'Server address (IP or domain)', 'Protocol type'). The description adds no additional parameter semantics beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting but doesn't compensate with extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate Xray client configuration for connecting to a proxy server.' It specifies the verb ('generate'), resource ('Xray client configuration'), and context ('for connecting to a proxy server'). However, it doesn't explicitly differentiate from sibling tools like 'generate_server_config' or 'validate_config', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'generate_server_config' (for server-side configuration) and 'validate_config' (for validation), the agent must infer usage based on tool names alone. No explicit when/when-not statements or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random password for Trojan or legacy Shadowsocks
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Password length |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions generating a 'random password' but lacks details on randomness quality, character sets, security considerations, or output format. For a tool that likely has security implications, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to understand at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of password generation (security tool with no annotations and no output schema), the description is incomplete. It doesn't explain what the password looks like (e.g., character types), how it's returned, or any behavioral traits like randomness sources. For a tool in this context, more detail is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'length' documented as 'Password length' and a default of 16. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate a random password') and specifies the target context ('for Trojan or legacy Shadowsocks'), which distinguishes it from sibling tools like generate_uuid or generate_x25519_keypair. However, it doesn't explicitly differentiate from all siblings (e.g., generate_short_id might also produce random strings), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like generate_short_id or generate_ss2022_key, nor does it mention any prerequisites or exclusions. It simply states what it does without context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate Xray server configuration. Supports VLESS, VMess, Trojan, and Shadowsocks protocols with various transport and security options.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | Protocol type | |
| port | Yes | Server listening port (1-65535) | |
| transport | No | Transport layer | tcp |
| security | No | Security layer | none |
| tls_cert_file | No | TLS certificate file path (required for TLS) | |
| tls_key_file | No | TLS private key file path (required for TLS) | |
| reality_dest | No | REALITY target destination (e.g., www.microsoft.com:443) | |
| reality_server_names | No | REALITY server names | |
| ws_path | No | WebSocket path | |
| grpc_service_name | No | gRPC service name | |
| xhttp_path | No | XHTTP path | |
| users | No | User list (auto-generated if not provided) | |
| ss_method | No | Shadowsocks encryption method | |
| vless_flow | No | VLESS flow control | |
| log_level | No | Log level | warning |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what protocols and options are supported but doesn't describe what the tool actually does behaviorally: whether it creates files, returns configuration objects, requires specific permissions, has side effects, or handles errors. For a configuration generation tool with 15 parameters, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It wastes no words but could potentially benefit from slightly more structure given the tool's complexity. Every element earns its place by specifying protocols and options.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters, no output schema, no annotations), the description is insufficient. It doesn't explain what the output is (e.g., configuration file content, JSON object), how to use the generated configuration, or any behavioral aspects. For a tool with this many options and no structured output documentation, the description should provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value beyond the schema by listing supported protocols and transport/security options, but doesn't provide additional context about parameter interactions, dependencies, or usage patterns. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generate Xray server configuration' with specific protocols listed (VLESS, VMess, Trojan, Shadowsocks). It distinguishes from sibling tools like generate_client_config by focusing on server-side configuration, though it doesn't explicitly contrast with all siblings. The verb 'generate' is specific, and the resource 'server configuration' is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or when to choose this over sibling tools like generate_client_config or validate_config. The context is implied (server setup), but no explicit usage instructions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a random short ID for REALITY authentication
| Name | Required | Description | Default |
|---|---|---|---|
| length | No | Short ID length (0-16) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool generates IDs for authentication but doesn't describe what 'REALITY authentication' entails, whether the IDs are cryptographically secure, how they're formatted, or what happens on invocation. The description provides minimal behavioral context beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a simple tool with one optional parameter, and every element ('Generate', 'random short ID', 'for REALITY authentication') earns its place by adding distinct value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple ID generation tool with one well-documented parameter and no output schema, the description provides the essential purpose and context. However, without annotations or output schema, it lacks details about the generated ID format, security characteristics, or authentication integration that would be helpful for an agent to use it correctly in the REALITY system context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'length' fully documented in the schema. The description adds no parameter-specific information beyond what the schema already provides. The baseline score of 3 reflects adequate coverage when the schema does the heavy lifting, though the description doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and resource ('random short ID'), with specific purpose ('for REALITY authentication'). It distinguishes from siblings like generate_uuid or generate_password by specifying the ID type and authentication context. However, it doesn't explicitly contrast with all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('for REALITY authentication'), suggesting when this specific ID type is needed. However, it provides no explicit guidance on when to choose this over alternatives like generate_uuid or generate_password, nor any prerequisites or exclusions for using the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a base64 key for Shadowsocks 2022
| Name | Required | Description | Default |
|---|---|---|---|
| cipher | No | Shadowsocks 2022 cipher | 2022-blake3-aes-256-gcm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool generates a key but doesn't specify if this is a one-time operation, whether the key is stored or ephemeral, or any rate limits or permissions required. For a key-generation tool, this lack of detail on security implications and usage constraints is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without any fluff or redundancy. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (key generation with cipher options) and no annotations or output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like key usage, security considerations, or integration with sibling tools. This leaves gaps that could hinder an agent's effective use, especially in a server with multiple related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'cipher' well-documented in the schema itself (including enum values and default). The description adds no parameter-specific information, which is acceptable given the high schema coverage. Since there's only one parameter, the baseline is 4, as the schema sufficiently handles the semantics without needing extra description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generate') and resource ('base64 key for Shadowsocks 2022'), making the purpose immediately understandable. It distinguishes this tool from siblings like generate_password or generate_x25519_keypair by specifying the key type and protocol version. However, it doesn't explicitly contrast with all siblings, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like generate_password or generate_client_config. It lacks context about prerequisites, such as whether this is for client or server setup, or integration with other tools in the server. This leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a new UUID v4 for VLESS/VMess authentication
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool generates a UUID v4 but doesn't disclose behavioral traits like whether this is idempotent, if it requires authentication, rate limits, or what format the output takes. For a tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key information (generate UUID v4) with specific context (VLESS/VMess authentication). Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is adequate but incomplete. It specifies the UUID version and authentication context but doesn't address output format or behavioral aspects that would help an agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline 4 for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate a new UUID v4') and the resource/context ('for VLESS/VMess authentication'). It distinguishes from siblings like generate_password or generate_short_id by specifying UUID v4 for authentication purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (VLESS/VMess authentication) but doesn't explicitly state when to use this vs. alternatives like generate_short_id or generate_x25519_keypair. It provides clear context but lacks explicit exclusions or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate X25519 key pair for REALITY. Returns base64url encoded private and public keys.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (base64url encoded keys) but lacks details on permissions, rate limits, or error behavior. It adequately describes the core operation but misses broader behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the purpose and includes essential return format details without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is nearly complete. It specifies the key type, encoding, and context, though it could benefit from clarifying the REALITY usage scenario or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so the baseline is 4. The description does not need to compensate for missing parameter info, as the schema fully documents the empty input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Generate X25519 key pair') and resource ('for REALITY'), distinguishing it from sibling tools like generate_ss2022_key or generate_uuid. It precisely identifies the cryptographic algorithm and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in the REALITY context but does not explicitly state when to use this tool versus alternatives like generate_ss2022_key or generate_client_config. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported proxy protocols with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List' implies a read-only operation, it doesn't specify whether this requires authentication, what format the output takes, if there are rate limits, or any error conditions. The description adds minimal behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a simple listing tool and front-loads the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no parameters and no output schema, the description provides adequate but minimal context. It states what will be listed but doesn't describe the return format or structure. Given the tool's simplicity, this is acceptable but leaves gaps in understanding what the output will look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't discuss parameters since none exist, earning a baseline score of 4 for zero-parameter tools that don't waste space on parameter discussion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all supported proxy protocols with descriptions'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like 'list_reality_targets' or 'list_transports' by focusing specifically on protocols rather than other configuration elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or differentiate from similar tools like 'list_transports' or 'list_security', leaving the agent with no usage guidelines beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recommended target sites for REALITY
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't add context such as what 'REALITY' refers to, potential rate limits, or the format of the returned list. This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the purpose without waste. It's appropriately sized for a simple list tool, though it could be slightly more structured by front-loading key details like the resource type more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity is low (0 parameters, no output schema), the description is minimal but incomplete. It lacks context on what 'REALITY' is, how the list is formatted, or any behavioral traits, making it insufficient for full understanding despite the simple schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the inputs. The description doesn't need to add parameter details, and it doesn't contradict the schema. A baseline of 4 is appropriate as it compensates adequately for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'recommended target sites for REALITY', which gives a specific purpose. However, it doesn't differentiate from sibling tools like 'list_protocols', 'list_security', or 'list_transports' that also list resources, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like other 'list_' tools or 'validate_config'. There's no mention of context, prerequisites, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported security types with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't specify output format, pagination, or any constraints like rate limits or authentication needs. This is a significant gap for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic read operation. However, it lacks details on output structure or behavioral traits, which could be helpful for an agent. It meets the minimum viable standard but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but this is acceptable given the baseline. It implies the tool returns security types and descriptions, which adds minimal semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all supported security types with descriptions'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_protocols' or 'list_transports', which follow similar patterns but target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or comparisons to sibling tools like 'list_protocols' or 'list_transports', leaving the agent to infer usage based on naming alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all supported transport types with descriptions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that it 'lists' with 'descriptions', implying a read-only operation, but doesn't specify whether this requires authentication, has rate limits, returns structured data, or details about the output format. For a tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundant information. It's front-loaded and appropriately sized for a simple listing tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose but lacks details on output format or behavioral traits, which could be helpful for an agent to understand what to expect from the response. It meets the minimum viable threshold for this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, and the baseline for this scenario is 4, as it avoids redundancy while clearly stating the tool's function without unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all supported transport types with descriptions'), making the purpose immediately understandable. It doesn't specifically differentiate from sibling tools like 'list_protocols' or 'list_security', but the resource specificity is adequate for understanding what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_protocols' or 'list_security'. It simply states what it does without context about appropriate use cases or prerequisites, leaving the agent to infer usage based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate an Xray configuration for syntax and semantic errors
| Name | Required | Description | Default |
|---|---|---|---|
| config | Yes | Xray configuration object to validate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool validates for errors but doesn't describe what happens during validation—e.g., whether it returns detailed error messages, if it's read-only or has side effects, or any performance considerations like rate limits. For a validation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'Validate an Xray configuration for syntax and semantic errors.' It is front-loaded with the core purpose, has zero wasted words, and is appropriately sized for a straightforward tool. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of validating configurations (which can involve detailed error reporting) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success/failure status, error details) or any behavioral traits. For a validation tool, this omission makes it inadequate for an agent to fully understand how to interpret results or handle errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'config' parameter documented as 'Xray configuration object to validate.' The description adds minimal value beyond this, as it doesn't elaborate on the structure or format of the configuration object. Since the schema already provides adequate documentation, the baseline score of 3 is appropriate, reflecting that the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Validate an Xray configuration for syntax and semantic errors.' It specifies the verb (validate) and resource (Xray configuration) with the scope of checking both syntax and semantics. However, it doesn't explicitly differentiate from sibling tools like 'generate_client_config' or 'list_protocols', which serve different purposes rather than being validation alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as whether the configuration should be pre-generated or if this is a standalone validation step. With siblings like 'generate_client_config' that might produce configurations, there's no indication of how validation fits into the workflow or when to choose validation over generation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0generate_client_configgenerate_passwordgenerate_server_configgenerate_short_idgenerate_ss2022_keygenerate_uuidgenerate_x25519_keypairlist_protocolslist_reality_targetslist_securitylist_transportsvalidate_configScored across 12 tools
Each tool has a clearly distinct purpose with no overlap: configuration generation, password/key/UUID generation, protocol/security/transport listing, and validation. The descriptions clearly differentiate them, such as generate_client_config vs. generate_server_config, and list_protocols vs. list_transports vs. list_security.
All tools follow a consistent verb_noun pattern (e.g., generate_client_config, list_protocols, validate_config). The naming is uniform throughout, using snake_case and clear verbs like 'generate', 'list', and 'validate' without any deviations or mixed conventions.
With 12 tools, the count is well-scoped for an Xray configuration server, covering key areas like generation, listing, and validation. Each tool serves a specific function in the domain, and there are no extraneous or missing tools that would make the set feel too thin or bloated.
The tool set provides complete coverage for Xray configuration management: it includes generation tools for all necessary components (configs, passwords, IDs, keys), listing tools for protocols, transports, and security, and a validation tool. There are no obvious gaps, and agents can perform full configuration workflows without dead ends.
Drop-in proxy keeping OpenAI Assistants API calls working past the August 26, 2026 sunset, plus a Th
LLM chat, text tools, image generation, editing, batch image jobs, and asynchronous video generation
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
