qnexus-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QNEXUS_MCP_PROJECTS | No | Comma-separated project allowlist, enforced on every mutating tool | |
| QNEXUS_MCP_TOOLSETS | No | Capability domains to expose (read,execute,manage,destructive) | read |
| QNEXUS_MCP_ALLOW_SPEND | No | Permit credit-spending (HQC) execution | false |
| QNEXUS_MCP_MAX_CREDITS | No | Hard per-call HQC ceiling; 0 blocks all spend | 0 |
| QNEXUS_MCP_MAX_OUTCOMES | No | Top-N cap on distinct measurement outcomes returned per result (truncation is always reported) | 100 |
| QNEXUS_MCP_ALLOW_HARDWARE | No | Permit real-QPU targets | false |
| QNEXUS_MCP_ALLOW_DESTRUCTIVE | No | Permit delete/cancel/archive | false |
| QNEXUS_MCP_MAX_SUBMISSIONS_PER_MINUTE | No | Sliding-window submission cap; each circuit in a batch counts as one | 6 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nexus_auth_statusA | Report whether a valid Nexus session exists. |
| nexus_whoamiA | Return the authenticated Nexus user. |
| nexus_list_devicesA | List available backends and their status. |
| nexus_device_statusA | Report whether a device is online. Emulators/syntax checkers are always available. |
| nexus_list_projectsA | List Nexus projects visible to the user (one page of up to Optional |
| nexus_get_quotaA | Return remaining compilation/simulation quotas. |
| nexus_list_jobsA | List jobs visible to the user (one page of up to Optional filters: exact |
| nexus_job_statusA | Return the status of a job by id. |
| nexus_job_costA | Return the HQC cost of an existing job by id. |
| nexus_get_resultsA | Return measurement counts for a completed job by id. Counts are capped at the top --max-outcomes outcomes by frequency; total_outcomes /
omitted_outcomes / omitted_shots report any truncation. Multi-circuit (batch) jobs return
one entry per circuit under |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
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.
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.
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.
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.