tech.xns/relayer
NPM · @XNS-CLOUD/RELAYER-MCP
Conversationally set up & manage an XNS Relayer over stdio: install, claim, VPD, S3, backups.
Available components
Last scanned (2 minutes ago)
Scores higher than 97% of npm servers
Category Cloud Infrastructure
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security99
- No malware found by supply-chain analysis.Pass
- No known CVEs affecting this package version or its production dependencies.Pass
- No install/post-install scripts declared.Pass
- 33 of 131 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency97
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Cryptographically verified build provenance (signed, bound to scpcorp/relayer-mcp). View diagnostics → Pass
- Clear OSI-approved license (Apache-2.0).Pass
- Actively maintained (last published 27 days ago).Pass
- Security-disclosure policy not yet verified: we couldn't inspect the source repository.Unverified
Schema Quality & AI Usability69
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 2891 tokens (~192/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management100
- No destabilizing schema changes in the last 30 days.Pass
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- We read all 15 captured tool definition(s), and no name or description among them implies an irreversible operation.Pass
- An AI judge read all 15 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 31 Oct 26 +1
- Stability: 0.97 → pass security
- 29 Oct 26 −1
- Stability: pass → 0.93 functional
- 17 Oct 26 +1
- Stability: 0.97 → pass security
- 15 Oct 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 90 to 93. That category is still filling its 30-day observation window: 27 days of observed history at the previous scan, 28 at this one. The score rises as the window fills, whether or not the server changes.
- 14 Oct 26 +43
- Injection markers: unverified → pass ▲ security
- Tool coverage: unverified → 100 ▲ functional
- MCP protocol: unverified → pass ▲ functional
- Stability: unverified → 0.90 ▲ functional
- Package version: 0.11.1 → 0.12.0 functional
- 11 Oct 26 −42
- Stability: 0.80 → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Package version: 0.11.1 → 0.12.0 functional
- 4 Oct 26 +12
- Malware scan: unverified → pass ▲ security
- Stability: pass → 0.80 functional
- 3 Oct 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 0.10.2 → 0.11.1 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 5 Nov 2026 · Analysed npm/@xns-cloud/relayer-mcp@0.12.0
Provenance Verified
A signed build attestation was found and verified, binding this exact artifact to the source repository it claims to come from.
| Result | Verified |
|---|---|
| Ecosystem | npm |
| Reason | Verified |
| Discovered via | Registry attestation endpoint |
| Source repo | scpcorp/relayer-mcp |
| Certificate issuer | https://gitlab.com |
| Certificate SAN | https://gitlab.com/scpcorp/relayer-mcp//.gitlab-ci.yml@refs/tags/v0.12.0 |
| Rekor log index | 3148618721 |
| Predicate type | SLSA build provenance https://slsa.dev/provenance/v0.2 |
| Subject digest | sha512:3c02e5ae362a4221e5aee164472f1fb66af922488062320f62ad40ef804b692e0e4bedf2f5b18891c0f32a9354ed0de6172ac552db317353b3a9c94be |
Background: How many MCP packages publish verified provenance →
Dependencies 131 packages
| Packages resolved | 131 |
|---|---|
| Stale | 33 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
check_claim_status ~113
Poll the status of a claim session. Checks every 10 seconds. States: STATE_1 (pending — user has not yet opened the claim URL), STATE_2 (in progress — user is completing the claim in browser), STATE_3 (completed — claim successful). Automatically proceeds when STATE_3 is reached.
| Name | Type | Req | Description |
|---|---|---|---|
| claim_id | string | yes | The claim_id returned by start_claim |
| timeout_ms | integer | – | Maximum time to poll in milliseconds (default: 10 minutes, max 1 hour) |
No output schema declared.
No examples provided.
check_email_verified ~88
Poll to check if the user has verified their email address. Automatically polls every 15 seconds for up to 30 minutes. Returns immediately if already verified. If the email has no account, indicates registration is needed.
| Name | Type | Req | Description |
|---|---|---|---|
| string | yes | Email address to check verification status | |
| poll | boolean | – | If true (default), poll until verified or timeout. If false, check once. |
No output schema declared.
No examples provided.
check_prerequisites ~172
Check system prerequisites for XNS Relayer installation: Docker installed and its daemon running (local or remote via DOCKER_HOST / ssh:// context), the Docker compose plugin, docker group access for this user, required ports (8888, 9000, 9443; a port held by the running xns-relayer container passes), no container from another project named prometheus or alertmanager, an existing xns-relayer installation, at least 10 GB free on the Docker root and the install directory, and network connectivity to console.xns.tech and auth.xns.tech. Also fails the check when the Docker daemon is on another machine (install_file_location), because install_relayer refuses in that case; run the MCP on the Docker host instead. Run this first before any other relayer tool.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
check_relayer_health ~246
Check the health of all Relayer services: UI (port 8888), S3 gateway (port 9000), HostIO, and the monitoring sidecars (Prometheus + Grafana containers). Polls every 10 seconds for up to 300 seconds. Reports each component status individually and names any unhealthy component; a missing monitoring stack reports as degraded (dashboards empty) without blocking the install flow. Targets the machine the Docker daemon runs on (auto-detected from the Docker context — supports remote ssh:// Docker hosts); pass host to override. Note: HostIO health status is unknown until OIDC authentication is completed.
| Name | Type | Req | Description |
|---|---|---|---|
| host | string | – | Hostname/IP where the Relayer containers run. Default: auto-detected from the Docker context (localhost, or the remote host for ssh:// / tcp:// contexts). |
| poll | boolean | – | If true (default), poll until healthy or timeout. If false, check once. |
| s3_port | integer | – | Host port for the S3 API (matches install_relayer s3_port) |
| ui_port | integer | – | Host port for the Relayer UI (matches install_relayer ui_port) |
No output schema declared.
No examples provided.
configure_vpd ~164
Configure VPD (Virtual Private Datacenter) host selection for the Relayer, or preview it with dry_run. Use defaults ("true" for both expressions) or a CEL expression filtering hosts by tags. The Relayer requires a minimum of 10 data hosts and 20 parity hosts — if too few match, broaden the criteria. Requires OIDC sign-in (same session as get_host_tags).
| Name | Type | Req | Description |
|---|---|---|---|
| data_expression | string | yes | CEL expression for data host selection. Use "true" for default (all hosts). |
| dry_run | boolean | – | Preview how many hosts match without applying anything. Not supported on Relayer versions without the evaluate endpoint. |
| parity_expression | string | yes | CEL expression for parity host selection. Use "true" for default (all hosts). |
No output schema declared.
No examples provided.
describe_settings ~61
List the adjustable Relayer settings: worker/concurrency tuning, backup schedule, and cost center (CCID). Returns current value, default, type, and guidance per setting. Use before update_settings. Requires OIDC sign-in (same session as the other tools).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
get_host_tags ~70
Get the available host tags for VPD (Virtual Private Datacenter) configuration, plus the currently applied VPD host selection. Translate tags into plain-language options for the operator — never show raw CEL expressions. Requires OIDC sign-in on first use (the user will be prompted to sign in via browser).
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
install_relayer ~1,089
Install and start the XNS Relayer. By default fetches the canonical release channel bundle — relayer + the Prometheus/Grafana monitoring stack — and its .env from releases.scpri.me (anonymous pull), appends the ports to that .env, then runs docker compose up -d — the user does NOT need to author any file. Falls back to a bundled copy of the bundle if either fetch fails. A failure names its cause (port in use, image pull refused, Docker stopped, out of disk, Docker socket permission) and the command that fixes it. Pass compose_url only to override with a custom compose. IMPORTANT — two machines: this tool writes docker-compose.yml and .env on the machine running the MCP, then starts the containers on whichever machine the Docker daemon is on. When DOCKER_HOST or an ssh:// Docker context points at a daemon on another machine, the tool refuses: it writes nothing and starts nothing, and returns an error naming the Docker host. Run the MCP on the Docker host (Node.js 20 there) and install from there. Exposure decisions on this surface: 1. BINDING — bind_address controls which host network interface Docker publishes ports on. Default: empty (all interfaces — the dashboard answers from any machine on the LAN with zero configuration). Set to "127.0.0.1" for loopback-only, or a specific interface IP. The value is passed to docker compose via env as BIND_ADDRESS; it takes effect only if the compose file used for the install references BIND_ADDRESS in its port declarations. When bind_address is set and the channel compose does not reference BIND_ADDRESS, the tool installs the bundled compose instead (source bundled-fallback, with a reason), because the bundled one honors it. A compose_url override is fetched remotely and may not honor it. The prerequisite check (check_prerequisites) probes port availability by binding 0.0.0.0 regardless of this setting. 2. UI TLS — ui_tls_enabled describes whether the admin UI listens on HTTPS in addition to HTTP. Default: false (off). Th…
| Name | Type | Req | Description |
|---|---|---|---|
| bind_address | string | – | Host network interface for Docker port publication. Default: empty string (all interfaces — reachable from any machine on the LAN). Set to "127.0.0.1" for loopback-only access, or a specific interfac… |
| compose_url | string | – | OPTIONAL override: URL to a custom docker-compose.yml. Omit for the normal released install. When provided, bind_address is passed to docker compose via env but the downloaded compose must use the BI… |
| install_path | string | – | Directory to install the compose file into |
| s3_port | integer | – | Host port for the S3 API (container 9000). Docker publishes this port on the interface chosen by bind_address. |
| s3_tls_enabled | boolean | – | Whether the S3 gateway should listen on HTTPS in addition to HTTP. Default: false (off — HTTP only). NOT WIRED in this version: accepted but has no effect until a future release ships the TLS listene… |
| ui_port | integer | – | Host port for the Relayer admin/customer UI (container 8888). Docker publishes this port on the interface chosen by bind_address. |
| ui_tls_enabled | boolean | – | Whether the admin UI should listen on HTTPS in addition to HTTP. Default: false (off — HTTP only). NOT WIRED in this version: accepted but has no effect until a future release ships the TLS listener.… |
No output schema declared.
No examples provided.
manage_backups ~135
Manage Relayer configuration backups: list archives, start a backup, restore from an archive, or delete one. Restore OVERWRITES current state and restarts services — always confirm with the operator and state which archive and components first. Backups must be enabled (BACKUP_ENABLED) for list/start.
| Name | Type | Req | Description |
|---|---|---|---|
| action | string | yes | Backup operation to perform. |
| components | array | – | Restore only these components (db, conf, hostio, samba). Omit to restore everything. |
| file | string | – | Archive file name from list (e.g. "1718000000000.zip"). Required for restore and delete. |
No output schema declared.
No examples provided.
restart_service ~75
Restart a Relayer service (hostio, gateway, s3gateway, database) or all services. Disruptive: in-flight S3 requests will fail during the restart — confirm with the operator before calling. Verify recovery afterwards with check_relayer_health.
| Name | Type | Req | Description |
|---|---|---|---|
| service | string | – | Service to restart. Defaults to "all". |
No output schema declared.
No examples provided.
setup_cli_credentials ~162
Provision S3 IAM credentials for the XNS CLI. Creates an IAM user in the Relayer and writes ~/.xns/credentials so that `xns ls` and other S3 verbs work without further configuration. Call once after check_claim_status reaches STATE_3.
| Name | Type | Req | Description |
|---|---|---|---|
| installation_id | string | – | Installation ID from check_claim_status STATE_3 result — used as cost_center_id in credentials |
| muse_token | string | yes | Keycloak/Muse token — the same token used for get_host_tags and configure_vpd |
| relayer_ui_url | string | – | Relayer UI base URL (default: http://localhost:8888). Must be a loopback, private-network, or .local address — this tool sends your Muse token to it. |
No output schema declared.
No examples provided.
start_claim ~61
Start a claim session to link this Relayer installation to an XNS account. Returns a claim URL that the user must open in a browser to complete the claim. The claim has an expiration time. After calling this, use check_claim_status to monitor claim progress.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
start_registration ~56
Get the browser registration URL for creating a new XNS account. The user opens this URL in a browser to sign up via Keycloak — the agent never touches credentials. After signing up, use check_email_verified to poll for email verification.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
update_settings ~111
Update adjustable Relayer settings (see describe_settings for the allowed set). Pass a map of setting name to new value, e.g. {"HOSTIO_UPLOAD_WORKERS": 20}. Returns require_restart — if true, follow up with restart_service after confirming with the operator. Changing CostCenter re-bills to a different cost center; always confirm first.
| Name | Type | Req | Description |
|---|---|---|---|
| settings | object | yes | Map of setting name to new value. Only whitelisted settings are accepted; unknown or protected keys are rejected with the allowed list. |
No output schema declared.
No examples provided.
verify_storage ~288
Verify the S3-compatible storage gateway is working by performing a round-trip test: create a test bucket, upload a small object, download it, and compare. Provisions a temporary scoped IAM credential automatically using your OIDC session — no manual key management needed. The throwaway credential and test data are removed after the test, pass or fail. By default targets port 9000 on the machine the Docker daemon runs on (auto-detected from the Docker context); pass endpoint to override.
| Name | Type | Req | Description |
|---|---|---|---|
| access_key_id | string | – | S3 access key ID — when provided with secret_access_key, skips automatic credential provisioning |
| endpoint | string | – | S3 endpoint URL. Default: http://{docker-host}:9000. Pass an explicit IP (e.g. http://192.168.1.100:9000) when auto-detection cannot reach the host. |
| muse_token | string | – | Optional Keycloak/Muse token override. Usually omitted — without it (and without access keys) the tool reuses the sign-in session from get_host_tags/configure_vpd, or starts a browser sign-in if ther… |
| relayer_ui_url | string | – | Relayer UI base URL (default: http://localhost:8888) |
| secret_access_key | string | – | S3 secret access key — when provided with access_key_id, skips automatic credential provisioning |
No output schema declared.
No examples provided.
How do I install the tech.xns/relayer MCP server?
tech.xns/relayer runs locally as an npm package, launched with npx -y @xns-cloud/relayer-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
npm · @xns-cloud/relayer-mcp
claude mcp add tech-xns-relayer -- npx -y @xns-cloud/relayer-mcp
What is the tech.xns/relayer MCP server?
tech.xns/relayer is an MCP server listed in the public MCP registry as tech.xns/relayer. Conversationally set up & manage an XNS Relayer over stdio: install, claim, VPD, S3, backups. This page covers its npm package (@xns-cloud/relayer-mcp).
Is the tech.xns/relayer MCP server safe to use?
tech.xns/relayer scores 94 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 5 November 2026. It declares no install or post-install scripts. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the tech.xns/relayer MCP server expose?
tech.xns/relayer exposes 15 tools: check_prerequisites, start_registration, check_email_verified, install_relayer, check_relayer_health, and 10 more. Their descriptions and schemas cost roughly 2,891 tokens of context every time the server is loaded.
Is the tech.xns/relayer MCP server still maintained?
tech.xns/relayer is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.
What licence is the tech.xns/relayer MCP server under?
tech.xns/relayer declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.