Skip to main content
Glama

Top processes

top_processes
Read-onlyIdempotent

Ranks processes by CPU or resident memory usage to identify resource-heavy workloads on Linux, with optional redacted command lines.

Instructions

The processes using the most CPU (measured over a short sample, 100 percent is one core) or the most resident memory. The command line, which can carry secrets, is left out unless include_cmdline is true, and is then redacted and cut to 300 characters.

Input Schema

NameRequiredDescriptionDefault
byNowhat to rank by (default cpu)
limitNohow many (default 10)
sample_msNohow long to measure CPU for, in milliseconds (default 500)
include_cmdlineNoadd the redacted command line (default false)

Output Schema

NameRequiredDescriptionDefault
byYes
processesYes
total_processesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world safety, so the bar is lower. The description adds real value beyond that: it discloses that cmdline is withheld by default because it can carry secrets, and that it is redacted and truncated to 300 characters when enabled, plus that 100% CPU equals one core. It does not cover sampling cost or return shape, but the privacy disclosure is substantive.

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?

Two tight sentences with zero waste: the ranking options come first, then the security-relevant caveat. Every clause earns its place and the most decision-critical fact is front-loaded.

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?

With an output schema present, return values need not be explained, and the description covers the critical behavioral facts (sampling units, cmdline privacy). The remaining gap is the lack of guidance against sibling system_overview, but nothing needed to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: include_cmdline's privacy/redaction behavior and the one-core equals 100% semantics behind the CPU sample. This meaningfully enriches two of the four parameters beyond their schema text.

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 resource (processes) and the two ranking modes (CPU vs resident memory), so an agent knows exactly what this returns. It does not explicitly differentiate itself from sibling system_overview, which likely also surfaces process/machine state, so it falls short of 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?

Implies usage by describing the ranking modes and the short sampling window, which hints at real-time load investigation. However, it never says when to prefer this over system_overview or when not to use it, and names no alternatives, leaving selection to inference.

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