Linux MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_journal_logsC | Get systemd journal logs. |
| read_log_fileC | Read a specific log file. |
| get_network_interfacesB | Get detailed information about network interfaces including address and traffic statistics. |
| get_network_connectionsB | Get detailed information about active network connections. |
| get_listening_portsB | Get details on listening port, protocols, and services. |
| pcp_guideA | Returns the PCP metrics guide: a catalog of the metric names recorded on a typical Linux system, and how to read the values the other PCP tools return. Read it before investigating performance with PCP, and take metric names from it rather than from memory. |
| pcp_list_metricsA | Browses the PCP metric namespace. Lists the metrics under 'prefix' with their descriptions, collapsing any large sub-namespace to one line giving its name and how many metrics it holds; call again with that name as the prefix to see inside it. Only metrics this system's pmlogger records are listed, so everything listed can be passed to pcp_query_metrics. The pcp_guide tool already names the commonly needed metrics, so reach for this when you need a subsystem the guide does not cover. Use only if get_system_information() indicates PCP is available. |
| pcp_query_metricsA | Retrieves historical metric data from PCP archives as JSON samples. When start_time, end_time, or interval is omitted, reasonable defaults are chosen, targeting one hour or about 20 samples. Call pcp_guide first for the metric catalog and how to read the values; do not guess metric names. Use only if get_system_information() indicates PCP is available. |
| pcp_performance_summaryA | Produces a condensed snapshot of CPU, memory, disk, network, and process information using pcp xsos. Can summarize the live system or a particular time in the past. Use only if get_system_information() indicates PCP is available. |
| list_processesC | List running processes |
| get_process_infoB | Get information about a specific process. |
| list_servicesA | List all systemd services. |
| get_service_statusA | Get detailed status of a specific systemd service. |
| get_service_logsB | Get recent logs for a specific systemd service. |
| list_block_devicesC | List block devices on the system |
| list_directoriesC | List directories under a specified path with various sorting options. |
| list_filesC | List files under a specified path with various sorting options. |
| read_fileB | Read the contents of a text file up to a safe size limit. |
| get_system_informationA | Get basic system information, including operating system, distribution, kernel version, uptime, last boot time, PCP installation and service status, and historical PCP time ranges. |
| get_cpu_informationC | Get CPU information. |
| get_memory_informationB | Get detailed memory including physical and swap. |
| get_disk_usageA | Get detailed disk space information including size, mount points, and utilization. |
| get_hardware_informationB | Get hardware information such as CPU details, PCI devices, USB devices, and hardware information from DMI. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 23 tools
Most tools have clearly distinct targets (network, disk, processes, services, files, PCP metrics). Minor overlap exists: get_hardware_information explicitly includes CPU details while get_cpu_information is separate, and get_service_logs / get_journal_logs / read_log_file all retrieve logs, though descriptions differentiate the sources.
All tools follow a strict snake_case verb_noun pattern (get_*, list_*, read_*), with a consistent pcp_* prefix grouping the PCP subsystem tools. No mixing of conventions or casing.
23 tools is on the heavier side but the domain (comprehensive Linux system diagnostics) legitimately spans many subsystems. Nearly every tool earns its place, though a few informational getters (CPU, memory, hardware, system) could plausibly be consolidated.
Broad read-oriented coverage across CPU, memory, disk, network, processes, services, logs, files, and PCP performance with sensible PCP gating. Gaps are limited to write/action operations (e.g. restart service, kill process, file search), which is acceptable if the server is intentionally read-only.