XNS Relayer 用 MCPサーバー — S3互換の分散オブジェクトストレージ。15のツールを提供し、AIエージェントが stdio トランスポートを介して会話形式で Relayer のセットアップと day-2 管理を完全に実行できるようにします。
npx @xns-cloud/relayer-mcp@latest料金: $4.00 per network-TB-month — データが保存されるパリティに対して支払い、$0 egress uncapped、no minimum retention。
Node.js 20+ — ディストリビューションが古いバージョンを提供している場合は、Node.js 20のインストールを参照してください。
Docker Engine — 同じマシン上、または Docker コンテキストを介したリモートホスト上（リモートDockerホストを参照）。
Ubuntu のデフォルトの apt リポジトリは Node 18 のみを提供しており、古すぎます。Node 20 を入手するには2つの方法があります：
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ランナー、使い捨て VM）内で実行されている場合、そこで実行されたインストールは環境が終了すると失われます。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（1コマンド）：
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）。
オペレーターに必要な操作は、メールリンクを1回クリック、ブラウザサインインを1回完了、クレームを1回確認するだけです。
オンボーディング後、ツール12～15は日常的な調整をカバーします：describe_settings→update_settings→restart_serviceによるチューニング（ワーカー、同時実行数、バックアップスケジュール、コストセンター）、およびバックアップライフサイクル用のmanage_backups。これら4つはすべてツール8～9と同じOIDCセッションを使用します。破壊的操作（リストア、再起動、コストセンターの変更）は、実行前にエージェントがオペレーターに確認します—ツールの説明とレスポンスに警告が含まれています。
install_relayerは新規インストールのみを実行します—既存のデプロイメントをその場でアップグレードすることはありません。Dockerコンテナ名はデーモンごとに一意であるため、既存のxns-relayerコンテナ（実行中または停止中、任意のチャネル—releases.scpri.meからのアルファチャネルインストールを含む）が存在するとインストールをブロックします。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をプローブします—それらが管理ノードから到達可能であることを確認してください。
check_prerequisitesはローカルポート可用性プローブをスキップし（コンテナはリモートホストにポートをバインドします）、スキップされたことを指示とともに報告します。
check_relayer_healthはhostオーバーライドを受け付け、verify_storageはendpointオーバーライドを受け付けます。自動検出では見えないセットアップ（ポートフォワード、NAT）に対応します。
症状 | 原因 | 修正 |
MCPが「Node.js 20以降が必要です」で終了する | ディストリビューションのNodeが古すぎる（Ubuntu aptはNode 18を提供） | |
| 以前のデプロイメント（任意のチャネル）がコンテナ名を所有している | |
ポート8888/9000が既に使用中 | Dockerホスト上の別のサービス（別のS3互換サービスが9000を占有） | そのサービスを停止するか、カスタムポートでインストール： |
ヘルスチェックは失敗するが、コンテナはリモートDockerホストで実行中 | ポート8888/9000が管理ノードから到達不能 | ポートを開放するか、 |
ツール8～9と12～15は、Relayer APIおよびHostIOプロキシにアクセスするためにOIDCトークンを必要とします。MCPは、scprime Keycloakレルムのrelayer-nativeパブリッククライアントに対するAuthorization Code + PKCE（S256）フローを使用して自動的にトークンを取得します。ユーザーはブラウザサインインを完了し、MCPはローカルの127.0.0.1ループバックリスナーでコードをキャプチャし、トークンと交換します。
前提条件: relayer-nativeパブリッククライアントがKeycloak scprimeレルムに登録されている必要があります（PKCE S256、リダイレクト http://127.0.0.1:*）。
npm install
npm testNode.js 20+が必要です。
relayer-nativeクライアントに関する注意このパッケージはOIDC認証にrelayer-native KeycloakクライアントIDを使用します。同じクライアント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
