Xray MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 3.3/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![xray-mcp MCP server](https://glama.ai/mcp/servers/clcc2019/xray-mcp/badges/card.svg)](https://glama.ai/mcp/servers/clcc2019/xray-mcp)

Score Badge

Copy to your README.md:

[![xray-mcp MCP server](https://glama.ai/mcp/servers/clcc2019/xray-mcp/badges/score.svg)](https://glama.ai/mcp/servers/clcc2019/xray-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clcc2019/xray-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server