Loading ToolBench
MCP server for XNS Relayer onboarding and day-2 management — drives Relayer setup, settings, and backups conversationally over stdio, npx-ready
This MCP server demonstrates solid definition quality with well-structured tool registrations, comprehensive descriptions, and proper input schemas across all 15 tools. Tool names follow verb_noun conventions (check_*, start_*, configure_*, manage_*) and are action-oriented. Descriptions range from 100-200 characters, providing context on WHAT each tool does and WHEN to call it. Input schemas use proper JSON Schema with types and descriptions. However, several tools lack output schema documentation, and some parameters could benefit from tighter constraints (enums where appropriate). Error handling is present but varies in actionability across tools. Overall above average for community MCP servers, with room for improvement in output documentation and parameter constraints.
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.
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.
Check runtime prerequisites before installation (Node version, Docker, disk space, networking)
Check the health status of the Relayer service (whether containers are running and responsive)
Configure VPD (Validator Public Data) on the Relayer. Requires OIDC authentication.
Retrieve the current Relayer configuration settings. Returns only whitelisted settings (worker concurrency, backup schedule, cost center).
Output schemas not documented in source. While tool descriptions indicate what is returned (e.g., 'Returns claim_id and browser URL'), the actual structured output schema is not visible in the code provided. LLMs cannot reliably chain tools without knowing the response field names and types.
configure_vpd accepts a generic 'vpd_config' object parameter without specifying its schema or allowed keys. This forces LLMs to guess at the structure and risks invalid configurations. Should document allowed keys, types, and validation rules.
manage_backups accepts an 'action' parameter as a free-form string. Should be declared as an enum: ['list', 'download', 'restore'] to prevent LLM hallucination of invalid actions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 56 | 2026-07-28+ | v2 |
Retrieve host tags (labels, metadata) from the Relayer. Requires OIDC authentication.
Download and install the XNS Relayer using docker-compose at a specified path
Manage Relayer configuration backups. List, download, or restore backup archives.
Restart the Relayer service (docker-compose down/up)
Set up CLI credentials for the Relayer. Generates and stores access keys for command-line access.
Start a claim session to link the Relayer to an XNS account. Returns a claim_id and browser URL for the user to complete the flow.
Start the user registration flow for a new XNS account
Update whitelisted Relayer configuration settings. Allowed keys: HOSTIO_UPLOAD_WORKERS, HOSTIO_DOWNLOAD_WORKERS, HOSTIO_UTILITY_OPERATIONS_WORKERS, HOSTIO_SIMULTANEOUS_UPLOADS, HOSTIO_SIMULTANEOUS_DOWNLOADS, BACKUP_ENABLED, BACKUP_FREQUENCY, BACKUP_THRESHOLD, BACKUP_RETENTION, CostCenter.
Verify that the Relayer's S3-compatible storage backend is accessible and working. Creates temporary test credentials, mints a test user, and performs read/write operations.
update_settings 'settings' parameter is a generic object without documented schema or whitelisted keys. While the description lists allowed keys (HOSTIO_UPLOAD_WORKERS, BACKUP_ENABLED, etc.), the schema should enforce this via a constrained object or enum set. LLMs may pass invalid keys.
Error handling is implicit in descriptions but no explicit error categorization (retryable, user-fixable, fatal) is visible. Tools like check_email_verified with long polling should document timeout behavior and recovery paths explicitly in error responses.
restart_service has minimal description ('Restart the Relayer service (docker-compose down/up)'). Should explain consequences: will interrupt running jobs, users will be disconnected, consider scheduling during maintenance windows.
Tools requiring OIDC authentication (get_host_tags, configure_vpd, verify_storage, setup_cli_credentials) mention it in descriptions but do not document how authentication is injected. Is there a prerequisite tool? Server-side secret injection? Unclear.