Ssh on Yarang's Tech Lair

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Mon, 09 Mar 2026 00:30:00 +0900

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Are you managing an increasing number of servers?

Individually connecting via SSH to check the status of each server is a waste of time. If you could grasp the CPU, memory, and disk usage of all servers at a glance, your work efficiency would improve significantly.

I faced this problem too, so I built a solution.

The Problem: Repetitive Server Monitoring Tasks

If you’re a DevOps engineer or system administrator, you’ve likely faced this situation:

Repeated SSH connections to each server
Manually running commands like top, htop, df
Manually recording status in Excel or Notion
Modifying management scripts as servers increase

This process wastes time and is repetitive work that can lead to mistakes.

The Solution: Server Status Checker Skill

Server Status Checker is a skill for Claude Code that checks the status of all servers in parallel based on your SSH config file.

Key Features

Feature	Description
Automatic SSH Config Parsing	Automatically discovers server list from `~/.ssh/config`
Real-time Status Check	Collects CPU, Memory, Disk, Uptime, Load information
Parallel Connections	Fast status checking with asyncssh (in seconds)
Group Classification	Automatically categorizes by GCP, OCI, GitHub, Blog, Local, etc.
Online/Offline Status	Intuitive status display with ✓ / ✗

Usage

# Check all server status
/server-status-checker

# Check specific server only
/server-status-checker --server mini01

# Output in JSON format
/server-status-checker --json

# Verbose error messages
/server-status-checker --verbose

Output Example

=== Server Status Report ===

[GCP Servers]
✗ gcp-ajou-ec1 - Offline (Authentication failed)
✗ gcp-fcoinfup-ec1 - Offline (Authentication failed)

[OCI Ajou]
✓ oci-ajou-ec1 - Online
 CPU: 15.2% | Memory: 62.3% | Disk: 45.8%
 Uptime: 15 days | Load: 1.23 1.45 1.38
 OS: Ubuntu 22.04 LTS

[Local Servers]
✓ mini01 - Online
 CPU: 6.7% | Memory: 45.2% | Disk: 5.0%
 Uptime: 2 days | Load: 2.17 2.11 1.94
 OS: macOS 26.3.1

Technical Details

SSH Config Parsing

Parses ~/.ssh/config file to automatically extract:

Host (hostname)
HostName (IP address or domain)
User (username)
Port (port number)
IdentityFile (SSH key path)

Asynchronous Parallel Processing

Uses Python’s asyncssh library to connect to all servers simultaneously:

async def check_server(host: str):
 # SSH connection and command execution
 result = await asyncssh.connect(...)
 return status

Checking 30 servers sequentially takes 5 minutes, but parallel processing completes in under 30 seconds.

Automatic Group Classification

Automatically classifies based on server name patterns:

Group	Pattern	Examples
GCP	`gcp-` prefix	gcp-ajou-ec1, gcp-fcoinfup-ec1
OCI Ajou	`oci-ajou-` prefix	oci-ajou-ec1
OCI Fcoinfup	`oci-fcoinfup-` prefix	oci-fcoinfup-ec1
GitHub	`github-as-` prefix	github-as-actions
Blog	`blog`	blog
Local	`mini`, `mac`	mini01, macbook-pro

System Metrics Collection

Collects the following information from each server:

Linux:

CPU: /proc/stat or psutil.cpu_percent()
Memory: /proc/meminfo or psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: /proc/uptime or psutil.boot_time()
Load: /proc/loadavg or os.getloadavg()

macOS:

CPU: psutil.cpu_percent()
Memory: psutil.virtual_memory()
Disk: psutil.disk_usage()
Uptime: psutil.boot_time()
Load: os.getloadavg()

GitHub Release

This skill is released as open source.

🔗 GitHub: https://github.com/yarang/skill-server-status-checker

Installation

git clone https://github.com/yarang/skill-server-status-checker.git
cp -r skill-server-status-checker ~/.claude/skills/server-status-checker

Business Value

Aspect	Improvement
Time Savings	90% reduction in server check time (5 min → 30 sec)
Real-time Monitoring	Immediate server status awareness
Centralized Management	Manage all servers with single SSH config file
Automation	Minimize human errors by eliminating repetitive tasks

Use Cases

1. Daily Server Health Check

Every morning, check all server status with a single /server-status-checker command.

2. Incident Response

When an incident occurs, immediately identify offline servers and take action.

3. Capacity Planning

Monitor disk usage trends to plan capacity expansion in advance.

4. Performance Monitoring

Track CPU and memory usage to identify bottlenecks.

Conclusion

Server Status Checker is more than a simple server status checking tool. It’s a productivity tool that helps DevOps engineers and system administrators focus on core tasks by eliminating repetitive work.

By leveraging the standardized SSH config file and providing fast results through parallel processing, you no longer need to connect to each server individually. Check the health status of all servers with a single command.

Through AI and automation, let’s improve system management efficiency and focus on more important problems.

Related Projects:

domain-checker - Domain availability checker tool

Tags: #DevOps #ServerMonitoring #OpenSource #Claude #AI #Productivity #SSH

Korean Version: 한국어 버전

[Cloud Monitor] MCP Tool Structure and Pros/Cons Analysis

Tue, 03 Mar 2026 15:02:49 +0900

[server-monitor] MCP Tool Structure and Pros/Cons Analysis

Overview

This document analyzes the structure, advantages, and disadvantages of the MCP (Model Context Protocol) tools implemented in the server-monitor project. A total of 13 MCP tools are provided, categorized into 8 existing Discord MCP tools and 5 new Cloud Monitor MCP tools.

Architecture Overview
Detailed Tool Analysis
Architecture Structure
Advantages
Disadvantages and Improvements
Conclusion

Architecture Overview

FastMCP-based Architecture

graph TB
 subgraph MCP Server
 A[FastMCP Server] --> B[Discord Tools]
 A --> C[Cloud Monitor Tools]
 B --> D[Gateway Service]
 C --> D
 D --> E[Discord API]
 end

 subgraph Cloud Monitor
 F[SSH Monitor] --> G[OCI Servers]
 F --> H[Mac mini]
 G --> I[Ubuntu]
 H --> J[macOS]
 end

 subgraph Discord
 K[Bot] --> L[Channels]
 K --> M[Threads]
 end

MCP Tool Categories

Category	Tool Count	Main Functions
Discord MCP	8	Message, thread management
Cloud Monitor MCP	5	Server monitoring, metrics collection
Total	13	Integrated monitoring platform

Detailed Tool Analysis

1. Existing Discord MCP Tools (8)

1.1 Message Management Tools

Tool Name	Parameters	Returns	Features
`discord_send_message`	`channel_id`, `content`, `thread_id?`	Result message	Basic message sending
`discord_get_messages`	`channel_id`, `limit?`, `after?`	Message list	Message retrieval
`discord_wait_for_message`	`channel_id`, `timeout_seconds?`	Wait status	Async message waiting (SSE not implemented)

1.2 Thread Management Tools

Tool Name	Parameters	Returns	Features
`discord_create_thread`	`channel_id`, `message_id`, `name?`	Thread info	Thread creation
`discord_list_threads`	`channel_id`	Thread list	Active thread lookup
`discord_archive_thread`	`thread_id`	Result message	Thread archiving (not implemented)

1.3 Concurrency Management Tools

Tool Name	Parameters	Returns	Features
`discord_acquire_thread`	`thread_id`, `agent_name`, `timeout?`	Lock acquisition result	Multi-agent lock
`discord_release_thread`	`thread_id`, `agent_name`	Lock release result	Agent lock release

2. New Cloud Monitor MCP Tools (5)

2.1 Server Management Tools

Tool Name	Parameters	Returns	Features
`cloud_get_server_status`	`server_name`	Server status info	Connection status, OS, metrics
`cloud_list_servers`	`group?`	Server list	Group filtering support
`cloud_list_ssh_config_hosts`	`group?`	SSH host list	SSH config auto-parsing

2.2 Monitoring Tools

Tool Name	Parameters	Returns	Features
`cloud_get_metrics`	`server_name`, `metric_types?`	Metrics data	Optional metric lookup
`cloud_set_alert`	`metric_type`, `level`, `threshold`	Setting result	Dynamic threshold configuration

Architecture Structure

1. FastMCP Structure

graph LR
 subgraph "FastMCP Layer"
 A[@mcp.tool decorator] --> B[Tool Function]
 B --> C[Parameter Validation]
 C --> D[Business Logic]
 D --> E[Result Formatting]
 E --> F[Return Response]
 end

 subgraph "Common Components"
 G[Gateway Request] --> H[HTTP Client]
 I[Config Manager] --> J[Cloud Monitor Config]
 K[Error Handler] --> L[Uniform Error Response]
 end

2. Communication Flow

sequenceDiagram
 participant MCP as MCP Server
 participant GW as Gateway Service
 participant Discord as Discord API
 participant Server as Target Server

 MCP->>GW: HTTP Request
 GW->>Discord: API Call
 Discord-->>GW: Response
 GW-->>MCP: JSON Response

 MCP->>Server: SSH Connection
 Server-->>MCP: Metrics Data
 MCP->>GW: Alert Message
 GW->>Discord: Embed Message

3. Data Flow

Configuration (config.yaml)
 ↓
Server Info parsing
 ↓
SSH Connection
 ↓
Metrics Collection
 ↓
Threshold Check
 ↓
Alert Generation
 ↓
Discord Notification

Advantages

1. Scalability

Modular Structure: Each tool operates independently and is easy to extend
Plugin Architecture: Adding new tools only requires adding decorators
Cloud Provider Abstraction: SSH-based support for various environments

2. Integration

Unified Platform: Discord and Cloud Monitor managed together on a single MCP server
Automatic Linkage: Automatic Discord alerts on server anomalies
Consistent Interface: All tools follow the same parameter pattern

3. Usability

Intuitive Tool Names: Clear function expression like cloud_get_server_status
Optional Parameters: Most parameters are optional for convenience
Detailed Error Messages: Clearly indicates the cause of failures
JSON Response: Structured data return for easy parsing

4. Reliability

Timeout Handling: Timeout set for all requests
Connection Pooling: SSH connection reuse for performance
Exception Handling: Comprehensive try-catch blocks
Status Tracking: Continuous server status monitoring

5. Maintainability

Centralized Configuration: Central management via config.yaml
Environment Variable Support: Sensitive info separated into environment variables
Logging System: Detailed logging for easy debugging
Version Management: Clear module version distinction

Disadvantages and Improvements

Issues

Synchronous Processing: Some tools operate sequentially
Connection Latency: New connection created each SSH connection
Memory Usage: All processing on single event loop

Improvements

# Async processing improvement example
async def concurrent_monitoring(servers):
 tasks = [monitor_server(server) for server in servers]
 return await asyncio.gather(*tasks)

# Connection pooling introduction
class ConnectionPool:
 def __init__(self, max_connections=10):
 self.pool = asyncio.Queue(maxsize=max_connections)

Issues

Undifferentiated Errors: All errors handled the same way
Lack of Recovery Mechanism: No auto-recovery logic on failures
Insufficient Detailed Logging: Insufficient logs for debugging

Improvements

# Differentiated error handling
class CloudMonitorError(Exception):
 pass

class ConnectionError(CloudMonitorError):
 pass

class MetricCollectionError(CloudMonitorError):
 pass

# Auto-recovery mechanism
async def resilient_monitoring(server_info, max_retries=3):
 for attempt in range(max_retries):
 try:
 return await monitor_server(server_info)
 except ConnectionError:
 await asyncio.sleep(2 ** attempt)
 raise CloudMonitorError("Max retries exceeded")

Issues

Lack of Metadata: Tool descriptions too brief
Insufficient Validation: Lack of input value check logic
No Batch Processing: Cannot process multiple servers simultaneously

Improvements

# Detailed metadata
@mcp.tool(
 name="cloud_batch_monitoring",
 description="Retrieve multiple server statuses at once",
 parameters={
 "server_names": {
 "type": "array",
 "items": {"type": "string"},
 "description": "List of server names to monitor"
 }
 }
)
async def cloud_batch_monitoring(server_names: List[str]) -> str:
 # Batch processing logic
 pass

Issues

Credential Exposure: Sensitive info potentially exposed in logs
No Access Control: Anyone can call tools
Insufficient Input Validation: Insufficient defense against malicious input

Improvements

# Access control
def require_role(required_role):
 def decorator(func):
 async def wrapper(*args, **kwargs):
 if not has_role(required_role):
 raise PermissionError("Access denied")
 return await func(*args, **kwargs)
 return wrapper
 return decorator

# Input validation
@mcp.tool()
async def secure_monitoring(server_name: str):
 if not is_valid_server_name(server_name):
 raise ValueError("Invalid server name")
 # ...

Issues

Lack of Documentation: No detailed documentation for tool usage
No Examples: No actual usage examples
Inconsistent Return Values: Some tools return JSON, others return strings

Improvements

# Consistent return value format
@mcp.tool()
async def cloud_get_server_status_v2(server_name: str) -> dict:
 """
 Retrieve server status.

 Args:
 server_name (str): Server name

 Returns:
 dict: {
 "success": bool,
 "data": Optional[dict],
 "error": Optional[str],
 "timestamp": str
 }
 """
 # ...
 return {
 "success": True,
 "data": status,
 "error": None,
 "timestamp": datetime.now().isoformat()
 }

Conclusion

1. Overall Assessment

The MCP tools in the server-monitor project have the following strengths:

✅ Excellent Integration: Perfect combination of Discord integration and server monitoring
✅ Scalable Structure: Modular architecture using FastMCP
✅ Practicality: Provides all functions needed for actual server monitoring
✅ Ease of Use: Intuitive tool names and simple interface

2. Improvement Priority

Improvement plans by priority:

High: Performance improvement (async processing, connection pooling)
Medium: Error handling enhancement and auto-recovery mechanisms
Low: Security enhancement and detailed documentation

3. Future Direction

Microservices Architecture: Separate each tool into independent services
Real-time Monitoring: Real-time data collection via WebSocket/SSE
Auto-scaling: Automatic scaling based on server changes
Machine Learning: ML model integration for anomaly detection

4. Final Assessment

Overall, a well-designed MCP tool system that provides stability and functionality suitable for actual production environments. While there are areas for improvement, the core functionality is highly complete, and it has the potential to develop into an even more powerful monitoring platform through continuous improvements.

Written: 2026-03-03 Author: server-monitor-team

Korean Version: 한국어 버전

Ssh on Yarang's Tech Lair

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

Boosting Server Management Efficiency: Introducing Server Status Checker Skill

The Problem: Repetitive Server Monitoring Tasks

The Solution: Server Status Checker Skill

Key Features

Usage

Output Example

Technical Details

SSH Config Parsing

Asynchronous Parallel Processing

Automatic Group Classification

System Metrics Collection

GitHub Release

Installation

Business Value

Use Cases

1. Daily Server Health Check

2. Incident Response

3. Capacity Planning

4. Performance Monitoring

Conclusion

[Cloud Monitor] MCP Tool Structure and Pros/Cons Analysis

[server-monitor] MCP Tool Structure and Pros/Cons Analysis

Overview

Table of Contents

Architecture Overview

FastMCP-based Architecture

MCP Tool Categories

Detailed Tool Analysis

1. Existing Discord MCP Tools (8)

1.1 Message Management Tools

1.2 Thread Management Tools

1.3 Concurrency Management Tools

2. New Cloud Monitor MCP Tools (5)

2.1 Server Management Tools

2.2 Monitoring Tools

Architecture Structure

1. FastMCP Structure

2. Communication Flow

3. Data Flow

Advantages

1. Scalability

2. Integration

3. Usability

4. Reliability

5. Maintainability

Disadvantages and Improvements

1. Performance Related

Issues

Improvements

2. Error Handling Related

Issues

Improvements

3. Functionality Related

Issues

Improvements

4. Security Related

Issues

Improvements

5. Usability Related

Issues

Improvements

Conclusion

1. Overall Assessment

2. Improvement Priority

3. Future Direction

4. Final Assessment