arch-mcp-server

List systemd units

svc_list

Read-onlyIdempotent

List systemd units filtered by state, name, or type to inspect service status. Returns unit, active, and sub state, with optional detailed info including description and load state.

Instructions

Systemd units filtered by state, name or type. Returns unit, active and sub; detailed adds description and load state.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "svc_list"
  }
}

Input Schema

Name	Required	Description	Default
`type`	No	Unit type (suffix)
`limit`	No	Units per page
`state`	No	Unit state filter	all
`cursor`	No	Cursor from a previous call
`detail`	No	detailed adds description and load	concise
`pattern`	No	Case-insensitive substring of the unit name

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.6.1Nov 12, 2026

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description usefully adds the return shape (unit, active, sub, plus description and load in detailed mode), but says nothing about pagination behavior — whether a next cursor is returned or how limit interacts with cursor.

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?

Two short sentences, front-loaded with purpose and followed by return content. Minor weakness: 'Returns unit, active and sub' is compressed to the point of ambiguity about whether these are field names.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With six optional parameters, 100% schema coverage, and no output schema, the description covers what is returned and the detail toggle. It is still thin on cursor/limit paging semantics and on routing versus the overlapping svc_failed and svc_status tools.

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%, with three enum-constrained parameters fully documented, so the baseline is 3. The description restates state/name/type filtering and the detail flag but adds no syntax, default, or interaction detail (e.g., pattern is case-insensitive substring, max 64 chars) beyond the schema.

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 opens with a concrete verb+resource — listing systemd units — and immediately names the three filter axes (state, name, type). It doesn't distinguish this tool from siblings like svc_failed or svc_status, which overlap heavily (svc_failed is essentially a pre-filtered state=failed listing).

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?

Usage is only implied: enumerating filters signals a browse/query use case, and the presence of a 'failed' state value hints at overlap with svc_failed. There is no explicit statement of when to pick this over svc_failed (filtered listing) or svc_status (single-unit detail), and no prerequisites or exclusions are given.

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

Deploy Server