Skip to main content
Glama
nucleusv

Linux MCP daemon

by nucleusv
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

memory/usage

Read-onlyIdempotent

Report RAM and swap use from /proc/meminfo, with summary or raw details. Returns text tables or structured JSON for monitoring and diagnostics.

Instructions

Reports memory and swap use from /proc/meminfo. Read-only. used is total - free - (buffers + cached + reclaimable slab); available is the kernel's MemAvailable. Text output is a free-like table with Mem: and Swap: rows (bytes, or e.g. 1.8Gi with human_readable); detailed: true returns the raw /proc/meminfo instead, but only for text output (it is ignored with output_format: json). JSON (also yaml/table/wide) returns an object (total, used, free, shared, buffCache, available, swap_total, swap_used, swap_free) in bytes; human_readable is ignored there. For per-process memory use processes/top or processes/list, for CPU load cpu/load-average.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailedNoReturn the raw /proc/meminfo instead of the summary (text output only; ignored with output_format json)
output_formatNoUse json for structured output (yaml, table and wide return the same JSON); default is text
human_readableNoSizes like free -h (1.8Gi); default is bytes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.4.1
    • changedInput schema / properties / detailed / description
      Previous value: -"Set to true to return raw /proc/meminfo instead of summary"New value: +"Return the raw /proc/meminfo instead of the summary (text output only; ignored with output_format json)"
    • changedInput schema / properties / output_format / description
      Previous value: -"Desired output format (e.g. json, yaml, table, wide). Defaults to text"New value: +"Use json for structured output (yaml, table and wide return the same JSON); default is text"
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint/idempotent/destructive=false, so the safety profile is covered; the description adds genuinely new behavioral facts, notably that `detailed` is silently ignored with output_format json and that `human_readable` is ignored in json/yaml/table/wide output. That silent-ignore behavior is exactly the kind of trait structured fields don't capture.

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?

Purpose and read-only status are front-loaded, and the dense middle section on formats and formulas is all decision-relevant rather than filler. It is heavier than it needs to be for a three-flag read tool, which keeps it short of a 5.

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

Completeness5/5

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

There is no output schema, so the description carries the return-shape burden and does it fully: it describes the text `free`-like table, the JSON object and its keys, byte vs human-readable units, and the raw-meminfo alternative. Nothing needed to call 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 real meaning beyond the schema: the exact formula for `used`, that `available` maps to the kernel's MemAvailable, the enumerated JSON keys, and the cross-parameter interactions between detailed/human_readable and output_format.

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 ('Reports memory and swap use from /proc/meminfo') and explicitly separates itself from siblings by naming processes/top, processes/list and cpu/load-average as the right tools for adjacent concerns. An agent can pick this without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routes the agent explicitly: per-process memory goes to processes/top or processes/list, CPU load goes to cpu/load-average. It also states when to use each mode (detailed for raw /proc/meminfo, json for structured output), leaving nothing to inference.

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

Deploy Server

Other Tools