xray-mcp-monitor

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: creation, one-time check, listing, retrieval, manual run, enable/disable, and deletion. While run_monitor_now and check_subscription_once both perform connectivity checks, the former applies to an existing monitor while the latter is standalone, and descriptions clearly disambiguate them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern using snake_case, with clear verbs such as register, check, list, get, run, set, and remove. The naming is uniform and predictable.
Tool Count5/5
Seven tools is well-scoped for a monitoring server, covering the full lifecycle without redundancy. Each tool serves a clear purpose and the count is neither too sparse nor overwhelming.
Completeness4/5
The tool set covers the full CRUD lifecycle (register, list/get, remove, set_enabled) plus a one-time check and manual run. The only notable gap is the lack of an update tool for modifying a monitor's subscription URL or schedule, but this is a minor limitation that can be worked around by removing and re-registering.
Average 3.1/5 across 7 of 7 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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, the description carries the full burden of behavioral disclosure. It does not explain side effects, whether the action is asynchronous, whether it requires special permissions, or what consequences 'running a monitor' has. The word 'immediately' hints at direct execution but provides no further detail.
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 concise sentence with no wasted words. It is front-loaded and easy to parse, though its brevity results in under-specification rather than elegant conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of sibling tools and a required parameter, the description is severely incomplete. It fails to explain what a monitor run entails, how it relates to other subscription-monitor operations, or what the output schema represents. The agent is left without sufficient context to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (watch_id) with 0% description coverage. The description does not mention watch_id or any parameter semantics, leaving the agent to infer its meaning solely from the name 'watch_id' without additional 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 states a specific action ('Run') on a specific resource ('a monitor') with a temporal qualifier ('immediately'). However, it does not differentiate from sibling tools, particularly 'check_subscription_once', which may also trigger a one-time check, leaving ambiguity about the exact distinction.
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?
No guidance is provided on when to use this tool versus alternatives. The description simply states the action without context, prerequisites, or exclusions, leaving the AI agent without clear decision criteria.
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, the description carries the full disclosure burden. 'Remove' indicates a likely destructive action, but it does not state permanence, permission needs, or side effects on scheduled jobs. Minimal transparency for a deletion operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The six-word description is extremely short and front-loaded, but the brevity sacrifices substantive detail. It is not padded, yet under-specification makes it less useful than a slightly longer, structured description.
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?
Despite a simple one-parameter, destructive operation, the description omits restoration mechanics, output/return behavior, and cannot differentiate from disabling. The presence of sibling tools and output schema do not compensate for these missing contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'watch_id' is only defined as a required string in the schema with 0% description coverage. The description never explains what watch_id refers to, where to obtain it, or its format, leaving the agent without sufficient information to populate it.
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 uses a clear verb ('Remove') and identifies the resource ('a scheduled monitor'), aligning with the tool name. It is not as specific as 'remove subscription monitor' but sufficient to distinguish from monitor listing/running tools.
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?
No guidance is provided on when to use this tool versus siblings like 'set_monitor_enabled' or 'run_monitor_now'. The description offers no context or exclusions, so the agent must infer intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 simply restates the action without explaining side effects, persistence, permission requirements, or what happens to the monitor when enabled/disabled. This is a significant gap for a mutating 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, front-loaded sentence that is easy to parse. It is appropriately concise for such a simple tool, though it sacrifices detail for brevity. No unnecessary words are present.
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 simplicity, the description is not entirely inadequate, but it lacks important context. It does not mention return values, whether the change is persistent, or any error conditions. With no annotations and an unhelpful schema, more explanation is needed for a complete picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions (0% coverage), and the description does not explain the meaning of 'watch_id' or 'enabled' beyond the implied toggle. The description adds no value to the parameter understanding, leaving the agent to guess at identifiers and boolean semantics.
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 ('Enable or disable') and the resource ('a scheduled monitor'), making its purpose unambiguous. It also distinguishes itself from siblings like run_monitor_now (executes immediately) and register_subscription_monitor (creates a new monitor), as it specifically toggles the enabled state.
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 does not mention prerequisites, exclusions, or cases where another sibling tool would be more appropriate. The intended context is only implicitly understood from the name and description.
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, the description carries the full burden of behavioral disclosure. It mentions 'one-time' (implying no persistence) but does not explain side effects (e.g., network request, potential subscription state changes), timeout behavior, or what constitutes success/failure. The description is too sparse for a network-involved tool.
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 sentence with no filler. It is concise and front-loaded with the action ('Fetch a subscription URL') followed by the purpose ('run a one-time connectivity check'). Every word contributes meaning.
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?
Despite the presence of an output schema, the description lacks sufficient context for a 3-parameter tool with no annotations. It does not explain what a subscription is, what a connectivity check entails, or the role of optional parameters. The tool is under-specified for reliable agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'subscription URL,' which maps to the `subscription_url` parameter, but it does not explain `timeout_seconds` or `node_name_keyword`. The word 'fetch' adds some context but leaves other parameters undocumented.
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 tool's action: 'Fetch a subscription URL and run a one-time connectivity check.' The verb 'run' and resource 'subscription URL' are specific. The phrase 'one-time' distinguishes it from sibling tools like `register_subscription_monitor` and `run_monitor_now`, which involve persistent or recurring checks.
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 a one-time ad-hoc check but does not explicitly state when to use this tool versus registering a monitor or triggering an existing one. There is no mention of alternatives or exclusions, so usage guidance is only implicit.
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 only states the basic operation ('List all registered scheduled monitors') with no mention of read-only nature, pagination, order, or potential side effects. The name implies a read operation, but the description itself adds no safety or behavioral context beyond the 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, direct sentence with no wasted words (six words total). It is appropriately minimal for a parameterless list tool and gets straight to the point without extraneous detail.
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?
The tool is very simple (no params) and has an output schema, so the description does not need to explain return values. The description covers the core function clearly, but it lacks differentiation from the similar 'get_subscription_monitor' and provides no usage context. Given the simplicity of the tool, this is a minor gap, so the description is nearly complete.
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 zero parameters, and the input schema is empty. The description implies that no arguments are needed, which aligns with the schema. Per the rubric, a zero-parameter tool receives a baseline score of 4, and the description does not need to add parameter details because there are none to explain.
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 'List' and the resource 'all registered scheduled monitors', making its purpose unambiguous. It is concise and uses specific language, though it does not explicitly differentiate from the sibling tool 'get_subscription_monitor'. The word 'all' implies listing versus retrieving a single monitor, but that distinction is not made explicit.
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 'get_subscription_monitor' or how it relates to other monitor management tools. There is no mention of prerequisites, use cases, or exclusions, leaving the agent without directional context for tool selection.
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 burden of disclosing side effects. It reveals the creation of a persistent scheduled monitor, but gives no details on idempotency, permissions, rate limits, or what happens at each scheduled run. This is minimal but not misleading.
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 no filler. Every word adds meaning, and it is front-loaded with the action ('Create...').
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?
The tool has moderate complexity (4 params, 1 required) and no annotations, yet the description only covers the core action. It omits parameter meaning, scheduling behavior, and any caveats, making it incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. It only implicitly touches on subscription_url ('subscription URL'), leaving timeout_seconds, interval_seconds, and node_name_keyword unexplained. This fails to compensate for the schema's lack of detail.
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 'Create a scheduled connectivity monitor for an Xray subscription URL,' using a specific verb (create) and resource (scheduled monitor). It distinguishes from siblings like check_subscription_once by emphasizing 'scheduled' and 'monitor' rather than a one-time check.
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 this tool is for setting up recurring monitoring but does not explicitly state when to use it versus alternatives. It lacks a clear 'when-not-to-use' or mention of sibling tools like check_subscription_once for one-off checks.
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, the description must carry the burden of behavioral disclosure. It states that the result includes the latest stored result, which is useful, but it does not mention error behavior, authentication, or side effects. The 'Get' verb implies a read-only operation, but no deeper transparency is provided.
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, clearly worded sentence that immediately conveys the tool's action and key detail. No wasted words, and the most important information is front-loaded.
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?
For a simple retrieval tool with one parameter and an output schema, the description is sufficient: it identifies the resource, the key behavior (latest stored result), and the selection mechanism. Some details like what a monitor is or where watch IDs come from are omitted, but sibling tool names and context fill in gaps.
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 0%, so the description must compensate. It clarifies that 'watch_id' is the identifier used to select the monitor, which adds some context beyond the raw schema, though it largely restates the parameter name and does not explain the format or origin of watch IDs.
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 states a specific verb ('Get'), resource ('monitor'), and identifier type ('watch ID'), and adds that it includes the latest stored result. This distinguishes it from siblings like list_subscription_monitors (which lists all) and remove_subscription_monitor (which deletes).
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 phrase 'by watch ID' clearly implies the tool is for retrieving a single, known monitor, as opposed to listing all monitors or running checks. While no explicit alternatives or exclusions are named, the context of a specific identifier provides clear usage context.
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/i-zrhe2016/xray-mcp/badges/card.svg)](https://glama.ai/mcp/servers/i-zrhe2016/xray-mcp)

Score Badge

Copy to your README.md:

[![xray-mcp MCP server](https://glama.ai/mcp/servers/i-zrhe2016/xray-mcp/badges/score.svg)](https://glama.ai/mcp/servers/i-zrhe2016/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/i-zrhe2016/xray-mcp'

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