mcp-xray

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 resource and action: connection check, GraphQL query, import results, and CRUD operations for test executions and test plans. There is no overlap or ambiguity between tools.
Naming Consistency4/5
Most tools follow the consistent xray_verb_noun pattern (e.g., get_test_plan, search_test_executions, create_test_execution). The exception is xray_graphql, which breaks the verb_noun convention but is still identifiable.
Tool Count5/5
With 9 tools covering connection, querying, importing results, and managing test executions/plans, the server is well-scoped. Each tool serves a clear purpose without over-fragmentation.
Completeness3/5
The server covers create, get, and search for both test executions and test plans, plus import and GraphQL queries. However, it lacks update and delete operations for these entities, which are common lifecycle operations and would require workarounds.
Average 4/5 across 9 of 9 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 is passing
This repository is licensed under MIT 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?
No annotations are provided, so the description carries full responsibility. It only says 'Creates a new Test Execution issue' but does not disclose permission requirements, potential side effects, rate limits, or what the response contains. For a mutating tool, this is a significant transparency 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 only two sentences, front-loaded with the core purpose and immediately followed by usage requirements. Every sentence adds necessary information without 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?
For a create tool with no output schema or annotations, the description covers the main intent and parameters but omits return values, error scenarios, and any post-creation side effects. The parameter documentation is complete, but the overall context feels minimally adequate.
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 coverage is 100%, so each parameter is already documented. The description reiterates required vs optional and gives an example for 'fields', but the schema already includes a similar example. Thus it adds minimal value beyond the schema, matching the baseline for full coverage.
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 uses a specific verb ('Creates') and resource ('Test Execution issue in Jira/Xray'), clearly stating the tool's action and output. This distinguishes it from sibling tools like xray_create_test_plan and xray_get_test_execution.
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?
It clearly states required inputs ('Requires a project key and summary') and optional parameters ('description and additional Jira fields'), which helps the agent know prerequisites. However, it does not explicitly mention when to use this over alternatives, though the resource type offsets this somewhat.
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 must carry the burden of behavioral disclosure. It adds the cloud-deployment restriction but does not state whether mutations are allowed, how auth works, what errors or response shape to expect, or any rate limits. This is a significant gap for an arbitrary GraphQL executor.
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 two sentences with the action and constraint front-loaded, followed by concrete usage examples. Every word earns its place and there is no 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?
The description covers purpose, usage, and a critical environment constraint (cloud-only), but given the tool's complexity, no output schema, and no annotations, it omits important behavioral details such as response format, error handling, and mutation safety. It is adequate for selection but not fully complete.
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 both parameters. The description adds context about intended query content but not additional parameter-level syntax or variable formatting; baseline 3 is appropriate.
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?
Description states a specific verb ('Executes') and resource ('GraphQL query against Xray Cloud'), then lists concrete use cases (test runs, test steps, preconditions, test sets). This clearly distinguishes it from sibling tools, which target specific Xray endpoints or operations.
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?
Provides explicit instruction: 'Use this for advanced Xray-specific queries like...' which tells when to choose this tool. However, it does not explicitly state when not to use it or mention alternatives like the sibling CRUD tools, so it lacks full exclusions.
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 disclosing side effects. It states 'Imports' (a mutation) but does not explain whether this creates a new Test Execution when no testExecKey is given, whether results are replaced or appended, or any permission/state-change details. The mention 'Optionally target... existing Test Execution issue' hints at behavior but is vague. This is a significant gap for a mutation 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 two sentences, with the main purpose front-loaded and supporting details following. Every sentence adds information: the supported formats and the required/optional inputs. There is no redundancy or wasted words.
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 (4 params, no output schema, no annotations), the description covers the essential usage: what formats are accepted and what to provide. However, it omits critical behavioral context such as the default behavior when no existing Test Execution key is provided (does it create a new one?), and it does not describe the return value or error scenarios. While an agent can likely invoke the tool correctly with the given information, the lack of these details makes it adequate but not thorough.
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 four parameters. The description adds little beyond that: it repeats the format list (already an enum) and the concept of 'full report content'. It does clarify the purpose of projectKey and testExecKey ('target a specific project or existing Test Execution'), which is a minor addition, but overall the description does not significantly enhance understanding beyond the schema.
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 action: 'Imports automated test execution results into Xray.' It lists supported formats and mentions targeting a specific project or existing Test Execution, distinguishing it from sibling tools like xray_create_test_execution which likely creates empty test executions. This is a specific verb+resource+target that differentiates the tool.
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 provides clear context: use this when you have a test report in one of the listed formats and want to bring it into Xray. It explains what to provide ('full report content as a string') and notes optional targets. However, it does not explicitly mention when NOT to use it or point to alternatives such as xray_create_test_execution for creating a new issue without results, so it falls short of a 5.
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 carries the transparency burden. It discloses that the tool returns 'full Jira issue details' and that the 'fields' parameter limits output, which is useful. However, it does not describe authentication needs, error behavior, or the exact response structure, leaving some behavioral gaps for a read operation.
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 three concise sentences, front-loaded with the main purpose. It includes examples and parameter guidance without any unnecessary words, earning a high score for efficiency.
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 read tool with no output schema, the description is reasonably complete. It explains the core behavior, the required parameter, and the optional fields filter. It lacks explicit details on errors or permissions, but given the low complexity and the presence of sibling tools that cover other scenarios, it is adequately complete for an agent to use the tool correctly.
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 coverage is 100%, so the baseline is 3. The description adds a brief explanation of the 'fields' parameter ('limit which fields are returned') and provides example issue keys, but it does not add significant new meaning beyond the schema's existing parameter descriptions.
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 function: 'Fetches a single Test Execution issue from Jira by its issue key'. It uses a specific verb ('Fetches') and resource ('Test Execution issue'), includes example keys, and distinguishes it from sibling tools like search or create by focusing on a single issue retrieval.
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 when you have an issue key and want a single Test Execution, and it gives guidance on the 'fields' parameter. However, it does not explicitly mention when to use this tool over alternatives (e.g., xray_search_test_executions) or provide exclusions, so guidance is implied rather than explicit.
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 carries the full burden. It transparently states the creation side effect and required inputs, but does not disclose return values, permissions, or potential side effects beyond creating an issue. This is adequate but not rich.
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 two concise sentences, front-loaded with the core action and domain. Every clause earns its place—required and optional parameters are mentioned 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 moderate complexity (4 params, nested fields) and lack of output schema/annotations, the description covers the essential invocation context: what it creates, where, and what inputs are needed. It could mention return value or error behavior, but the schema covers parameters thoroughly.
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 schema already provides complete descriptions for all four parameters, including examples for fields. The description's mention of 'project key and summary' and 'labels, components' adds no new semantic meaning beyond the schema, so a baseline score of 3 is appropriate.
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 uses a specific verb and resource: 'Creates a new Test Plan issue in Jira/Xray.' This clearly differentiates the tool from siblings like xray_create_test_execution and xray_get_test_plan, making its purpose immediately obvious.
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 states what is required ('project key and summary') and optional ('description and additional Jira fields'), giving clear invocation context. However, it does not explicitly mention alternatives or when not to use this tool versus xray_create_test_execution or search tools.
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 behavior ('Returns the full Jira issue details') and the fields-limiting feature, but does not mention potential errors, authentication requirements, or side effects. This is basic transparency but not comprehensive.
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?
Two sentences, front-loaded with the core purpose, followed by a useful parametric note. No repetitive or extraneous content; every phrase earns its place.
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 tool with two straightforward parameters and no nested objects, the description is adequate. It tells the user exactly how to invoke it and what to expect. It does not elaborate on error cases or permissions, but these are less critical given the tool's simplicity.
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 for both parameters, including examples. The description reinforces the 'fields' parameter's purpose but adds no new semantic details beyond the schema, so the baseline of 3 applies.
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 ('Fetches a single Test Plan issue from Jira'), the resource ('Test Plan issue'), and the method ('by its issue key'). This distinguishes it from sibling tools like xray_search_test_plans and xray_get_test_execution, which target different resources or use search semantics.
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 provides clear context: use this when you have a known issue key and need a single Test Plan issue. It also explains the optional 'fields' parameter for limiting output. However, it does not explicitly mention when to use alternatives (e.g., search) or state exclusions, stopping short of a 5.
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 carries the burden. It usefully discloses that the issuetype filter is applied automatically and gives an example. However, it does not cover other behavioral aspects such as pagination, return format, authentication needs, or the read-only nature of the operation, which would be valuable for a search 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 two sentences, front-loaded with the main purpose, and every part earns its place. It includes a practical example without bloat.
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 no annotation and no output schema, the description covers the essential purpose, parameter usage, and an example. It does not describe the return value shape, which would be helpful for an agent, but the tool's simplicity and good param descriptions keep it mostly 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the intended use of key parameters ('projectKey' filtering by project, 'jql' for additional conditions, 'orderBy' for sorting) and provides a concrete example, going beyond the schema's basic descriptions.
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 action ('Searches'), a specific resource ('Test Plan issues in Jira'), and the mechanism ('using filters'). It clearly distinguishes from sibling tool xray_search_test_executions by focusing on Test Plans. The automatic issuetype filter is mentioned, adding specificity.
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?
Provides explicit guidance on key parameters ('projectKey', 'jql', 'orderBy') and a concrete example. It implies when to use this tool (for Test Plan searches) but does not explicitly contrast with alternatives like xray_search_test_executions or xray_get_test_plan, nor does it state when not to use it.
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 carries the full burden of behavioral disclosure. It states the tool validates authentication, which implies a read-only operation, but does not disclose whether it mutates any state, what happens on failure, or if it has side effects like rate limiting or logging. This is adequate for a simple check tool but lacks explicit safety or failure behavior details.
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 two sentences long, front-loaded with the primary action. Every sentence earns its place: the first states what the tool does, and the second provides usage guidance. There is no redundancy or irrelevant detail.
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?
This is a simple zero-parameter tool with no output schema, so the description should explain return values or success/failure conditions. It does not explicitly state what the tool returns (e.g., boolean, message, error). The description is sufficient for basic understanding but lacks details about the outcome of the validation, which is a gap given the absence of an output 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 zero parameters, and the schema is empty, so schema coverage is trivially 100%. Per the rubric, a baseline of 4 is applied for zero-parameter tools. The description adds no parameter information, which is acceptable because there are no parameters to describe.
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 purpose: 'Validates authentication against the configured Xray deployment (cloud or datacenter) and Jira instance.' This is a specific verb+resource combination that distinguishes it from sibling tools like xray_get_test_execution or xray_create_test_plan, which focus on test data operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this first to verify credentials are working before using other tools.' This provides a clear usage context and sequencing, telling the agent when to invoke this tool relative to others. It implies that other tools should only be used after this check succeeds, though it doesn't name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 reveals that the issuetype filter is applied automatically and warns not to include 'issuetype' or 'ORDER BY' in jql, which is critical for correct usage. It also gives an example, but does not describe pagination or the default return fields beyond what schema notes.
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 concise and front-loaded with the core purpose, then delivers practical usage details in three sentences. Every sentence provides useful information without repetition or fluff.
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 tool with 5 optional parameters and no output schema, the description covers the main usage contexts well, including filters, sorting, and examples. However, it omits details about default return fields and pagination behavior, which are relevant for a search tool, but the schema provides maxResults bounds.
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?
Schema coverage is 100% with detailed per-parameter descriptions, so baseline is 3. The description adds value by providing a full usage example and emphasizing the automatic issuetype filter, which is not explicit in the schema. This enhances understanding of how parameters work together.
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 'Searches for Test Execution issues in Jira using filters,' using a specific verb and resource. It distinguishes itself from siblings like xray_search_test_plans (which searches test plans) and xray_get_test_execution (which retrieves a specific execution).
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 provides clear usage context with concrete examples for projectKey, jql, and orderBy, and explains how filters combine. However, it does not explicitly contrast this with alternatives (e.g., when to use xray_get_test_execution instead), so it lacks explicit when-not-to-use guidance.
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:

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

Score Badge

Copy to your README.md:

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

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/Mammals-at-work/mcp-xray'

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