Skip to main content
Glama
NNNNzs

Server Status MCP Server

by NNNNzs
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Hybrid

Server Quality Checklist

50%
Profile completionA complete profile improves this server's visibility in search results.

  • Latest release: v1.0.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.

  • Average 2.9/5 across 2 of 2 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 0 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under ISC License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

  • 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.

  • 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

  • Confirm that the MCP server is working as expected.
  • Confirm that there are no obvious security issues.
  • Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

server-status-mcp-server MCP server

Copy to your README.md:

Score Badge

server-status-mcp-server MCP server

Copy to your README.md:

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