Linux MCP Server

Get service status

get_service_status

Read-only

Check the status of a specific systemd service on local or remote hosts to diagnose running, failed, or inactive services.

Instructions

Get detailed status of a specific systemd service.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`host`	Yes	System to run on: 'localhost' for the system the MCP server runs on, or a remote host to connect to via SSH
`service_name`	Yes	Name of the systemd service

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.7.0Oct 3, 2026

removedInput schema / properties / host / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / host / default
```
Removed value: -null
```

changedInput schema / properties / host / description

Previous value: -"Remote host to connect to via SSH"New value: +"System to run on: 'localhost' for the system the MCP server runs on, or a remote host to connect to via SSH"

addedInput schema / properties / host / examples

Added value: +[
+  "localhost",
+  "web1.example.com"
+]

addedInput schema / properties / host / type
```
Added value: +"string"
```

changedInput schema / required

Previous value: -[
-  "service_name"
-]New value: +[
+  "service_name",
+  "host"
+]

Changed1 schema field changedv1.6.0Sep 4, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
First observedv0.1.0Mar 11, 2026

TDQS

A3.6/5.0

Behavior3/5

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

readOnlyHint=true is consistent with 'Get detailed status', so no contradiction. Beyond that the description adds nothing behavioral (no output format, no permissions, no remote-SSH caveats), but with annotations covering the safety profile and an output schema covering returns, a baseline 3 is fair.

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?

A single front-loaded sentence with no filler; every word (verb, scope, resource) earns its place.

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?

For a simple read-only lookup with a complete two-parameter schema and an output schema, the description is sufficient. It is slightly thin on how it relates to sibling status/log tools, but nothing essential to correct invocation 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?

Schema description coverage is 100% and both parameters (host, service_name) are fully documented with examples, so the schema carries parameter semantics. The description adds no format or syntax detail, matching the baseline 3 for high-coverage schemas.

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?

States a specific verb ('Get') and resource ('detailed status of a specific systemd service'), so an agent knows it retrieves state for one named service. It does not explicitly differentiate itself from siblings like list_services or get_service_logs, keeping it below a 5.

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 word 'specific' implies single-service lookup versus a list, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. list_services for enumeration, get_service_logs for logs). Usage is only implied.

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