Skip to main content
Glama
NNNNzs

Server Status MCP Server

by NNNNzs
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
JavaScript
Hybrid

服务器状态监控工具

这是一个基于 FastMCP 的服务器状态监控工具，可以获取本地或远程服务器的 CPU、内存和运行时间信息。

功能特点

  • 支持获取本地服务器状态

  • 支持通过 SSH 获取远程服务器状态

  • 自动读取 SSH 配置文件（~/.ssh/config）

  • 支持自定义 SSH 连接参数

  • 可作为独立服务器运行

  • 可作为npm包集成到其他应用中

Related MCP server: Linux MCP Server

安装

通过npm安装

# 全局安装
npm install -g server-status-mcp-server

# 或作为项目依赖安装
npm install server-status-mcp-server

从源码安装

# 克隆仓库
git clone https://github.com/nnnnzs/server-status-mcp-server.git
cd server-status-mcp-server

# 安装依赖
npm install

# 构建项目
npm run build

使用方法

作为独立服务运行

1. 启动服务器

# 如果全局安装了包
server-status-mcp-server

# 或者从源码启动
npm start

2. 运行测试客户端

node client.js

3. 命令行直接调用

使用 stdio 方式与服务器通信：

echo '{"jsonrpc":"2.0","method":"get_server_status","params":{},"id":1}' | node dist/index.js

获取远程服务器状态：

echo '{"jsonrpc":"2.0","method":"getRemoteServerStatus","params":{"host":"172.18.1.103"},"id":1}' | node dist/index.js

作为npm包集成

1. 创建和配置MCP服务

import { createServerStatusMCP } from 'server-status-mcp-server';

// 创建MCP服务实例
const server = createServerStatusMCP({
  // 可选：自定义SSH配置文件路径
  sshConfigPath: '/path/to/ssh/config'
});

// 启动服务
server.start({
  transportType: "stdio" // 或其他传输类型
});

2. 使用MCP客户端调用

import { MCPClient } from 'fastmcp';
import { createServerStatusMCP } from 'server-status-mcp-server';
import { spawn } from 'child_process';

async function main() {
  // 方法1：创建子进程运行服务
  const serverProcess = spawn('node', ['path/to/your/server.js']);
  
  // 创建MCP客户端
  const client = new MCPClient();
  
  // 连接到服务进程
  await client.connect({
    process: serverProcess,
    transportType: "stdio"
  });
  
  // 方法2：在同一进程中使用（不推荐用于生产环境）
  const server = createServerStatusMCP();
  server.start({ transportType: "memory" });
  
  const memoryClient = new MCPClient();
  await memoryClient.connect({ transportType: "memory", server });
  
  // 调用工具
  const localStatus = await client.invoke('getLocalServerStatus', {});
  console.log('本地服务器状态:', JSON.stringify(localStatus, null, 2));
  
  const remoteStatus = await client.invoke('getRemoteServerStatus', {
    host: 'your-ssh-host'
  });
  console.log('远程服务器状态:', JSON.stringify(remoteStatus, null, 2));
  
  // 断开连接
  await client.disconnect();
  serverProcess.kill();
}

main().catch(console.error);

SSH 配置示例

在 ~/.ssh/config 文件中添加以下配置：

Host my-server
    HostName 192.168.1.100
    User username
    Port 22
    IdentityFile ~/.ssh/id_rsa

然后可以使用配置的主机名来获取状态：

echo '{"jsonrpc":"2.0","method":"getRemoteServerStatus","params":{"host":"my-server"},"id":1}' | node dist/index.js

返回数据格式

本地服务器状态

{
  "cpuCount": 8,
  "cpuRel": 0.12,
  "memory": 8589934592,
  "memoryUsage": "45.32",
  "uptime": 123456,
  "type": "local"
}

远程服务器状态

{
  "cpu": "处理器信息...",
  "memory": "内存使用情况...",
  "uptime": "系统运行时间...",
  "type": "remote"
}

API文档

主要导出

// 创建MCP服务实例
createServerStatusMCP(config?: { sshConfigPath?: string }): FastMCP

// 获取本地CPU使用率
getLocalCpuUsage(): number

// 解析SSH配置文件
parseSSHConfig(configContent: string, targetHost: string): Promise<Record<string, string> | null>

// 服务器状态接口
interface RemoteServerStatus {
  cpuRel: string;
  memoryRel: string;
  alarmInfo: string;
  itemStatus: string;
  cpu: string;
  memory: string;
  memoryUsage: string;
  uptime: string;
  type: 'remote' | 'local';
}

错误处理

如果连接失败或执行命令出错，将返回：

{
  "error": "错误信息"
}

发布到NPM

如果你想自己发布这个包到NPM，可以按照以下步骤操作：

  1. 更新package.json中的版本号

  2. 运行npm run build确保构建成功

  3. 运行npm login登录NPM账号

  4. 运行npm publish发布包

  5. 可选：使用npm publish --access public发布公共包

许可证

ISC

Available Tools

2 tools
get_remote_server_statusC

获取远程服务器的CPU、内存和运行状态

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes远程服务器地址或SSH配置中的主机名

TDQS

C2.9/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 of behavioral disclosure. While it states what information is retrieved (CPU, memory, operational status), it doesn't mention how this information is obtained (SSH connection? API call?), what authentication is required, potential rate limits, error conditions, or the format of returned data. For a tool that presumably connects to remote servers, this is a significant gap.

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 - a single sentence that directly states what the tool does. There's no wasted language or unnecessary elaboration. It's front-loaded with the core functionality. Every word earns its place in communicating the tool's purpose.

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 that this is a tool that presumably connects to remote systems (with no annotations and no output schema), the description is incomplete. It doesn't explain how the connection is established, what authentication is needed, what happens if the server is unreachable, or what format the status information will be returned in. For a tool with potential complexity around remote access, more context would be helpful.

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% (the 'host' parameter has a clear description in the schema), so the baseline is 3. The tool description doesn't add any parameter information beyond what's already in the schema. The description mentions '远程服务器' (remote server) which aligns with the 'host' parameter, but provides no additional semantic context about parameter usage or constraints.

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 clearly states the tool's purpose: '获取远程服务器的CPU、内存和运行状态' (Get remote server's CPU, memory, and operational status). It specifies the verb (get/获取) and resources (CPU, memory, operational status). However, it doesn't distinguish this from the sibling tool 'get_server_status' - we don't know if that tool is for local servers or has different functionality.

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. There's a sibling tool 'get_server_status' with a similar name, but the description doesn't explain the difference between them or when one should be preferred over the other. No context about prerequisites or limitations is mentioned.

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

get_server_statusC

获取服务器的CPU、内存和运行状态

ParametersJSON Schema
NameRequiredDescriptionDefault
hostNo远程服务器地址或SSH配置中的主机名

TDQS

C2.9/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 of behavioral disclosure. It describes the tool's function but lacks details on behavioral traits such as whether it requires authentication, has rate limits, returns real-time or cached data, or what happens if the host is unreachable. For a tool that interacts with remote servers, this is a significant gap.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it easy to understand quickly. Every part of the sentence contributes to clarifying what the tool does.

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 the complexity of server status retrieval and the lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, data format, or performance implications. For a tool that likely involves network calls and system metrics, more context is needed to use it effectively.

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?

The schema description coverage is 100%, with the single parameter 'host' documented as '远程服务器地址或SSH配置中的主机名' (remote server address or hostname in SSH configuration). The description doesn't add any additional meaning beyond this, as it doesn't mention parameters at all. With high schema coverage, the baseline score of 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 clearly states the tool's purpose: retrieving CPU, memory, and operational status of a server. It uses specific verbs ('获取' meaning 'get') and resources ('服务器的CPU、内存和运行状态' meaning 'server's CPU, memory, and running status'). However, it doesn't explicitly differentiate from the sibling tool 'get_remote_server_status', which appears to serve a similar purpose.

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. There's no mention of the sibling tool 'get_remote_server_status', nor any context about prerequisites, target environments, or specific use cases. It only states what the tool does, not when it should be selected.

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.

  1. 2 tool updatesv1.0.0
    • First observedget_remote_server_status
    • First observedget_server_status
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.8/5.0
Disambiguation1/5

The two tools are nearly identical in purpose: both retrieve CPU, memory, and operational status. The only difference is 'remote' vs. unspecified server, which is ambiguous and likely to cause misselection, as an agent cannot reliably determine which tool to use without additional context.

Naming Consistency5/5

Both tool names follow a consistent verb_noun pattern (get_remote_server_status and get_server_status). The naming is clear and predictable, with no deviations in style or convention.

Tool Count2/5

With only 2 tools, the server feels thin for a 'Server Status' domain. A typical status monitoring system might include more operations like list_servers, start_server, or stop_server. The minimal toolset limits functionality and suggests incomplete coverage.

Completeness2/5

The tool surface is severely incomplete for server status management. It only provides read operations (get status) with no ability to list servers, modify states, or handle other common tasks like restarting or checking logs. This will likely cause agent failures when more comprehensive actions are needed.

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • mcp-sysmon

    dragogargo
    A
    license
    A
    quality
    C
    maintenance
    MCP server for system monitoring, enabling users to ask about CPU, memory, disk, network, and processes on their system.
    9
    3
    MIT

  • Linux MCP Server

    ahmedadan
    A
    license
    Not graded
    quality
    B
    maintenance
    A read-only MCP server for Linux and macOS system administration, diagnostics, and troubleshooting, supporting remote SSH execution and multi-host management.
    Apache 2.0

  • server-monitor-mcp

    Call123X
    F
    license
    Not graded
    quality
    B
    maintenance
    Server Monitor MCP is a Linux server inspection service with web backend and MCP interface. It allows you to manage SSH hosts and query server metrics via natural language.
    -

  • linux-mcp

    Mohabdo21
    A
    license
    A
    quality
    A
    maintenance
    A Linux system monitoring MCP server that provides real-time information on CPU, memory, disk, network, processes, Docker, security, and more via MCP tools.
    69
    MIT

Appeared in Searches

Latest Blog Posts

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/NNNNzs/server-status-mcp-server'

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