qnexus-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource and action: auth status and whoami separate session validity from user identity; list_devices and device_status distinguish enumeration from specific status; job tools (list, status, cost, results) each serve a unique query purpose. No two tools overlap in what they retrieve.
Naming Consistency4/5
All tools share the 'nexus_' prefix and mostly follow a verb_noun (list_devices, get_quota) or resource_status (job_status, device_status) pattern. The 'whoami' tool deviates slightly from the pattern, but the naming remains predictable and readable.
Tool Count5/5
10 tools is a well-scoped count for a quantum computing platform, covering auth, devices, projects, quotas, and jobs without unnecessary bloat. Each tool earns its place for typical query workflows.
Completeness2/5
The set is heavily read-only, covering queries for auth, devices, projects, quotas, and job status/results, but lacks any tool to submit, cancel, or manage jobs or projects. This is a significant gap for a platform presumably intended to run quantum workloads, limiting agent capability.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 63 commits in the last 12 weeks
- Last stable release on July 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the word 'remaining', implying a usage/quota snapshot, but does not disclose details like whether quotas reset or are separate for compilation vs simulation. This is adequate but minimal beyond annotations.
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 concise sentence that is front-loaded with the action and resource. No unnecessary words or filler.
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 (no parameters) and the existence of an output schema, the description is mostly complete. It states what is returned (remaining quotas). However, it could clarify whether 'compilation' and 'simulation' are separate quota values or combined, but this is minor and likely visible in the 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, so the baseline is 4. The schema already indicates no parameters, and the description does not need to add anything. It is clear that no input is required.
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 'Return' and clearly identifies the resource as 'remaining compilation/simulation quotas'. This distinguishes it from sibling tools like nexus_list_jobs or nexus_job_cost, which serve different purposes.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks context such as 'use before starting a build' or any exclusions, leaving the agent to infer the use case solely from the tool name.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a non-destructive read. The description adds no further behavioral details (e.g., error behavior or auth), but given the annotations cover safety, the minimal description is acceptable.
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 one short sentence with no filler. It is immediately clear and 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?
The tool is low-complexity with one parameter and an output schema. The description plus annotations provide enough context for the agent to invoke it correctly. No additional return values or error handling are needed since the output schema exists.
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 has one parameter (job_id) with no description (0% coverage). The description's 'by id' clarifies that job_id is the identifier, but it doesn't elaborate on format or valid values. For a simple parameter, this adds marginal value 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 uses the specific verb 'Return' with the resource 'status of a job', and specifies lookup by 'id'. This clearly distinguishes it from siblings like nexus_list_jobs (listing) and nexus_job_cost (cost).
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 gives no explicit guidance on when to choose this tool over alternatives. It implies usage for checking job status but lacks any mention of preconditions or situations where other tools would be more appropriate.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral essence (session validity check) but provides no extra context about edge cases like expired sessions or required privileges, which is acceptable given the tool's simplicity.
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?
One short, front-loaded sentence conveys the complete purpose without any wasted words. Ideal conciseness.
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 absence of parameters, the presence of an output schema, and comprehensive annotations, the description is adequately complete. It could mention how to interpret the report (e.g., boolean vs status string), but the output schema likely covers this, so the description suffices.
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 zero parameters, so the baseline is 4. The description correctly avoids inventing parameters, and no additional semantic explanation is needed.
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 'Report' and a clear resource 'whether a valid Nexus session exists', which precisely defines the tool's function. It distinguishes from siblings like nexus_whoami (identity) and nexus_device_status (device-specific) by focusing on session validity.
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 purpose clearly implies usage as a pre-check for authentication, but there is no explicit guidance on when to use this tool versus alternatives like nexus_whoami. The context is implied rather than stated with exclusions or alternative recommendations.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a small constraint that the job must already exist ('existing job'), but does not describe error handling or other behaviors. It does not contradict the annotations, but also offers minimal extra 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?
A single, concise sentence delivers all necessary information: the action, resource, and required input. There is no redundancy or filler, making it optimally concise and well-structured.
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, the existence of an output schema (which documents return values), and rich annotations, the description is sufficiently complete. It clearly states the input requirement and purpose. The only minor gap is the lack of error behavior or cost format, but these are not essential for a simple read-by-id operation.
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%, and the description only says 'by id', which does little beyond the parameter name job_id. However, the parameter is simple and self-explanatory, and the phrase 'existing job' implies the ID must refer to a valid job, adding slight semantic value. It does not fully compensate for the lack of schema documentation, but the parameter is straightforward.
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 ('Return') and the resource ('HQC cost of an existing job'), with a precise scope ('by id'). It is distinct from sibling tools like nexus_job_status and nexus_get_results, which focus on status or results respectively, making the purpose unambiguous.
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 gives a clear context: use this when you need the HQC cost for a specific job ID. It does not explicitly mention when not to use it or alternatives, but the context is so specific that usage is evident. The lack of exclusions is acceptable given the tool's narrow scope.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a meaningful behavioral trait beyond these annotations: emulators/syntax checkers are always available, which is specific to this status checker and useful for the agent. No contradictions with annotations.
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 short sentences, with the primary purpose stated first and the second sentence adding a relevant caveat. There is no wasted or redundant information, and the structure is ideal for quick comprehension.
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, strong annotations, and the presence of an output schema, the description provides sufficient context: it states the core purpose and a key behavioral nuance. The lack of parameter detail is a minor gap, but overall the description is complete for a straightforward status-check tool.
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 schema has a single required parameter 'device' with no description (0% coverage). The description does not explain what values or format 'device' should take, leaving the agent to infer from the tool name. With schema coverage so low, the description should compensate but does not, making parameter semantics unclear.
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: reporting whether a device is online. It uses a specific verb ('Report') and resource ('device'), and distinguishes itself from siblings like nexus_list_devices and nexus_auth_status by focusing on status rather than listing or auth. The added note about emulators/syntax checkers reinforces the specific scope.
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 gives clear context for when to use the tool—checking device online status—and includes a useful caveat that emulators/syntax checkers are always available, which informs expected behavior. However, it does not explicitly name alternatives or state when not to use this tool, so it lacks explicit exclusions.
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?
Annotations already declare the tool as readOnly and non-destructive. The description adds the semantic detail of 'available' and 'status' but does not disclose any additional behavioral traits such as pagination or output format. This is acceptable given the annotations.
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?
A single sentence with no redundant words, front-loading the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, a strong annotation set, and an output schema present, this simple list tool is fully described by the one-line description.
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?
Tool has zero parameters, so there is no parameter information needed. The description doesn't need to compensate, earning a baseline 4.
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 the specific verb 'List' and names the resource 'available backends' with their status, clearly distinguishing this from sibling tools like nexus_device_status which likely query a specific device.
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 is for enumerating backends but does not explicitly state when to use it over alternatives like nexus_device_status or nexus_list_projects. No exclusions or conditions are provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description is consistent with these and adds that it returns the user, but provides no additional behavioral context such as error handling or authentication requirements. The annotations carry the burden, and the description adds minimal extra value.
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 that is front-loaded with the action and resource, containing no superfluous words. It is concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is extremely simple with no parameters and has an output schema present. The description sufficiently conveys the purpose, and the annotations cover safety and idempotency. For a zero-parameter read-only tool, this description is 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 0 parameters, so the baseline is 4. Schema description coverage is 100% (vacuously), and there are no parameter semantics to explain. The description does not need to add parameter information.
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 the specific verb 'Return' and the resource 'authenticated Nexus user', clearly stating the tool's function. It distinguishes from sibling tools like nexus_auth_status by focusing on the user identity rather than authentication status.
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?
No explicit guidance is provided on when to use this tool versus alternatives such as nexus_auth_status. The purpose implies its use for retrieving the current user, but the description lacks any when-to-use or exclusion statements, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: counts are capped at --max-outcomes, truncation is reported via total_outcomes/omitted_outcomes/omitted_shots, and multi-circuit jobs return one entry per circuit in submission order. This enriches the read-only/idempotent annotation without contradiction.
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 purpose, followed by concise details about capping and multi-circuit behavior. Every sentence earns its place with no waste.
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 description covers key behaviors like capping, truncation reporting, and batch ordering. It does not specify behavior for invalid or non-completed jobs, but the presence of an output schema likely fills return-value gaps, making this reasonably complete.
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 only parameter is job_id, which is a string per the schema. The description merely says 'by id', adding no meaningful semantic beyond the parameter name and schema. With 0% schema description coverage, the description should have compensated but does not.
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 returns measurement counts for a completed job by id, using a specific verb and resource. It distinguishes from siblings like nexus_job_status (status) and nexus_job_cost (cost) by focusing on measurement counts.
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 for completed jobs to retrieve measurement counts, providing clear context. It does not explicitly name alternatives or exclusions, but the purpose is distinct enough among the sibling tools.
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?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds behavior beyond annotations: it returns one page with a total count, and it may occasionally fail with transient server errors. This is useful operational context, though it does not cover auth or rate limits.
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 compact sentences, front-loaded with the core action. Each sentence adds value: function, filters, and error-handling guidance. No wasteful wording.
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?
With an output schema present and simple read-only behavior, the description sufficiently covers pagination, filtering, and error avoidance. It does not detail sort order or exact filter interaction, but these are not necessary for basic invocation.
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 0%, so the description must compensate. It explains all four parameters: limit as page size, project as exact name, status with example values, and name_like as a substring. It does not explicitly describe null/default behavior or how filters combine, but the main semantics are clear.
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: list jobs visible to the user, with pagination details. It distinguishes itself from sibling tools like nexus_job_status and nexus_get_results by focusing on a list operation with filters rather than single-job 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 provides when-not-to-use guidance and alternatives: in case of a Nexus-side server error, use nexus_job_status or nexus_get_results by id instead of retrying. It also mentions optional filters, which implies when to apply them.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: the one-page limit with total count, and how the archived flag changes results. This goes beyond what annotations provide, though it doesn't address potential rate limits or permission 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 compact and effectively front-loaded. The first sentence states the primary purpose and key behavior (one page and total count); the second sentence covers all optional filters. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 (3 optional parameters, rich annotations, and an output schema), the description covers all essential aspects: the resource listed, visibility scope, pagination, total count, and filter options. It does not need to detail return values since an output schema exists, making it complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to each parameter beyond the schema: it explains that 'limit' controls the page size and that the response includes a total count, 'name_like' is a substring filter, and 'archived' toggles the listing to archived projects. This is valuable since the schema itself lacks property 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: 'List Nexus projects visible to the user'. It uses a specific verb (List), identifies the resource (Nexus projects), and adds scope ('visible to the user'). The mention of pagination and total count further distinguishes it from sibling list tools like nexus_list_jobs and nexus_list_devices.
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 when to use the tool (to list projects) and provides context on pagination and filtering options ('Optional name_like substring filter; set archived to list archived projects instead'). However, it does not explicitly name alternatives or state when not to use it, so it falls short of the highest bar.
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:

[![qnexus-mcp MCP server](https://glama.ai/mcp/servers/Blite-HQ/qnexus-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Blite-HQ/qnexus-mcp)

Score Badge

Copy to your README.md:

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

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