safe-ssh-mcp

Overview Schema Source Related Servers Discussions Admin

get_pressure

Retrieve Linux pressure stall information for CPU, I/O, and memory in one call to identify which host resource is causing task wait times.

Instructions

Returns Linux pressure stall information (PSI) for CPU, I/O and memory in one call. USE THIS TOOL to tell which resource the host is short of: unlike load average, it shows how much time tasks actually spent waiting for each resource. 'some' = share of time at least one task was stalled, 'full' = all non-idle tasks were stalled at once; avg10/avg60/avg300 are percentages over the last 10, 60 and 300 seconds, total is the cumulative stall time in microseconds. Prints 'PSI not supported' for a resource if the kernel is older than 4.20 or PSI is disabled.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "host": "<host>",
      "user": "<user>"
    },
    "name": "get_pressure"
  }
}

Input Schema

Name	Required	Description	Default
`host`	Yes
`port`	No
`user`	Yes
`timeout`	No
`key_path`	No
`password`	No
`accept_new_hostkey`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Nov 13, 2026

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it explains the meaning of 'some' versus 'full', the avg10/avg60/avg300 percentage windows, that total is cumulative microseconds, and the exact failure text returned when PSI is unavailable (kernel < 4.20 or disabled). It does not discuss SSH authentication needs or timeouts, which is the remaining 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?

Front-loaded with the one-line purpose, then usage guidance, then output-field semantics, then the failure mode. Each sentence contributes distinct information with no filler.

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?

Output schema exists, so return values need not be spelled out, yet the description still explains the fields, which improves interpretability, and it covers the degraded case of unsupported PSI. The only omission is any explanation of the SSH connection parameters for a tool that clearly executes remotely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Seven parameters with 0% schema description coverage, and the description says nothing about any of them, including host, user, port, key_path, password, timeout or accept_new_hostkey. The only mitigating factor is that the parameter names and defaults are largely self-explanatory, but the description adds no semantic value for inputs.

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?

States a specific verb and resource ('Returns Linux pressure stall information (PSI)') and scopes it to CPU, I/O and memory 'in one call', which implicitly separates it from the memory-only sibling get_memory_pressure. An agent can identify the resource and scope without opening the schema.

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?

'USE THIS TOOL to tell which resource the host is short of' gives an explicit trigger condition, and the contrast with load average explains why this is preferable. It stops short of naming the sibling tools or stating when not to use it, so it is strong but not exhaustive.

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

Deploy Server