How do I use Xserver MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Xserver MCP check disk usage on my server" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Xserver MCP

by masp047

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Xserver MCP

XServer API を 読み取り専用 でラップした MCP サーバーです。Claude との会話からサーバーの状況（ディスク使用量・ドメイン・メール・cron など）を確認できます。

あなた: サーバーのディスク、あとどれくらい空いてる？
Claude: [xserver_server_status を実行]
        xs123456.xsrv.jp: 42.1 GB / 300 GB (14.0%)、ファイル数 128,430
        ドメイン 7、サブドメイン 12、メールアカウント 23、MySQL 4

重要な前提

このサーバーは GET しか発行しません。 設定変更・削除は一切できません。
お手元のマシンで動かす前提です。 Claude Desktop / ローカルの claude CLI に stdio で接続します。Claude Code on the web のリモートセッションからは api.xserver.ne.jp に到達できないため、そちらでは動きません。
エンドポイントは実アカウントで検証済みです。 公式リファレンス（https://developer.xserver.ne.jp/api/server/ ）を参照できない状態で実装したため当初は推測を含んでいましたが、npm run check による実測で確定させました。一部は 404 で存在しないことが判明しています。下記「エンドポイントの検証状況」を参照してください。

Related MCP server: @rarecloudio/mcp-server

セットアップ

必要環境: Node.js 20 以上。

git clone <このリポジトリ>
cd Xserver_MCP
npm install
npm run build

APIキーの発行

Xserver のサーバーパネルにログイン
「アカウント」→「APIキー設定」
「APIキー発行」をクリックしてキーをコピー

キーはチャットに貼らず、環境変数として渡してください。

動作確認

MCP クライアントに繋ぐ前に、接続チェックを実行します。

XSERVER_API_KEY='発行したキー' npm run check

/me の疎通、サーバー名の解決、各エンドポイントの到達性を順に確認し、 ok / miss で一覧表示します。miss になったパスは実在しない（＝推測が外れた）ということなので、公式リファレンスで正しいパスを確認してください。

Claude Desktop への登録

設定ファイル（macOS: ~/Library/Application Support/Claude/claude_desktop_config.json、 Windows: %APPDATA%\Claude\claude_desktop_config.json）に追記します。

{
  "mcpServers": {
    "xserver": {
      "command": "node",
      "args": ["/absolute/path/to/Xserver_MCP/dist/index.js"],
      "env": {
        "XSERVER_API_KEY": "発行したキー",
        "XSERVER_SERVERNAME": "xs123456.xsrv.jp"
      }
    }
  }
}

args は絶対パスにしてください。設定後、Claude Desktop を再起動します。

ローカルの claude CLI の場合:

claude mcp add xserver \
  --env XSERVER_API_KEY='発行したキー' \
  --env XSERVER_SERVERNAME='xs123456.xsrv.jp' \
  -- node /absolute/path/to/Xserver_MCP/dist/index.js

環境変数

変数	必須	既定値	説明
`XSERVER_API_KEY`	✅	—	サーバーパネルで発行した APIキー
`XSERVER_SERVERNAME`		`/me` から自動解決	初期ドメイン。Xserver は `<サーバーID>.xsrv.jp`、Xserver ビジネスは `<サーバーID>.xbiz.jp`
`XSERVER_API_BASE`		`https://api.xserver.ne.jp/v1`	APIのベースURL（https 必須）
`XSERVER_TIMEOUT_MS`		`30000`	1リクエストあたりのタイムアウト

XSERVER_SERVERNAME を省略した場合、最初のツール呼び出し時に GET /me からサーバー名を取得してキャッシュします。

APIキーをコマンド行に直接書くと PowerShell の履歴ファイルに平文で残ります。入力を伏せ字にして渡すには:

$env:XSERVER_API_KEY = [Runtime.InteropServices.Marshal]::PtrToStringBSTR([Runtime.InteropServices.Marshal]::SecureStringToBSTR((Read-Host "API key" -AsSecureString)))

提供ツール

ツール	用途
`xserver_account_info`	`GET /me`。契約種別・有効期限・サーバー名・権限種別。まずこれで疎通確認
`xserver_server_status`	サーバー状況。ディスク使用量・ファイル数・各種リソース件数のサマリと生JSON
`xserver_list`	リソース一覧（`resource` を指定）。domain / mail / cron / subdomain / ssl / php / mysql / ftp / dns など
`xserver_get`	任意パスへの GET。他のツールで届かないエンドポイント用の逃げ道
`xserver_endpoints`	このサーバーが把握しているエンドポイント一覧と確度を返す

xserver_list で 404 が返る場合は、xserver_endpoints で確度を確認したうえで、公式リファレンスの正しいパスを xserver_get に渡してください。

エンドポイントの検証状況

Xserver ビジネス契約・permission_type: "read" のキーで npm run check を実行した実測結果です。

verified（200 が返る）

パス	レスポンス
`/me`	`{service_type, expires_at, servername, permission_type}`
`/server/{servername}/server-info`	`{server_id, hostname, ip_address, os, cpu, ...}`
`/server/{servername}/server-info/usage`	`{disk: {quota_gb, used_gb, file_limit, file_count}, counts: {...}}`
`/server/{servername}/domain`	`{domains: [{domain, type, ssl, memo, is_awaiting}]}`
`/server/{servername}/mail`	`{accounts: [...]}`
`/server/{servername}/cron`	`{crons: [...], notification_email}`
`/server/{servername}/subdomain`	`{subdomains: [...]}`
`/server/{servername}/ssl`	`{ssl_list: [{id, common_name, type, expires_at, status}]}`
`/server/{servername}/ftp`	`{accounts: [...]}`
`/server/{servername}/dns`	`{records: [...]}`
`/server/{servername}/mail-filter`	`{filters: [...]}`

disk.file_limit が 0 の場合は上限なしを意味します。

requires-params（422 VALIDATION_ERROR）

access-log / error-log

エンドポイントは存在しますが、domain パラメータが必須です（省略すると {"error":{"code":"VALIDATION_ERROR","message":"ドメインは必須です"}}）。

xserver_list(resource="access-log", query={ "domain": "example.com" })

domain の値は xserver_list(resource="domain") で取得できます。 npm run check は最初のドメインを自動で補って検証します。

unavailable（404 NOT_FOUND）

php / mysql / mysql-user / wordpress / mail-forward / backup

これらは xserver_list の候補から除外してあり、指定すると「このパスには存在しない」旨を説明して返します。機能自体は別パスに存在する可能性があるため、公式リファレンスで正しいパスを確認のうえ xserver_get を使ってください。

なお verified は上記1アカウント（Xserver ビジネス・読み取り権限）での結果です。プランや権限が異なれば同じパスでも 403 になり得ます。

日本語メッセージが文字化けする場合

APIのエラーメッセージは UTF-8 の日本語です。Windows のコンソールは既定で cp932 のため化けます。PowerShell で先に実行してください:

[Console]::OutputEncoding = [Text.Encoding]::UTF8

セキュリティ

APIキーは環境変数からのみ読み込み、ログにもツールの応答にも出力しません。
xserver_get に渡されたパスは正規化のうえ検証し、XSERVER_API_BASE とホストが一致しない URL は拒否します（Authorization ヘッダを別ホストへ送出させないため）。.. を含むパスも拒否します。
HTTP メソッドは GET に固定されており、書き込み系は実装されていません。書き込みを追加する場合は XserverClient にメソッドを足すことになりますが、誤操作のリスクを踏まえて明示的なオプトイン（環境変数など）でガードすることを推奨します。

開発

npm run build      # dist/ へコンパイル
npm run watch      # 差分ビルド
npm run typecheck  # 型チェックのみ
npm run check      # API 疎通チェック（要 XSERVER_API_KEY）

src/ の構成:

config.ts — 環境変数の読み込みと検証
client.ts — HTTPクライアント。認証・パス正規化・レート制限ヘッダ・エラー整形
endpoints.ts — エンドポイントカタログ（確度付き）
tools.ts — MCP ツールの定義と登録
index.ts — stdio サーバーのエントリポイント
check.ts — 疎通チェックCLI

実装メモ

MCP SDK は v1 系（@modelcontextprotocol/sdk@^1.30.0）を使用しています。 v2 系（@modelcontextprotocol/server@2.0.0）が 2026-07-27 にリリースされていますが、リリース直後で各 MCP クライアントの対応状況が読めないため、広く動作実績のある v1 系を選択しました。v1 は少なくとも v2 リリースから6か月はメンテナンスされます。

ライセンス

MIT

Available Tools

5 tools

xserver_account_infoXServer account infoA

Read-only

Fetch the XServer contract and account information tied to the configured API key (GET /me): service type, expiry date, server name, and permission type. Use this first to confirm the key works and to discover the server name.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint, openWorldHint) are consistent with description. Description adds that it uses the configured API key and is a GET request, aligning with read-only behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first describes what it does, second gives usage guidance. No fluff, all information is relevant and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no parameters or output schema. Description covers purpose, API endpoint, returned fields, and usage context (first use, key confirmation). Complete for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so schema coverage is 100%. Description doesn't need to add parameter details. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it fetches contract and account info. Lists specific fields (service type, expiry date, server name, permission type) and the endpoint (GET /me). Distinguishes from siblings focused on endpoints or server status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly recommends using this first to confirm the key works and discover the server name. Provides clear context for when to use, though doesn't explicitly state when not to use or list alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xserver_endpointsList known XServer API endpointsA

Read-only

List the XServer API endpoints this server knows about, with a status marker. verified paths returned 200 when probed against a live account; unavailable paths returned 404; likely paths are unprobed guesses. Use this to pick a path for xserver_get.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint annotation, the description details how status markers are determined (verified, unavailable, likely based on probing), adding behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, purpose first, no redundancy. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description explains what is returned and its interpretation, making it complete for a zero-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description adds no parameter info but that's unnecessary; it focuses on output semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'List the XServer API endpoints this server knows about, with a status marker' and explains the status values, which clearly defines the tool's purpose and differentiates it from siblings like xserver_get.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides direct guidance: 'Use this to pick a path for xserver_get,' telling the agent when and why to use this tool before xserver_get.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xserver_getGET any XServer API pathA

Read-only

Issue an arbitrary read-only GET against the XServer API. Use this when a specific endpoint is not covered by the other tools. The path is relative to the API base (https://api.xserver.ne.jp/v1), e.g. "/server/xs123456.xsrv.jp/cron". Writes (POST/PUT/DELETE) are not supported by this server.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path relative to the API base, e.g. /me or /server/{servername}/domain. A leading /v1 or a full https://api.xserver.ne.jp/v1/... URL is also accepted.
`query`	No	Optional query string parameters.

TDQS

A4.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's mention of 'read-only GET' and 'Writes not supported' adds little behavioral insight beyond what is already provided. The description does not contradict annotations, but it does not add significant new behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the tool's core purpose, and every sentence is necessary. There is no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 parameters, no output schema, strong annotations), the description provides all essential context: base URL, relative path, example, scope (uncovered endpoints), and restrictions (no writes). It is fully adequate for the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, covering both 'path' and 'query' parameters. The description adds valuable context: the path is 'relative to the API base (https://api.xserver.ne.jp/v1)', with an example path '/server/xs123456.xsrv.jp/cron'. It also clarifies that query parameters are optional and that the path can accept a full URL. This meaningfully supplements the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool issues 'an arbitrary read-only GET against the XServer API' for endpoints not covered by other tools. It uses specific action verb 'issue' and resource 'read-only GET', and distinguishes from sibling tools by stating 'when a specific endpoint is not covered by the other tools'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides guidance: 'Use this when a specific endpoint is not covered by the other tools.' It also specifies what not to use it for: 'Writes (POST/PUT/DELETE) are not supported by this server.' 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.

xserver_listList an XServer resourceA

Read-only

List a per-server resource. Available resources: domain, mail, cron, subdomain, ssl, ftp, dns, mail-filter, access-log, error-log. access-log and error-log require query={ domain }. These paths returned 404 when probed and are not available: php, mysql, mysql-user, wordpress, mail-forward, backup. On an unexpected 404, call xserver_endpoints and then xserver_get with the exact path.

ParametersJSON Schema

Name	Required	Description
`query`	No	Optional query string parameters, e.g. { limit: "50" }.
`resource`	Yes	Resource key. One of: domain, mail, cron, subdomain, ssl, ftp, dns, mail-filter, access-log, error-log.
`servername`	No	Server name, e.g. xs123456.xsrv.jp. Defaults to the configured/resolved one.

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, openWorldHint), specifies required query parameter for access-log and error-log, documents unavailable paths, and describes error recovery pattern.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise, front-loaded with core purpose, then lists resources, special requirements, unavailable paths, and fallback advice. Every sentence is necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameter constraints, unavailable resources, and error handling. No output schema, but response structure is implied by 'list' operation. Sufficient for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all parameters (100%). Description adds value by listing allowed resource values (though not as enum) and clarifying when query is required (for access-log and error-log).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists per-server resources and enumerates available ones, distinguishing from siblings like xserver_get (which gets by exact path) and xserver_endpoints (which discovers endpoints).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists available resources and those that are not available (returned 404). Provides alternative guidance: on unexpected 404, call xserver_endpoints then xserver_get.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

xserver_server_statusXServer server statusA

Read-only

Fetch server status: metadata plus resource usage (disk quota and usage, file counts, and counts of domains, subdomains, mail accounts, FTP accounts and MySQL databases). This is the tool to use for questions like 'how is my server doing' or 'how much disk is left'.

ParametersJSON Schema

Name	Required	Description	Default
`servername`	No	Server name, e.g. xs123456.xsrv.jp. Defaults to XSERVER_SERVERNAME, or is resolved from GET /me.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint and openWorldHint; description adds specific resource metrics (disk quota, file counts, domain counts) not in schema, providing helpful behavioral context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: first defines what the tool does, second gives concrete query examples. No fluff, front-loaded, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, but description lists returned data categories (metadata, disk usage, counts of various items). Missing exact output format but sufficient for agent to infer structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds value by explaining default resolution: 'Defaults to XSERVER_SERVERNAME, or is resolved from GET /me.' This clarifies optional parameter behavior beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it fetches server status with metadata and resource usage. The title corroborates. It distinguishes from sibling tools like xserver_endpoints or xserver_account_info by specifying health/resource monitoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit example queries ('how is my server doing', 'how much disk is left') indicating appropriate use cases. Lacks explicit when-not-to-use, but examples are clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jul 28, 2026
- First observedxserver_account_info
- First observedxserver_endpoints
- First observedxserver_get
- First observedxserver_list
- First observedxserver_server_status

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: endpoints discovery, account info, server status, resource listing, and generic GET. There is no overlap, and the generic GET is reserved for uncovered endpoints.

Naming Consistency5/5

All tool names follow a consistent pattern: 'xserver_' prefix with lowercase and underscores. The names use a mix of nouns (endpoints, account_info, server_status) and verbs (list, get), but the convention is uniform.

Tool Count5/5

Five tools is appropriate for the scope of the server, covering essential read-only operations for the XServer API without being excessive or insufficient.

Completeness4/5

The toolset provides near-complete read-only coverage, including account info, server status, resource listing, and a generic GET for missing endpoints. A minor gap is the lack of support for write operations, but that is by design.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
turva-mcp A
dev.turva
Read-only MCP server for turva.dev, an agent-readiness audit and advisory service.
Autonomous Agents Security Developer Tools
42
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2

Related MCP Servers

MariaDB MCP Server
Databases Search
abel9851
A
license
Not graded
quality
D
maintenance
An MCP server implementation that enables Claude to execute read-only queries against MariaDB databases and explore database schemas through natural language.
Updated a year ago (2025-03-26 17:34 UTC)
20
MIT
@rarecloudio/mcp-serverofficial
Cloud Platforms Developer Tools Payments & Billing
RareCloudio
A
license
A
quality
B
maintenance
Read-only MCP server for the RareCloud API, enabling AI agents to list servers, browse the catalog, check billing, and plan deployments.
Updated 2 months ago (2026-07-14 21:28 UTC)
100
16
MIT
MySQL MCP Server
Databases Developer Tools
Ahngbeom
A
license
Not graded
quality
D
maintenance
A read-only MCP server that enables Claude Code to access MySQL databases, allowing safe querying with SELECT, SHOW, DESCRIBE, and EXPLAIN.
Updated 8 months ago (2026-01-14 09:48 UTC)
32
MIT
masaro-infra-mcpofficial
Cloud Platforms Networking & Infrastructure
masaro-media
F
license
Not graded
quality
C
maintenance
A secure MCP server providing read-only tools to interact with Cloudflare, Coolify, and other infrastructure services, enabling AI clients to safely diagnose and validate environments.
Updated 2 months ago (2026-07-04 21:58 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/masp047/Xserver_MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Xserver MCP

重要な前提

セットアップ

APIキーの発行

動作確認

Claude Desktop への登録

環境変数

提供ツール

エンドポイントの検証状況

日本語メッセージが文字化けする場合

セキュリティ

開発

実装メモ

ライセンス

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

@rarecloudio/mcp-serverofficial

masaro-infra-mcpofficial

Latest Blog Posts

MCP directory API