What can you do with this server?

This MCP server provides Ubuntu system monitoring and diagnostics, allowing you to query system information, resource usage, and service status. * System Overview (get_system_overview): Combined summary of OS info, uptime, and CPU/memory/disk usage. * CPU Info (get_cpu_info): CPU model, core count, usage rate, and load averages. * Memory Info (get_memory_info): Detailed memory and swap usage (from /proc/meminfo and free -m). * Disk Info (get_disk_info): Disk usage and mount points via df -h and lsblk. * Network Info (get_network_info): Network interface status, connection status, and send/receive statistics. * Running Services (get_running_services): List systemd services filtered by state — running (default), failed, or all. * Top Processes (get_top_processes): Top resource-consuming processes, sortable by cpu (default) or memory, with a configurable limit of 1–50 (default 15). * Security Audit: Check firewall, SSH config, sudo, auth logs, updates, and SUID files — returns a score and actionable findings. * Network Insights: Diagnose interfaces, routing, DNS, open ports, connections, and bandwidth statistics.

Which integrations are available for this server?

Provides tools to retrieve system information (CPU, memory, disk, network, services, processes) from an Ubuntu system.

How do I use ubuntu-insights?

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., "@ubuntu-insights show me current CPU and memory usage" 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.

ubuntu-insights

by duelist2021jp

Overview Schema Related Servers Score Discussions

JavaScript

Local

mcp-ubuntu-insights

Ubuntu のシステム情報・リソース使用量を Bob に提供する MCP サーバーです。 CPU・メモリ・ディスク・ネットワーク・サービス・プロセス情報に加え、セキュリティ診断 と ネットワーク詳細診断 を自然言語で問い合わせられるようになります。

動作環境

項目	要件
OS	Ubuntu 24.04 LTS（WSL2 含む）
Node.js	v18 以上
MCP クライアント	IBM Bob、AWS Kiro、Claude Code

Related MCP server: System Info MCP Server

ディレクトリ構成

mcp-ubuntu-insights/
├── src/
│   └── index.ts        # サーバー実装（TypeScript）
├── build/
│   └── index.js        # コンパイル済みバイナリ（自動生成）
├── package.json
├── tsconfig.json
└── README.md

登録設定ファイル（ワークスペーススコープ）:

<ワークスペース>/
└── .bob/
    └── mcp.json        # Bob への MCP サーバー登録

セットアップ手順

まず Node.js がインストール済みかどうかを確認してください。

node --version
npm --version

v18.0.0 以上が表示された場合 → 手順 A（インストール済み）へ
command not found と表示された場合 → 手順 B（未インストール）へ

手順 A：Node.js インストール済みの場合

A-1. リポジトリのクローン

git clone https://github.com/duelist2021jp/mcp-ubuntu-insights.git
cd mcp-ubuntu-insights

A-2. 依存パッケージのインストールとビルド

npm install
npm run build

成功すると build/index.js が生成されます。

ls build/   # index.js が存在すれば OK

A-2a. sudoers の設定（`get_security_audit` を使う場合）

get_security_audit ツールは UFW のステータス取得に sudo を使用します。 MCP サーバーは非対話プロセスのため、パスワードなしで実行できるよう NOPASSWD ルールの追加が必要です。

# ufw コマンドのみに限定した NOPASSWD ルールを追加
echo "<あなたのユーザー名> ALL=(ALL) NOPASSWD: /usr/sbin/ufw" \
  | sudo tee /etc/sudoers.d/mcp-ufw
sudo chmod 440 /etc/sudoers.d/mcp-ufw

# 構文チェック（"parsed OK" と表示されれば成功）
sudo visudo -c

注意: <あなたのユーザー名> は whoami の出力に置き換えてください。この設定を省略した場合、get_security_audit の firewall チェックで UFW のステータスが正しく取得されず、ファイアウォールが無効と誤検知されることがあります。

A-3. Bob への登録（`mcp.json`）

node の絶対パスを確認します。

which node
# 例（システム標準）: /usr/bin/node
# 例（nvm）         : /home/testuser/.nvm/versions/node/v24.18.0/bin/node

ワークスペース内の .bob/mcp.json を作成または編集して以下を追加します。 パスは which node と pwd の結果に合わせて変更してください。

# build/index.js の絶対パスを確認
pwd   # 例: /home/testuser/bob-study/mcp-ubuntu-insights

.bob/mcp.json（ワークスペースルートの .bob/ ディレクトリに配置）

{
  "mcpServers": {
    "ubuntu-insights": {
      "command": "/usr/bin/node",
      "args": ["/home/youruser/path/to/mcp-ubuntu-insights/build/index.js"]
    }
  }
}

A-4. 接続確認

mcp.json を保存すると Bob がホットリロードし、MCP パネルに ubuntu-insights が表示されます。表示されない場合は Bob を再起動してください。

動作確認（コマンドラインから直接テスト）:

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0"}}}' \
  | node build/index.js
# {"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true}},...}}

手順 B：Node.js 未インストールの場合（nvm 経由）

B-1. nvm のインストール

# nvm のインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash

# シェルに nvm を読み込む
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

# Node.js LTS をインストール
nvm install --lts

# バージョン確認
node --version   # 例: v24.18.0
npm --version    # 例: 11.16.0

注意: 次回以降のシェル起動時も nvm が自動的に読み込まれるよう、インストーラーが ~/.bashrc へ追記します。手動で追加する場合は以下を ~/.bashrc に記述してください。
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

B-2. リポジトリのクローン・ビルド

git clone https://github.com/<your-username>/mcp-ubuntu-insights.git
cd mcp-ubuntu-insights
npm install
npm run build

B-2a. sudoers の設定（`get_security_audit` を使う場合）

手順 A-2a と同様に sudoers の NOPASSWD ルールを設定してください。

→ A-2a. sudoers の設定を参照

B-3. Bob への登録（`mcp.json`）

nvm でインストールした Node.js の絶対パスを確認します。

which node
# 例: /home/testuser/.nvm/versions/node/v24.18.0/bin/node

重要: Bob は ~/.bashrc を読み込まないため PATH に nvm のパスが通っていません。 command には node ではなく必ず 絶対パス を指定してください。

.bob/mcp.json（ワークスペースルートの .bob/ ディレクトリに配置）

{
  "mcpServers": {
    "ubuntu-insights": {
      "command": "/home/testuser/.nvm/versions/node/v24.18.0/bin/node",
      "args": ["/home/testuser/bob-study/mcp-ubuntu-insights/build/index.js"]
    }
  }
}

B-4. 接続確認

mcp.json を保存すると Bob がホットリロードし、MCP パネルに ubuntu-insights が表示されます。表示されない場合は Bob を再起動してください。

動作確認（コマンドラインから直接テスト）:

echo '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"0"}}}' \
  | node build/index.js
# {"result":{"protocolVersion":"2024-11-05","capabilities":{"tools":{"listChanged":true}},...}}

ゼロからスクラッチで構築する場合

GitHub からクローンせず、自分でファイルを作成する場合の手順です。

2. プロジェクトのセットアップ

ワークスペース内にプロジェクトディレクトリを作成し、依存パッケージをインストールします。

# ワークスペースへ移動（例）
cd /home/testuser/bob-study

# ディレクトリ作成
mkdir -p mcp-ubuntu-insights/src
cd mcp-ubuntu-insights

# package.json の初期化（後述の内容で上書きします）
npm init -y

# 依存パッケージのインストール
npm install @modelcontextprotocol/sdk zod
npm install -D @types/node typescript

3. 設定ファイルの作成

package.json

{
  "name": "mcp-ubuntu-insights",
  "version": "0.1.0",
  "description": "MCP server for Ubuntu system insights",
  "type": "module",
  "scripts": {
    "build": "tsc && chmod 755 build/index.js"
  },
  "bin": {
    "mcp-ubuntu-insights": "./build/index.js"
  },
  "files": ["build"],
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.29.0",
    "zod": "^3.25.76"
  },
  "devDependencies": {
    "@types/node": "^22.20.0",
    "typescript": "^5.9.3"
  }
}

tsconfig.json

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

4. サーバー実装（`src/index.ts`）

src/index.ts を作成します。詳細は src/index.ts を参照してください。
ファイルの骨格は以下の通りです。

#!/usr/bin/env node
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
// ...（各ツールの registerTool 呼び出し）

const server = new McpServer({ name: "mcp-ubuntu-insights", version: "0.1.0" });

// ツールを登録 → server.registerTool("ツール名", { description, inputSchema }, handler)

async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("mcp-ubuntu-insights running on stdio");
}

main().catch((error) => {
  console.error("Fatal error:", error);
  process.exit(1);
});

ログは必ず console.error を使用してください。
console.log は MCP プロトコルの stdout チャネルに書き込まれるため、接続が壊れます。

5. ビルド

# mcp-ubuntu-insights ディレクトリで実行
npm run build

成功すると build/index.js が生成されます。

ls build/   # index.js が存在すれば OK

6. Bob への登録（`mcp.json`）

ワークスペース内の .bob/mcp.json にサーバーを登録します。 node の絶対パスと build/index.js の絶対パスは環境に合わせて変更してください。 → 詳細は手順 A-3 または手順 B-3 を参照してください。

ワークスペーススコープ（.bob/mcp.json）: このワークスペースを開いている間のみ有効
グローバルスコープ（~/.bob/settings/mcp.json）: 全ワークスペースで有効同名のサーバーはワークスペーススコープがグローバルスコープを上書きします。

7. 接続確認

mcp.json を保存すると Bob がホットリロードし、MCP パネルに ubuntu-insights が表示されます。表示されない場合は Bob を再起動してください。

提供ツール一覧

基本ツール（v0.1）

ツール名	説明	パラメーター
`get_system_overview`	OS・稼働時間・CPU/メモリ/ディスクの総合概要	なし
`get_cpu_info`	CPUモデル・コア数・ロードアベレージ	なし
`get_memory_info`	メモリ・スワップ詳細（`/proc/meminfo` + `free -m`）	なし
`get_disk_info`	`df -h` + `lsblk` のディスク情報	なし
`get_network_info`	IPアドレス・接続状況・送受信統計（基本）	なし
`get_running_services`	systemd サービス一覧	`state`: `running`（既定）/ `failed` / `all`
`get_top_processes`	リソース消費上位プロセス	`sortBy`: `cpu`（既定）/ `memory`、`limit`: 1〜50（既定 15）

新ツール（v0.2）

`get_security_audit` — セキュリティ診断・コンプライアンスレポート

パラメーター	型	既定	説明
`checks`	`string[]`	`["all"]`	実施するチェック項目

checks に指定できる値:

値	チェック内容
`firewall`	UFW ステータス・カーネルネットパラメーター（ip_forward 等）
`ssh`	sshd_config（PermitRootLogin・PasswordAuthentication・Protocol・MaxAuthTries 等）
`sudo`	sudoers の NOPASSWD・UID 0 アカウント・空パスワードアカウント
`auth_log`	`/var/log/auth.log` の認証失敗ログ件数
`updates`	unattended-upgrades の設定状況
`suid`	SUID/SGID ファイル・ワールドライタブルファイルの検出
`all`	上記すべて（既定）

戻り値の構造:

{
  "summary": {
    "score": 67,        // 0–100 のセキュリティスコア
    "rating": "要改善", // 良好 / 要改善 / 問題あり / 危険
    "totalFindings": 5,
    "bySeverity": { "critical": 0, "high": 1, "medium": 2, "low": 2 }
  },
  "findings": [
    {
      "severity": "high",
      "item": "ファイアウォール無効",
      "detail": "UFW が無効またはインストールされていません。",
      "recommendation": "sudo ufw enable && sudo ufw default deny incoming ..."
    }
  ],
  "rawData": { ... }
}

`get_network_insights` — ネットワーク詳細診断

パラメーター	型	既定	説明
`checks`	`string[]`	`["all"]`	実施するチェック項目

checks に指定できる値:

値	チェック内容
`interfaces`	インターフェース状態（UP/DOWN）・ARPテーブル・NetworkManager状態
`routing`	デフォルトゲートウェイ・ルーティングテーブル・ゲートウェイへの ping
`dns`	`/etc/resolv.conf`・systemd-resolved 状態・8.8.8.8 への疎通確認
`ports`	待受ポート一覧・危険ポート（Telnet/FTP/NFS等）の検出
`connections`	確立済みTCP接続・接続数異常の検出
`bandwidth`	`/proc/net/dev` の送受信バイト数・エラー・ドロップ統計
`all`	上記すべて（既定）

戻り値の構造:

{
  "summary": {
    "totalFindings": 1,
    "bySeverity": { "critical": 0, "high": 1, "medium": 0, "low": 0, "info": 0 },
    "externalConnectivity": "ok",      // ok / unreachable / unchecked
    "gatewayConnectivity": "ok"        // ok / unreachable / unchecked
  },
  "findings": [
    {
      "severity": "high",
      "item": "危険なポートが公開されている: 23/Telnet（平文通信）",
      "detail": "0.0.0.0:23 で Telnet が待ち受けています。",
      "recommendation": "サービスを停止するか SSH トンネリングに移行してください。"
    }
  ],
  "network": {
    "interfaces": [...],
    "bandwidthStats": { "eth0": { "rxBytes": ..., "txBytes": ... } },
    "dnsServers": ["127.0.0.53"],
    "defaultRoutes": ["default via 172.30.192.1 dev eth0"],
    "listeningPorts": [...],
    "establishedConnections": 12
  },
  "rawData": { ... }
}

使い方の例

Bob のチャットで以下のように質問できます。

システムの概要を教えて
CPU の負荷を確認して
メモリ使用量を詳しく見せて
失敗しているサービスはある？
メモリ消費上位 20 件のプロセスを教えて

# v0.2 新機能
セキュリティ診断レポートを出して
SSH の設定に問題はある？
ファイアウォールの状態を確認して
ネットワークの問題を診断して
外部と通信できているか確認して
危険なポートが開いていないか確認して

ツールの追加・拡張

新しいツールを追加するには src/index.ts に server.registerTool(...) を追記し、ビルドし直します。

# 編集後にビルド
cd /home/testuser/bob-study/mcp-ubuntu-insights
npm run build

ビルドが完了すると Bob が自動的に新しいツールを認識します（再起動不要）。

トラブルシューティング

MCP パネルにサーバーが表示されない

Bob を再起動する
.bob/mcp.json の JSON 構文エラーがないか確認する
node と build/index.js のパスが正しい絶対パスであることを確認する
コマンドラインから直接実行して起動エラーがないか確認する（上記「接続確認」参照）

`node: command not found` になる

mcp.json の command には node ではなく nvm でインストールした Node.js の絶対パス を指定してください。
Bob は nvm のシェル設定（~/.bashrc）を読み込まないため、PATH に nvm のパスが通っていません。

# 正しい絶対パスを確認
which node

`get_security_audit` でファイアウォールが「無効」と誤検知される

UFW はインストール・有効化済みにもかかわらず ファイアウォール無効 と報告される場合は、 sudoers の NOPASSWD 設定が不足しています。

# 設定されているか確認
sudo cat /etc/sudoers.d/mcp-ufw

表示されない、または ufw が含まれていない場合は A-2a. sudoers の設定を参照して設定してください。

ビルドエラーが出る

TypeScript のバージョンや @modelcontextprotocol/sdk の API 変更が原因の場合があります。

# 依存パッケージを最新化して再ビルド
npm update
npm run build

Available Tools

7 tools

get_cpu_infoA

CPU使用率・コア数・モデル情報を返します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so the description carries the full burden. It explicitly states the tool returns information, implying a read-only operation. This is sufficient for a simple tool with no parameters.

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?

Single sentence, no unnecessary words, well-structured and front-loaded with the key purpose.

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, so description compensates by listing return values. However, lacks details on units or format (e.g., usage percentage). Adequate for the tool's simplicity.

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, baseline 4. The description adds meaning beyond the empty schema by specifying what information (CPU usage, cores, model) is returned.

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 returns CPU usage, core count, and model information. This distinguishes it from sibling tools like get_disk_info or get_memory_info.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives, but the name and sibling tools imply it is for CPU information. No when-not-to or prerequisites mentioned.

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

get_disk_infoA

ディスク使用量・マウントポイント情報を返します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations provided; description does not mention any behavioral traits (e.g., read-only, no side effects). Agent cannot infer safety without prior knowledge.

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?

Single concise sentence with no wasted words, front-loaded with key information.

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?

Simple tool with no params and no output schema; description adequately covers purpose. Minor omission: no mention of instantaneous nature or side-effect-free behavior.

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 description adds no extra meaning; baseline 4 applies since schema coverage is trivially 100%.

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?

Description clearly states 'returns disk usage and mount point information' with specific verb+resource, distinguishing it from sibling tools like get_cpu_info, get_memory_info.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs. siblings. User must infer context from names alone.

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

get_memory_infoA

メモリ・スワップの使用量を詳しく返します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

Annotations are absent, so the description carries full burden. It only states 'returns detailed usage' without disclosing behavioral traits like read-only nature, permissions required, or potential side effects. This is a significant gap for a system information tool.

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 extremely concise, consisting of a single sentence that directly states the tool's purpose. Every word is necessary, and it is front-loaded.

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

Completeness3/5

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

With no output schema, the description should clarify what 'detailed' means or what metrics are returned. It fails to do so, leaving ambiguity. However, for a simple tool with no parameters, it is minimally adequate.

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?

There are no parameters, so baseline is 4. The description adds no parameter information, but none is needed.

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 returns detailed memory and swap usage, which is a specific verb+resource. It effectively distinguishes from sibling tools like get_cpu_info, get_disk_info, etc., which focus on other system metrics.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The usage is implied by the tool name and description, but there are no when-not or alternative recommendations.

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

get_network_infoA

ネットワークインターフェース・接続状況・統計情報を返します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits beyond returning data, such as permissions or side effects. For a zero-annotation tool, more detail would be helpful.

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 a single concise sentence with no unnecessary information.

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

Completeness3/5

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

While the description covers the basic purpose, it lacks details about output format, real-time nature, or access requirements. It is adequate but not comprehensive.

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?

There are no parameters, so the description does not need to add parameter info. The baseline score for zero parameters is 4.

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 returns network interface, connection status, and statistical information, distinguishing it from sibling tools like get_cpu_info or get_disk_info.

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

Usage Guidelines3/5

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

The description only states what it does without any guidance on when to use it vs. alternatives. Usage is implied but not explicit.

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

get_running_servicesC

systemdサービスの稼働状況一覧を返します。

ParametersJSON Schema

Name	Required	Description	Default
`state`	No	取得するサービス状態のフィルター	running

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states returns a list but does not mention any side effects, permissions needed, or output format. A mutation or read-only status is not clarified.

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

Conciseness4/5

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

The description is a single sentence, concise and front-loaded. It is efficient for a simple tool but could be expanded with minimal effort.

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

Completeness2/5

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

Given no output schema and a single parameter, the description lacks completeness. It does not describe the return structure (e.g., list of service names, status details) or any behavior on non-systemd systems.

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

Parameters3/5

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

Schema description coverage is 100% as the only parameter 'state' has a description. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose4/5

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

The description 'systemdサービスの稼働状況一覧を返します' clearly states the tool returns a list of systemd service statuses. It specifies the resource (systemd services) and action (returns list). It distinguishes from siblings like get_cpu_info which focus on hardware resources.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention filtering options or when to choose specific states, nor does it indicate any prerequisites or limitations.

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

get_system_overviewA

OS情報・稼働時間・CPU/メモリ/ディスクの概要をまとめて返します。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It states the tool returns a summary overview, which implies a read-only operation with no side effects. However, it does not disclose any potential performance impact, data freshness, or error conditions.

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?

Single sentence that immediately states what the tool returns. Front-loaded with the key purpose. No filler or redundant information.

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?

Given zero parameters and no output schema, the description adequately conveys the scope of the tool. It covers OS info, uptime, and overview of CPU/memory/disk. However, it lacks details on the output format or specific metrics included, which could aid understanding but is not strictly necessary.

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 schema coverage is 100% and the description adds no param information. Per guidelines, baseline for 0 params is 4. Description is sufficient.

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 returns OS info, uptime, and CPU/memory/disk overview. The verb '返します' explicitly indicates a retrieval operation. This purpose is distinct from sibling tools which provide more detailed specific metrics.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs siblings. However, the sibling tools like get_cpu_info imply this is for a quick summary while siblings are for detailed metrics. Usage context is implicit but not stated.

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

get_top_processesB

CPUまたはメモリ消費量上位のプロセス一覧を返します。

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	返すプロセス数（最大50）
`sortBy`	No	ソート基準: 'cpu' or 'memory'	cpu

TDQS

B3.4/5.0

Behavior2/5

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 does not disclose behavioral traits such as whether the operation is read-only, required permissions, or potential rate limits. The description merely states the function without additional context.

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

Conciseness4/5

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

The description is a single sentence with no extraneous information. However, it is slightly too brief and could include more context without sacrificing conciseness.

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

Completeness3/5

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

For a simple tool with full schema coverage, the description is minimally adequate. However, it lacks usage guidelines and behavioral transparency, making it less complete than it could be.

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

Parameters3/5

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 minimal meaning beyond the schema by mentioning sorting by CPU or memory, but the schema already defines the 'sortBy' enum with those values.

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 returns a list of top processes by CPU or memory consumption, which is a specific verb and resource. It distinguishes from siblings like get_cpu_info, get_disk_info, etc., which focus on system metrics rather than process lists.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool versus alternatives. The description implies usage when top processes are needed, but does not mention exclusions or contexts where sibling tools would be more appropriate.

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.

7 tool updatesv0.1.0Jul 1, 2026
- First observedget_cpu_info
- First observedget_disk_info
- First observedget_memory_info
- First observedget_network_info
- First observedget_running_services
- First observedget_system_overview
- First observedget_top_processes

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct system resource (CPU, disk, memory, network, services, processes) plus a summary. No overlap or ambiguity.

Naming Consistency4/5

All tools use the 'get_' prefix and snake_case, with most following 'get_<resource>_info'. Minor deviations like 'get_running_services' and 'get_system_overview' are acceptable.

Tool Count5/5

Seven tools is well-scoped for a system insights server—enough to cover core resources without being overwhelming.

Completeness4/5

Covers CPU, memory, disk, network, processes, and services. A summary tool provides an overview. Minor gaps exist (e.g., logs, detailed process info) but not critical.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

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

mcp A
com.googleapis.compute
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Cloud Platforms Networking & Infrastructure OS Automation
292
SentinelX MCPOAuth
app.sentinelx
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Shell Access OS Automation
26
sentinelOAuth
io.rootstuff
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Monitoring Observability
21
maxion-mcp-gateway A
io.github.aruuhii2yo
CPU telemetry & benchmarking, SHA-256 hashing, AES-256-GCM storage, AI video/image via Nova.
Monitoring Security AI & Machine Learning
1921

Related MCP Servers

System Monitor MCP Server
OS Automation Monitoring
PraveerT
F
license
Not graded
quality
D
maintenance
Provides system monitoring and management capabilities for Claude CLI, allowing users to view system information, track resource usage, and manage processes through natural language commands.
Updated a year ago (2025-07-06 03:15 UTC)
-
System Info MCP Server
Monitoring OS Automation Observability
srirama7
A
license
Not graded
quality
D
maintenance
Enables comprehensive system monitoring and diagnostics through 18 tools that provide detailed information about CPU, memory, disk usage, network interfaces, running processes, battery status, hardware details, and temperature monitoring. Allows users to query system information and performance metrics through natural language interactions.
Updated a year ago (2025-10-19 04:59 UTC)
24
ISC
MCP System Monitor Server
Monitoring OS Automation Developer Tools
huhabla
A
license
Not graded
quality
D
maintenance
Enables real-time monitoring of system resources including CPU, GPU (NVIDIA, Apple Silicon, AMD/Intel), memory, disk, network, and processes across Windows, macOS, and Linux platforms through natural language queries.
Updated a year ago (2025-07-07 18:36 UTC)
3
MIT
System Stats MCP Server
Monitoring OS Automation Observability
orkuhh
F
license
Not graded
quality
C
maintenance
Provides real-time Linux system monitoring for CPU load, memory usage, disk space, and process activity. This server enables users to retrieve comprehensive performance metrics and resource utilization data through a standardized interface.
Updated 4 months ago (2026-05-09 02:20 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/duelist2021jp/mcp-ubuntu-insights'

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

mcp-ubuntu-insights

動作環境

ディレクトリ構成

セットアップ手順

手順 A：Node.js インストール済みの場合

A-1. リポジトリのクローン

A-2. 依存パッケージのインストールとビルド

A-2a. sudoers の設定（get_security_audit を使う場合）

A-3. Bob への登録（mcp.json）

A-4. 接続確認

手順 B：Node.js 未インストールの場合（nvm 経由）

B-1. nvm のインストール

B-2. リポジトリのクローン・ビルド

B-2a. sudoers の設定（get_security_audit を使う場合）

B-3. Bob への登録（mcp.json）

B-4. 接続確認

ゼロからスクラッチで構築する場合

2. プロジェクトのセットアップ

3. 設定ファイルの作成

4. サーバー実装（src/index.ts）

5. ビルド

6. Bob への登録（mcp.json）

7. 接続確認

提供ツール一覧

基本ツール（v0.1）

新ツール（v0.2）

get_security_audit — セキュリティ診断・コンプライアンスレポート

get_network_insights — ネットワーク詳細診断

使い方の例

ツールの追加・拡張

トラブルシューティング

MCP パネルにサーバーが表示されない

node: command not found になる

get_security_audit でファイアウォールが「無効」と誤検知される

ビルドエラーが出る

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

A-2a. sudoers の設定（`get_security_audit` を使う場合）

A-3. Bob への登録（`mcp.json`）

B-2a. sudoers の設定（`get_security_audit` を使う場合）

B-3. Bob への登録（`mcp.json`）

4. サーバー実装（`src/index.ts`）

6. Bob への登録（`mcp.json`）

`get_security_audit` — セキュリティ診断・コンプライアンスレポート

`get_network_insights` — ネットワーク詳細診断

`node: command not found` になる

`get_security_audit` でファイアウォールが「無効」と誤検知される