ubuntu-mcp-server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: inventory listing, health overview, service listing/status/management, update checking, log reading, and a fallback shell command. The descriptions explicitly note when to prefer specialized tools over the generic runner, eliminating ambiguity.
Naming Consistency4/5
All tools share the consistent 'ubuntu_' prefix and use lowercase with underscores. Most follow a verb_noun pattern (list_servers, manage_service, tail_log), but 'system_overview' and 'service_status' deviate to noun-first style, creating a minor inconsistency in the otherwise predictable naming convention.
Tool Count5/5
The 8 tools are well-scoped for an Ubuntu server management MCP. The count is neither too small to cover common tasks nor too large to add confusion, and each tool earns its place in the set.
Completeness5/5
The surface covers the core server administration lifecycle: listing inventory, health checks, service management, update checks, log inspection, and a generic command runner for everything else. The fallback ensures no dead ends and the specialized tools cover the most frequent operations.
Average 4.5/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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 MIT 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations: pagination metadata (total, has_more, next_offset), the return fields (unit name, active/sub state, description), and the state filter behavior. This provides a clearer picture of the tool's operational characteristics.
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 well-structured with a concise opening sentence, a clear Args list, a Returns line, and an example. While it duplicates schema details, the structure makes it easy to scan and the example is valuable. It is appropriately sized for the tool's complexity.
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 presence of an output schema, the description need not explain return values in depth, but it still provides a useful summary and pagination metadata. It also includes a practical example and references to related tools. The description is complete for a read-only list tool, covering parameters, output, and usage context.
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%, so the schema already documents all parameters and defaults. The description repeats the parameter list but adds marginal value by cross-referencing ubuntu_list_servers for the server parameter and providing a usage example. It does not materially enrich parameter meaning beyond what the schema provides.
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's function: 'List systemd services on an Ubuntu server, optionally filtered by state.' The verb 'List' and resource 'systemd services' are specific, and the optional filtering distinguishes it from sibling tools like ubuntu_service_status, which likely targets a single service.
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?
The description provides a clear example ('state='failed' answers "is anything broken on web-01?"') and references the prerequisite source for the server parameter (ubuntu_list_servers). However, it does not explicitly mention when not to use this tool or alternatives like ubuntu_service_status for individual service details, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds behavioral context by noting it gathers everything in one SSH round trip and clarifying that memory and disk are returned as raw 'free -h' / 'df -h' tables, which helps set expectations about output verbosity.
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 concise and well-organized: a purpose sentence, a usage recommendation, an Args section, and a Returns note. Every sentence contributes information without redundancy or padding, and the most important information is front-loaded.
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?
For a read-only overview tool with only two parameters and an output schema, the description covers all necessary context: what it returns, the exact sections, and the caveat about raw tables. Combined with the schema and annotations, an agent has everything it needs to select and invoke the tool correctly.
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 input schema already provides full descriptions for both parameters (server from inventory, response_format enum with default). The Args section in the description largely duplicates the schema, adding no new meaning beyond what the structured data already provides, so it meets the baseline for high schema coverage.
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 opens with a specific verb and resource ('Get a one-shot health overview of an Ubuntu server') and enumerates the exact metrics collected (hostname, OS release, kernel, uptime, load, memory, disk, reboot required, failed services). This clearly distinguishes it from siblings like ubuntu_list_services or ubuntu_check_updates, which focus on narrower concerns.
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?
It explicitly recommends this as 'the best first call when asked "how is server X doing?"' and explains the benefit (single SSH round trip). While it doesn't list when not to use it or name alternative tools, the stated context is clear enough for an agent to choose it for health checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description discloses the sudo -n requirement, the return format (confirmation plus service state), and error handling specifics (password sudo errors, reload failure). This provides substantial behavioral context that helps the agent anticipate side effects and troubleshoot failures.
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 well-structured: a clear introductory line, an Args list, a Returns note, and an Error handling section. Each sentence adds necessary information without 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?
The description covers prerequisites (passwordless sudo), all supported actions, return behavior, and common failure scenarios. Given the presence of an output schema and complete schema documentation, the description is fully sufficient for the agent to select and use the tool correctly.
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 the parameters are already well-documented. The description repeats the parameter meanings and adds minimal examples (e.g., 'nginx'), but does not introduce new semantic information beyond the schema. Baseline 3 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?
The description opens with 'Start, stop, restart, reload, enable, or disable a systemd service' – a specific verb+resource pairing that clearly states the tool's purpose. It distinguishes itself from sibling read-only tools like ubuntu_service_status and ubuntu_list_services by focusing on state-changing operations.
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?
The description provides clear context on how to invoke the tool (requires passwordless sudo), and includes explicit guidance on 'reload' failing for unsupported services with the recommendation to use 'restart' instead. It does not explicitly name alternative tools for when not to use it, but the context is sufficiently clear to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only and idempotent. The description adds valuable behavioral context beyond that: permission errors suggest use_sudo=true or group membership, and it explicitly states that the tool returns plain text. This goes beyond simple safety signaling and covers real edge cases.
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 well-structured with clear sections: summary, Args, Returns, Error handling, and Examples. Every section earns its place; there is no filler. It front-loads the core purpose and avoids redundancy with the schema.
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?
For a tool with 8 parameters, two source modes, and conditional requirements, this description is highly complete. It covers both modes, defaults, error handling, sudo usage, and return format, and includes worked examples. No critical use-case information is missing.
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 description coverage is 100%, so the baseline is 3. The description adds value by grouping parameters by source mode ('journal only', 'file only'), showing defaults, and providing concrete examples that combine multiple parameters (e.g., source='journal', unit='nginx', since='1 hour ago', grep='error'). This is more helpful than the raw 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 opens with a specific verb and resource: 'Read recent log lines from an Ubuntu server' and clearly distinguishes the two source modes (journal vs file). It is immediately distinct from sibling tools like ubuntu_service_status and ubuntu_run_command.
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?
The description provides clear context for when to use this tool (need recent log lines) and gives detailed examples (e.g., 'errors in nginx logs in the last hour') that map natural language to parameter combinations. However, it does not explicitly mention when NOT to use it or contrast it with alternatives like ubuntu_service_status, so top marks are withheld.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false), the description discloses that refresh_cache runs 'apt-get update' via sudo -n and requires passwordless sudo, and explicitly states the tool does not install packages. This adds context about side effects and prerequisites, with no contradiction to 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?
Description is well-structured with a purpose statement, Args section, Returns, and usage note. Every sentence contributes value, and it is neither too terse nor verbose.
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?
With complete schema descriptions, an output schema, and a clear return-value description, the tool is fully documented. The alternative install path is also mentioned, making the context complete.
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?
Input schema already provides 100% coverage with descriptive parameter docs. The description adds a concise inline summary for each param (e.g., 'server name from the inventory'), but does not add new semantics beyond the schema. Baseline 3 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?
The description clearly states it 'List[s] pending apt package updates on an Ubuntu server, flag[s] security updates, and report[s] whether a reboot is required.' It explicitly distinguishes itself by saying 'Does NOT install anything' and pointing to ubuntu_run_command for installs, differentiating it from sibling 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?
Provides explicit guidance: 'Does NOT install anything' and 'To actually install updates, use ubuntu_run_command with sudo... after confirming with the user.' Also explains conditions like refresh_cache requiring passwordless sudo, so the agent knows when to use this vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, but the description adds valuable context with 'Does not contact the servers, so a listed server is not necessarily reachable right now.' It also discloses the return fields (name, host, port, username, description), going beyond the structured 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?
The description is well-structured: purpose statement, usage guidance, Args, and Returns. Every sentence serves a purpose with no redundant filler. It is front-loaded with the core purpose and efficiently organized.
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?
This is a simple read-only listing tool with a single optional parameter. The description covers the return format, the non-contact behavior, and its role as a discovery tool. Combined with annotations and schema, nothing essential is missing.
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 only parameter, response_format, is fully covered by the schema (enum, default, description). The description repeats the parameter info without adding extra meaning. Since schema coverage is 100%, the baseline is 3; no additional value is provided.
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: 'List all Ubuntu servers configured in the inventory (servers.json), with their connection details.' This specifies a precise verb and resource. It also distinguishes itself from sibling tools by noting it is the discovery mechanism for the 'server' parameter used by all other ubuntu_* 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?
Explicitly instructs: 'Call this first to discover valid values for the server parameter used by every other ubuntu_* tool.' This provides clear when-to-use guidance and explains the tool's role relative to alternatives. It also adds a caveat that servers are not contacted, so a listed server may not be reachable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the annotations: pipes/redirects work, sudo requires passwordless sudo, non-zero exit codes are not tool errors, unknown servers return valid names, and sudo failure output includes the fix. It complements the destructiveHint annotation without contradiction.
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 well-structured with clear sections (purpose, alternatives, args, returns, error handling). Despite its length, every sentence provides useful operational context, and it is front-loaded with the primary purpose.
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 complexity (arbitrary shell execution, destructive potential) and the presence of an output schema, the description is complete. It covers error handling, prerequisites, and alternatives, and doesn't need to detail return structure since an output schema exists.
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%, so the baseline is 3. The description's Args section largely restates what is already in the schema (e.g., 'pipes and redirects work', 'requires passwordless sudo'), adding no new meaning beyond the structured field descriptions.
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 runs an arbitrary shell command on a configured Ubuntu server via SSH and returns stdout, stderr, and exit code. It uses a specific verb ('Run') and resource, and differentiates itself from sibling tools by explicitly listing specialized alternatives.
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?
It provides explicit guidance: 'Prefer the specialized tools when they fit' and lists them, then says to use this tool for everything they don't cover. Also mentions checking ubuntu_list_servers for valid server names, offering 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds substantial context beyond that: it specifies the full systemctl status output components, parsed active_state and enabled state, and error handling behavior (reports missing unit and suggests a fallback tool). This fully discloses what the tool does and returns, exceeding the annotation baseline.
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 well-structured with clear sections: purpose, args, returns, and error handling. Every sentence adds value, and the main purpose is front-loaded. No redundant or vague phrasing; it's appropriately sized for the tool's simplicity.
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?
For a tool with 2 parameters and a simple read-only operation, the description covers all necessary context: what it does, what inputs are expected, what returns look like, and how errors are handled. The output schema existence means return value details are optional, but the description includes them anyway, making it self-contained and complete.
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%, with parameter descriptions already present. The description additionally clarifies the 'server' parameter's source (inventory from ubuntu_list_servers) and gives examples for 'service' (e.g., 'nginx' or 'ssh'). This adds practical guidance beyond the schema, justifying an above-baseline score.
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's purpose: 'Show detailed status of one systemd service' with specific details about the output (state, log lines, PID, memory) and boot-enabled status. It distinguishes from siblings by focusing on a single service's status, contrasting with listing (ubuntu_list_services) or managing (ubuntu_manage_service).
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?
The description provides context for when to use: when you need detailed status of a single service. It also references ubuntu_list_servers to obtain server names and suggests ubuntu_list_services in error handling for finding correct service names. It doesn't explicitly state 'when not to use', but the alternatives are clearly implied, which is sufficient guidance.
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

Copy to your README.md:

[![MCP-Ubuntu MCP server](https://glama.ai/mcp/servers/PainInTheNic/MCP-Ubuntu/badges/card.svg)](https://glama.ai/mcp/servers/PainInTheNic/MCP-Ubuntu)

Score Badge

Copy to your README.md:

[![MCP-Ubuntu MCP server](https://glama.ai/mcp/servers/PainInTheNic/MCP-Ubuntu/badges/score.svg)](https://glama.ai/mcp/servers/PainInTheNic/MCP-Ubuntu)

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/PainInTheNic/MCP-Ubuntu'

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