XNS Relayer 的 MCP 服务器——兼容 S3 的去中心化对象存储。提供 15 个工具，让 AI 代理能够通过 stdio 传输以对话方式驱动完整的 Relayer 设置和日常运维管理。
npx @xns-cloud/relayer-mcp@latest定价： 每网络-TB-月 $4.00——您为数据存储的冗余度付费，$0 出站流量无上限，无最低保留期限。
Node.js 20+——如果您的发行版自带较旧版本，请参阅安装 Node.js 20。
Docker 引擎——在同一台机器上，或通过 Docker 上下文在远程主机上（请参阅远程 Docker 主机）。
Ubuntu 的默认 apt 仓库仅提供 Node 18，版本过旧。获取 Node 20 有两种方式：
nvm（推荐——无需 root 权限）：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
\. "$HOME/.nvm/nvm.sh" && nvm install 20NodeSource（系统级）：请遵循 https://github.com/nodesource/distributions#installation-instructions。
如果您在较旧版本的 Node 上启动 MCP，它会立即退出并显示此指导信息，而不是显示依赖堆栈跟踪。
Related MCP server: Docker/Hetzner MCP Server
Relayer 以 Docker 容器方式运行，并将其数据持久化存储在 Docker 卷中。如果 MCP 在临时环境（沙箱容器、CI 运行器或一次性虚拟机）中运行，则在该环境中执行的任何安装操作都会在环境退出时丢失。check_prerequisites 会自动检测此情况，并以警告形式报告，同时提供具体的后续步骤——它永远不会阻塞流程。
如果您的环境是临时的，请改为在持久化 Docker 主机上安装。从临时沙箱出发的最简单路径是使用 SSH Docker 上下文：
docker context create relayer --docker "host=ssh://user@persistent-host"
docker context use relayer然后 MCP 通过 SSH 上下文在持久化主机上驱动安装。或者，将安装步骤交给目标机器上的人工操作员，然后从 check_relayer_health 开始继续引导流程。
Claude Code（一条命令）：
claude mcp add relayer -- npx @xns-cloud/relayer-mcp@latestClaude Desktop / 任何 MCP 客户端——添加到您的 claude_desktop_config.json（或等效文件）：
{
"mcpServers": {
"relayer": {
"command": "npx",
"args": ["@xns-cloud/relayer-mcp@latest"]
}
}
}Cursor——添加到 .cursor/mcp.json：
{
"mcpServers": {
"relayer": {
"command": "npx",
"args": ["@xns-cloud/relayer-mcp@latest"]
}
}
}无需单独的安装步骤——npx 会按需获取包。
# | 工具 | 用途 |
1 |
| 验证 Docker（本地或远程）、端口（8888、9000）、现有安装、磁盘和网络连接。 |
2 |
| 获取用于创建 XNS 账户的浏览器注册 URL——代理从不处理凭据。 |
3 |
| 轮询邮箱验证状态（15 秒间隔，30 分钟超时）。 |
4 |
| 获取规范的测试版渠道包——relayer + Prometheus/Grafana 监控栈（ |
5 |
| 轮询 UI、S3、HostIO 和监控边车（10 秒间隔，300 秒超时）。缺少监控栈会报告为降级状态，但不会阻塞流程。自动定位 Docker 主机。 |
6 |
| 发起认领会话——返回用于浏览器确认的 URL。 |
7 |
| 轮询认领状态（STATE_1 / STATE_2 / STATE_3）。 |
8 |
| 获取用于 VPD 配置的可用主机标签，以及当前应用的数据/冗余选择（通过 |
9 |
| 通过 CEL 表达式设置数据/冗余主机选择。 |
10 |
| 针对 S3 网关进行往返 S3 测试（创建存储桶、放置对象、获取对象）。通过您的 OIDC 会话自动生成临时作用域 IAM 凭据——无需手动密钥管理。测试后，该工具会尝试删除测试数据和临时凭据；如果无法删除任何资源，则会报告 |
11 |
| 配置 S3 IAM 凭据并写入 |
12 |
| 列出可调整的设置——工作器/并发调优、备份计划、成本中心（CCID）——包含当前值、默认值和指导说明。MCP 仅有意暴露此精选集合，而非完整的高级配置目录。 |
13 |
| 应用设置变更映射（白名单强制执行）。返回 |
14 |
| 重启 |
15 |
| 列出/启动/恢复/删除配置备份。恢复操作具有破坏性，并支持选择性组件（ |
代理检查先决条件（工具 1）。
代理获取浏览器注册 URL；用户在浏览器中创建账户（工具 2）。
用户点击电子邮件验证链接；代理轮询（工具 3）。
代理安装并启动 Relayer 容器（工具 4）——它自行编写发布的 compose 和 .env 文件；用户无需提供 compose URL。
代理轮询健康状态，直到 UI 和 S3 启动（工具 5）。
代理发起认领；用户在浏览器中打开认领 URL（工具 6 和 7）。
代理通过 OIDC 登录以配置主机偏好（工具 8 和 9）。
代理验证 S3 存储是否正常工作（工具 10）。
可选地，代理配置 CLI 凭据（工具 11）。
操作员唯一需要执行的操作是：点击一个电子邮件链接、完成一次浏览器登录以及确认一次认领。
完成初始设置后，工具 12-15 涵盖常规调整：describe_settings → update_settings → restart_service 用于调优（工作进程、并发数、备份计划、成本中心），以及 manage_backups 用于备份生命周期。这四个工具均使用与工具 8-9 相同的 OIDC 会话。破坏性操作（恢复、重启、更改成本中心）在执行前需经代理与操作员确认——工具描述和响应中会包含警告。
install_relayer 仅执行全新安装——它不会原地升级现有部署。Docker 容器名称对每个守护进程是唯一的，因此任何现有的 xns-relayer 容器（运行中或已停止，任何渠道——包括来自 releases.scpri.me 的 alpha 渠道安装）都会阻止安装。check_prerequisites 和 install_relayer 都会检测到这种情况，并在任何问题发生前告知你。
要替换现有部署：
docker stop xns-relayer && docker rm xns-relayer # does NOT delete the data directory然后再次运行 install_relayer。要保留现有部署，请跳过 install_relayer 并继续针对它进行初始设置（从 check_relayer_health 开始）。
Claude Code 不必在 Docker 机器上运行。如果你在管理节点或跳板机上运行它，可以通过 SSH 上下文将 Docker CLI 指向远程服务器：
docker context create relayer --docker "host=ssh://user@docker-box"
docker context use relayer（需要在管理节点上安装 docker CLI——静态二进制文件 就足够了——并且拥有对 Docker 主机的 SSH 密钥访问权限。）
MCP 会自动检测这一点（它会遵循 DOCKER_HOST 和活动的 Docker 上下文）：
install_relayer 针对远程守护进程运行 docker compose。
check_relayer_health 和 verify_storage 探测远程主机的 8888/9000 端口，而不是 localhost——确保这些端口可从管理节点访问。
check_prerequisites 跳过本地端口可用性探测（容器绑定远程主机上的端口），并报告为已跳过并附上说明。
check_relayer_health 接受 host 覆盖参数，verify_storage 接受 endpoint 覆盖参数，用于自动检测无法识别的设置（端口转发、NAT）。
症状 | 原因 | 修复 |
MCP 退出并显示"requires Node.js 20 or newer" | 发行版 Node 版本过旧（Ubuntu apt 提供 Node 18） | |
| 之前的部署（任何渠道）占用了该容器名称 | |
端口 8888/9000 已被占用 | Docker 主机上的其他服务（另一个 S3 兼容服务占用了 9000） | 停止该服务，或使用自定义端口安装： |
健康检查失败但容器在远程 Docker 主机上运行 | 管理节点无法访问端口 8888/9000 | 开放这些端口，或传递 |
工具 8-9 和 12-15 需要 OIDC 令牌才能访问 Relayer API 和 HostIO 代理。MCP 使用授权码 + PKCE (S256) 流程自动获取一个令牌，该流程针对 scprime Keycloak 领域和 relayer-native 公共客户端。用户完成浏览器登录；MCP 在本地 127.0.0.1 回环监听器上捕获代码并将其交换为令牌。
先决条件： relayer-native 公共客户端必须在 Keycloak scprime 领域上注册（PKCE S256，重定向 URI http://127.0.0.1:*）。
npm install
npm test需要 Node.js 20+。
relayer-native 客户端的说明此包使用 relayer-native Keycloak 客户端 ID 进行 OIDC 身份验证。同一客户端 ID 计划供未来的独立 Relayer CLI（@xns-cloud/relayer-cli）重用，并将 OIDC 模块（src/lib/oidcAuth.js）提取到共享的 @xns-cloud/relayer-auth 包中。
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 | Required | Description | Default |
|---|---|---|---|
| claim_id | Yes | The claim_id returned by start_claim | |
| timeout_ms | No | Maximum time to poll in milliseconds (default: 10 minutes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the responsibility of disclosing behavior. It reveals that the tool polls every 10 seconds, lists the meaning of each state, and states that it automatically proceeds upon reaching STATE_3. This goes beyond the basic 'poll status' phrasing, though it does not detail timeout error behavior or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. The first sentence states the purpose, and the second sentence efficiently enumerates states and the auto-proceed behavior. Every sentence contributes necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the polling interval, state meanings, and auto-proceed behavior, providing a good overall context. However, it does not explain what happens if the timeout_ms expires (e.g., whether it returns an error or a timeout state), which is a minor gap for an agent invoking a long-polling operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear descriptions for claim_id and timeout_ms. The description itself adds no direct parameter semantics but the schema already provides sufficient information, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Poll the status of a claim session.' It further distinguishes the tool by detailing the session states (STATE_1, STATE_2, STATE_3), which ties directly to sibling tools like start_claim and check_relayer_health, 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after start_claim by referencing claim sessions and the 'claim_id returned by start_claim' in the schema. It does not explicitly mention alternatives or exclusions, but the polling context and state definitions make it clear when this tool should be used (to wait for claim completion).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| poll | No | If true (default), poll until verified or timeout. If false, check once. | |
| Yes | Email address to check verification status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the polling interval, timeout duration, early return condition, and the no-account case. These are meaningful behavioral traits that go well beyond the tool's name and cannot be inferred from the schema alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose. Every sentence contributes essential information: polling mechanics, immediate return condition, and the no-account edge case. No filler, repetition, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple polling tool with no output schema and no annotations, the description covers the key scenarios: polling, early verification, timeout, and no-account. It does not specify the exact return format, but given the simplicity and lack of an output schema, this is a minor gap. It is adequately complete for an AI agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds context about the polling behavior (every 15 seconds, up to 30 minutes), which elaborates the 'poll' parameter's meaning and behavior. This adds value beyond the schema without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: polling to check email verification status. It uses a specific verb ('Poll to check') and resource ('user's email address'), and it explains distinct outcomes (returns immediately if verified, indicates registration if no account). However, it does not explicitly contrast with sibling tools like check_prerequisites or check_claim_status, though its unique subject matter makes the purpose understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it polls every 15 seconds up to 30 minutes, returns immediately if already verified, and indicates when registration is needed. This implies when to use it and hints at an alternative (registration). It stops short of explicitly naming alternative tools or stating when not to use it, which would have earned a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check system prerequisites for XNS Relayer installation: Docker availability (local or remote via DOCKER_HOST / ssh:// context), required ports (8888, 9000), an existing xns-relayer installation, disk space, and network connectivity to console.xns.tech and auth.xns.tech. Run this first before any other relayer tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly discloses a read-only action ('Check') and lists all the checks performed, including network endpoints and ports. However, it does not state the return format or whether the check may require authentication (e.g., Docker credentials), leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary purpose, followed by a detailed enumeration of checks and a clear usage directive. Every sentence earns its place; the first sentence is dense but informative, the second provides critical workflow guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema, no annotations), the description provides the essential context: what is checked and when to run it. It does not describe the output or success criteria, which the agent would need to interpret results, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The schema coverage is 100% because the schema is empty. The description adds no parameter information since none exist, which is appropriate; the baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Check') and resource ('system prerequisites for XNS Relayer installation'), and enumerates specific checks (Docker, ports, existing installation, disk space, network connectivity). This distinguishes it from sibling tools, as it is the prerequisite check before any other relayer operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Run this first before any other relayer tool,' providing a direct and unambiguous usage directive. This tells the agent exactly when to use this tool in the workflow, though it doesn't need to list alternatives because this is the entry point tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| host | No | Hostname/IP where the Relayer containers run. Default: auto-detected from the Docker context (localhost, or the remote host for ssh:// / tcp:// contexts). | |
| poll | No | If true (default), poll until healthy or timeout. If false, check once. | |
| s3_port | No | Host port for the S3 API (matches install_relayer s3_port) | |
| ui_port | No | Host port for the Relayer UI (matches install_relayer ui_port) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses key behaviors: polling interval/timeout, per-component status reporting, degraded state handling, Docker context auto-detection with host override, and the OIDC caveat for HostIO. This gives the agent a complete understanding of side effects and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and every clause adds value—polling details, status reporting, degraded state, and host detection. No fluff or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (per-component status, unhealthy components named) and important caveats (degraded monitoring stack, HostIO unknown until OIDC). It covers the essential information an agent needs to invoke and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds meaningful context beyond the schema by specifying the polling interval (10s) and timeout (300s), and explaining the impact of the polling behavior on the 'poll' parameter. It also reinforces the default ports and host override, adding nuance not fully captured in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific action ('Check the health') and enumerates the exact resources (UI on port 8888, S3 gateway on 9000, HostIO, and monitoring sidecars). This clearly distinguishes it from sibling tools like check_prerequisites or check_claim_status, which target different concerns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use the tool (health checks during/after installation) and important conditional behavior (degraded monitoring stack does not block install flow). However, it does not explicitly mention alternatives or when not to use it, 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.
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 | Required | Description | Default |
|---|---|---|---|
| dry_run | No | Preview how many hosts match without applying anything. Not supported on Relayer versions without the evaluate endpoint. | |
| data_expression | Yes | CEL expression for data host selection. Use "true" for default (all hosts). | |
| parity_expression | Yes | CEL expression for parity host selection. Use "true" for default (all hosts). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses important behavioral traits: dry_run preview does not apply changes, requires OIDC sign-in, and enforces minimum host thresholds. It does not detail side effects such as persistence or service restart, but covers key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, and no redundant information. Each sentence adds meaning: purpose, configuration syntax, and prerequisites/constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a configuration tool with no output schema, the description covers the core aspects: purpose, usage, constraints, and auth. It lacks explicit return value or post-conditions, but is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds practical value by showing default values ('true') and explaining CEL expressions filter by tags, plus ties host count constraints to the expression parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures VPD host selection for the Relayer, with an optional dry_run preview. It distinguishes itself from sibling tools by focusing on host selection, a unique function not covered by other listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: configuring host selection with defaults or CEL expressions, and notes the minimum host count requirement to guide criteria. It mentions the OIDC sign-in prerequisite but does not explicitly contrast with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 structure (current value, default, type, guidance per setting) and the authentication requirement (OIDC sign-in). While it does not explicitly state that the operation is read-only, the verb 'List' and the context of inspecting settings before updating imply a safe, non-mutating behavior. This is adequate transparency for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the core purpose. The first sentence states what the tool lists and returns; the second provides usage timing and auth requirements. Every word earns its place—no fluff, no repetition of schema (which is empty).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the essential aspects: what the tool does, what it returns, when to use it, and what prerequisites exist. It is sufficiently complete for a simple listing tool with no parameters. The inclusion of return detail (value, default, type, guidance) compensates for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 per the rubric. The description adds value by naming the settings covered, which helps the agent understand the scope of the output, even though no input is needed. Since there are no parameters to document, the description's mention of the settings is a bonus.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'adjustable Relayer settings', enumerating categories (worker/concurrency tuning, backup schedule, cost center). It distinguishes itself from siblings by explicitly stating 'Use before update_settings', making its role as a read-only precursor clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance to use 'before update_settings', directly linking this tool to its sibling. It also notes the OIDC sign-in requirement. However, it does not mention scenarios where this tool should not be used or alternatives beyond update_settings, so it lacks exclusions but provides clear use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 OIDC sign-in requirement on first use and the output transformation rule ('never show raw CEL expressions'), which are important behavioral traits. It could mention whether the operation is strictly read-only, but the verb 'Get' and the nature of the tool imply it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, output behavior, and authentication note. Each sentence is necessary and informative, with no fluff. The most important information (what the tool does) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers purpose, output format, and auth. It could specify the return structure more explicitly, but it adequately explains what the operator will receive and how to handle it. The sibling context (configure_vpd) reinforces its role as a prerequisite helper.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameter semantics to clarify. The description adds value by explaining how the results are presented (plain-language options), which is more about output than parameters. The baseline for 0 params is 4, and the description does not need to do more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and resource: 'Get the available host tags for VPD configuration, plus the currently applied VPD host selection.' This is a specific verb + resource and distinguishes it from configure_vpd and other siblings by focusing on retrieval and current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by tying the tool to VPD configuration and indicating it retrieves both available tags and the current selection. It does not explicitly name alternatives or exclusions, but the purpose is positioned as a prerequisite step, which is sufficient for a zero-parameter informational tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install and start the XNS Relayer. By default fetches the canonical beta channel bundle — relayer + the Prometheus/Grafana monitoring stack — from releases.scpri.me (anonymous pull) and writes a .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 the fetch fails. Pass compose_url only to override with a custom compose.
| Name | Required | Description | Default |
|---|---|---|---|
| s3_port | No | Host port for the S3 API (container 9000) | |
| ui_port | No | Host port for the Relayer admin/customer UI (container 8888) | |
| compose_url | No | OPTIONAL override: URL to a custom docker-compose.yml. Omit for the normal released install. | |
| install_path | No | Directory to install the compose file into | /opt/xns-relayer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It honestly details side effects: fetching from releases.scpri.me, writing a .env, running docker compose up -d, and falling back to a bundled copy if the fetch fails. It also notes the user doesn't need to author files, which is a useful behavioral cue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary action, and uses a few sentences to pack essential operational details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex installation tool, the description covers the source, the installation mechanism, fallback behavior, and the override path. It lacks explicit mention of port defaults or prerequisites, but the schema supplies port defaults and no output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all four parameters with 100% coverage, so the baseline is 3. The description adds value by clarifying compose_url as an override, but does not deepen the meaning of s3_port, ui_port, or install_path beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Install and start the XNS Relayer' using a specific verb and resource, distinguishing it from sibling health/restart/status tools. It also specifies the default bundle and monitoring stack, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the default behavior (canonical beta bundle, anonymous pull) and when to use the override ('Pass compose_url only to override with a custom compose'). However, it does not explicitly mention any exclusions or alternatives among the sibling tools, such as checking prerequisites with check_prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| file | No | Archive file name from list (e.g. "1718000000000.zip"). Required for restore and delete. | |
| action | Yes | Backup operation to perform. | |
| components | No | Restore only these components (db, conf, hostio, samba). Omit to restore everything. |
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 explicitly warns that restore 'OVERWRITES current state and restarts services' and advises confirming with the operator, which is critical for a potentially destructive operation. It does not mention deletion permanence, but the restore warning is a strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with each sentence adding value: the first enumerates actions, the second provides a critical safety warning, and the third states a prerequisite. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of output schema, the description covers the main operations, key safety warnings, and prerequisites. It doesn't explain return values, but this is not essential for a backup management tool. The description is adequate for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all parameters (action, file, components) with 100% coverage. The description adds a bit of practical guidance (e.g., 'state which archive and components first'), but it doesn't substantially augment the schema's parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs: 'list archives, start a backup, restore from an archive, or delete one.' It identifies the resource (Relayer configuration backups) and distinguishes the tool from siblings that handle other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is used for managing backups, and it explicitly notes a prerequisite ('Backups must be enabled'). However, it doesn't explicitly contrast with alternative tools or state when not to use it, so it falls short of full usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new XNS account with an email and password. After registration, the user must verify their email at auth.xns.tech by clicking the link sent to their inbox. Use check_email_verified to poll for verification status. If the email already has an account, you can skip to install_relayer.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | User email address | ||
| password | Yes | Password (minimum 8 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the burden. It discloses that registration triggers a verification email, requires user action, and suggests polling. It also notes the existing-account condition. It could mention error responses or idempotency, but the workflow is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: purpose, post-registration requirement, and alternative paths. No filler or redundancy; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with no output schema, the description covers the registration flow, verification step, and conditional skip. It lacks explicit error messages or return values, but is complete enough for an agent to act correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for both parameters with descriptions (email format, password min length). Description only restates 'email and password' without adding extra meaning beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Register' with the resource 'new XNS account' and explicitly mentions email/password. It distinguishes itself from sibling tools by directing to check_email_verified for polling and install_relayer for existing accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use the tool (to register), what to do after (verify email, poll with check_email_verified), and when to skip (if email already has an account, go to install_relayer). This provides clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| service | No | Service to restart. Defaults to "all". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of safety disclosure. It explicitly warns that the operation is disruptive and that in-flight S3 requests will fail, which is critical behavioral context. It does not detail every possible side effect, but the primary risk is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action and followed by essential risk and recovery guidance. Every sentence earns its place without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter restart tool with no output schema, the description covers the action, target options, disruptive impact, operator confirmation, and verification step via a sibling tool. It is complete within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter, service, is already fully documented with an enum and default. The description repeats the service list but does not add new parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (restart) and the resource (Relayer services), lists the valid service targets, and distinguishes from sibling tools by focusing on restart rather than health checks or installation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit preconditions: confirm with the operator before calling, and directs verification with check_relayer_health afterward. It does not explicitly state when not to use the tool or name alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| muse_token | Yes | Keycloak/Muse token — the same token used for get_host_tags and configure_vpd | |
| relayer_ui_url | No | Relayer UI base URL (default: http://localhost:8888) | http://localhost:8888 |
| installation_id | No | Installation ID from check_claim_status STATE_3 result — used as cost_center_id in credentials |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the core side effects (creates an IAM user, writes credentials), but does not reveal whether repeated calls overwrite existing credentials, or what happens if called prematurely. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences: the first states the verb and resource, the second gives the usage trigger. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose, the effect on the CLI, and the correct timing relative to check_claim_status. It lacks details on return values or failure modes, but for a one-time setup tool with strong contextual anchor, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter already carrying descriptive meaning. The description adds no new parameter-level detail beyond what the schema provides, maintaining the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Provision') and names exact resources (S3 IAM credentials, ~/.xns/credentials), immediately distinguishing this tool from siblings like check_claim_status or install_relayer. It clearly states the outcome (S3 verbs work without further configuration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit trigger condition: 'Call once after check_claim_status reaches STATE_3.' This is clear contextual guidance on when to invoke the tool, though it does not mention alternatives or 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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, and it does: it notes the tool returns a claim URL that requires browser action, mentions the expiration time, and points to the monitoring tool. This gives the agent a clear model of the tool's side effects and follow-up actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, with the main action first and no filler. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool without an output schema, the description covers the core flow: start, get URL, user action, expiry, and monitoring. It doesn't discuss failure handling, but the absence of parameters and the straightforward session flow make the description sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema already reflects this. The description adds no parameter-specific details, but with 0 params, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Start a claim session to link this Relayer installation to an XNS account,' clearly stating the verb, resource, and goal. It distinguishes itself from the sibling check_claim_status by indicating it's the initiation step that returns a URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly directs the user to 'use check_claim_status to monitor claim progress' after calling, providing a clear sequential guideline. It doesn't explicitly state exclusions or prerequisites, but the context makes the primary use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Required | Description | Default |
|---|---|---|---|
| settings | Yes | Map of setting name to new value. Only whitelisted settings are accepted; unknown or protected keys are rejected with the allowed list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the require_restart return flag, the need for restart_service, and the re-billing side effect of CostCenter changes. This is strong, though it doesn't detail all potential side effects or the timing of changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff: purpose, example, return behavior, and a warning. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers the return value (require_restart), the follow-up restart_service action, and a special-case confirmation for CostCenter. It is self-sufficient when paired with describe_settings, and the sibling list reinforces the workflow context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 concrete example (HOSTIO_UPLOAD_WORKERS: 20) and clarifies the map format, which enriches the schema's generic definition and gives the agent a clearer invocation pattern.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Update' with the resource 'Relayer settings' and explicitly directs users to describe_settings for the allowed set. This clearly distinguishes it from sibling tools like describe_settings (read-only) and restart_service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: consult describe_settings for allowed settings, follow up with restart_service if require_restart is true, and always confirm before changing CostCenter. This gives clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. IMPORTANT: you must supply fullaccess credentials — the admin key pair created via the Relayer UI IAM page (not a read-only or bucket-scoped key). By default targets port 9000 on the machine the Docker daemon runs on (auto-detected from the Docker context — supports remote ssh:// Docker hosts); pass endpoint to override with an explicit IP when auto-detection cannot reach the host.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint | No | S3 endpoint URL. Default: http://{docker-host}:9000, where {docker-host} is auto-detected from the Docker context. Pass an explicit IP (e.g. http://192.168.1.100:9000) when auto-detection cannot reach the host. | |
| access_key_id | Yes | S3 access key ID (fullaccess credentials from the Relayer UI IAM page) | |
| secret_access_key | Yes | S3 secret access key (fullaccess credentials from the Relayer UI IAM page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it creates a test bucket, uploads/downloads an object, and compares. It also reveals a practical requirement for fullaccess credentials and explains endpoint auto-detection with remote host support. However, it doesn't disclose whether the test bucket is cleaned up after the test, which is a notable omission for a tool with side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with no redundant sentences. It front-loads the purpose, then adds credential and endpoint details in a logical order. Every clause contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose, credentials, and endpoint behavior but omits cleanup behavior and failure semantics. Given the tool creates a test bucket, the lack of cleanup information leaves an important gap. Overall, it's adequate but not fully complete for a side-effectful verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions (100% coverage). The description adds critical context: endpoint default and override conditions, and the exact credential type ('fullaccess' from Relayer UI IAM, not read-only/bucket-scoped). This enriches the schema meaning and helps agents pick appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Verify the S3-compatible storage gateway is working by performing a round-trip test...' It specifies the verb, resource, and method, distinguishing it from sibling tools like check_relayer_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use this when you need to verify the storage gateway, not just service health. It also specifies when to override the endpoint ('when auto-detection cannot reach the host') and explicitly states the required credential type. However, it doesn't name alternative tools for different checks, 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.
Each tool targets a distinct phase or action in the relayer lifecycle: prerequisites, account, install, health, claim, VPD, storage, CLI, settings, restart, backups. There is no overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., check_prerequisites, start_claim, update_settings). The verbs clearly indicate the action and the noun indicates the target, making the naming predictable and readable.
With 15 tools, the set covers the full installation and management workflow without being bloated. Each tool serves a specific, necessary function in the operator's journey, and the count is within the well-scoped range for a server with this purpose.
The tool set covers the entire lifecycle from prerequisites to installation, claiming, configuration, verification, settings tuning, restart, and backups. There are no obvious dead ends or missing operations for the intended use case of installing and managing an XNS Relayer.
Create a free sandbox object storage bucket; upload, download, list, inspect, and delete objects.
S3 storage and Solana/Base/Ethereum health checks for AI agents, paid per call via x402.
Deploy full-stack apps (Postgres, Redis, S3, workers, backups) from Claude or curl. 59 MCP tools.
Discover machine-payable APIs, probe x402 payment terms, and run seller operations. Non-custodial.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xns-cloud/relayer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
