Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

linux_disk_usage_calculator

Read-onlyIdempotent

Parse du and df outputs, compute RAID capacity, plan disk partitions, generate find commands, and format byte counts in IEC or SI units.

Instructions

Linux Disk Usage And RAID Calculator. Six pure-arithmetic disk operations selected by the operation field. parseDu parses pasted du output into entries with byte sizes, depth, and a total; parseDf parses df output into filesystems with size/used/available bytes and use percent; raidCalculator computes usable bytes, redundancy overhead, and fault tolerance for a RAID/RAIDZ level; partitionPlanner allocates a disk into partitions by percent, bytes, or remaining share and reports leftover bytes; findCommand assembles a find -size command string with a plain-English explanation; humanize formats a byte count in IEC (1024) or SI (1000) units. Operates only on the numbers and text you supply, never reading a real filesystem (use file_file_size_calculator for byte-unit conversion plus transfer-time estimates, or math_unit_converter for general unit conversion). Read-only, non-destructive, offline, and rate-limited (30 requests/minute for anonymous callers). Returns a per-operation result object plus warnings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYesSelects the computation. Determines which other fields are read.
textNoRaw du or df command output to parse. Required for parseDu and parseDf; ignored otherwise. Auto-detects human (du -h) vs raw-byte columns.
inputNoStructured input object for raidCalculator, partitionPlanner, and findCommand. May be supplied as this nested object or as top-level fields alongside operation.
bytesNohumanize: byte count to format. Required for the humanize operation.
systemNohumanize: unit system. iec uses 1024 (KiB/MiB/GiB); si uses 1000 (KB/MB/GB).iec

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
successNoTrue when the operation completed.
operationNoEchoes the requested operation.
resultNoOperation-specific output.
Behavior5/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds 'offline' and 'rate-limited (30 requests/minute for anonymous callers)', plus 'Operates only on the numbers and text you supply', which provides additional behavioral context beyond annotations.

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?

The description is relatively long but well-organized: starts with overall purpose, lists operations, then constraints and alternatives. It could be slightly more concise, but every sentence adds value and the structure is logical.

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?

Given the complexity of six operations with nested parameters and an existing output schema, the description covers all necessary context: what each operation does, parameter requirements, constraints, and integration with other tools. It feels complete for an AI agent's needs.

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 description coverage is 100%, so baseline is 3. The description adds context like 'Auto-detects human (du -h) vs raw-byte columns' for the 'text' parameter and 'May be supplied as this nested object or as top-level fields alongside operation' for 'input', which adds value beyond the schema.

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 states it's a 'Linux Disk Usage And RAID Calculator' and enumerates six specific operations with brief explanations. It distinguishes from sibling tools like 'file_file_size_calculator' and 'math_unit_converter' by naming them explicitly.

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?

The description provides clear when-to-use guidance for each operation and includes an explicit alternative: 'use file_file_size_calculator for byte-unit conversion plus transfer-time estimates, or math_unit_converter for general unit conversion'. It also clarifies constraints like 'never reading a real filesystem'.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jambozx/onlinecybertools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server