trmm-mcp

trmm_agent_processes

Read-onlyIdempotent

Retrieve live process lists from a managed agent, sorted by memory or CPU usage to identify resource-heavy processes. Requires the agent to be online.

Instructions

Live process list from an agent, sorted by memory or CPU. Requires the agent to be online.

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": {
      "agent": "<agent>"
    },
    "name": "trmm_agent_processes"
  }
}

Input Schema

Name	Required	Default
`agent`	Yes
`limit`	No
`sort_by`	No	memory

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.1.0Sep 4, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already mark the operation as read-only, idempotent, and non-destructive. The description adds operational context beyond those hints by stating the data is live and that the target agent must be online, which is useful when invoking the tool.

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 a single front-loaded sentence with no filler: it states what the tool returns, the sorting options, and the online prerequisite. Every clause pulls its weight.

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?

For a simple read-only list tool the description gives the essential: scope to an agent, live nature, sorting, and online requirement. However, there is no output schema and no mention of return fields or behavior when the agent is offline, so the agent must infer some details.

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 0%, so the description must compensate. It clarifies sort_by values ('memory or CPU') and implies the agent scope, but does not document the limit parameter or the exact accepted sort_by string values. Parameter names are mostly self-explanatory.

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 names a specific resource and action: a live process list scoped to an agent, with explicit sorting by memory or CPU. The term 'process' distinguishes it from sibling agent tools like trmm_agent_services and trmm_agent_checks, so an agent can tell them apart.

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 description implies the tool is for inspecting an agent's current processes and states a prerequisite (the agent must be online). It does not explicitly say when to choose this over alternatives such as trmm_agent_services, so usage guidance is present but only implied.

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