Skip to main content
Glama
Sign In
DevOps Dashboard MCP Server

DevOps Dashboard MCP Server

by turlockmike
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

disk_usage

Check disk space and inode usage by filesystem or mount point to prevent disk-full outages. Excludes virtual filesystems for clarity, with optional path and human-readable sizes.

Instructions

Show disk space usage by filesystem/mount point. Includes both space and inode usage. Excludes virtual filesystems (tmpfs, devtmpfs) for clarity. Essential for preventing disk-full outages.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "disk_usage"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNoSpecific mount point or path to check. Omit to show all filesystems.
humanNoShow sizes in human-readable format (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly states that both space and inode usage are included and that virtual filesystems (tmpfs, devtmpfs) are excluded, which are useful behavioral details beyond a generic 'show disk usage' statement. It does not discuss side effects, but the verb 'Show' implies a read-only operation.

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?

Three sentences with no wasted words. The main purpose is front-loaded, followed by useful behavioral details and a practical use case. Every sentence contributes meaningful information.

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?

For a simple read-only tool with two optional parameters and no output schema, the description covers the essential behavior: what is measured, what is excluded, and why the tool matters. It could mention the output format, but the tool's purpose and output are predictable enough that the description is largely complete.

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 100%, so the schema already fully documents both parameters (path and human). The description does not add additional parameter-level semantics, but the baseline of 3 is appropriate because no compensation is needed when the schema covers everything.

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 uses a clear verb ('Show') and a specific resource ('disk space usage by filesystem/mount point'). It further distinguishes the tool by noting it includes inode usage and excludes virtual filesystems, making it easy to differentiate from sibling tools like memory_info or service_status.

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?

The description provides a clear use case ('Essential for preventing disk-full outages') and the scope of what is shown. It does not explicitly state when not to use it or name an alternative, but the sibling tools are mostly unrelated, so the guidance is sufficient for a simple informational tool.

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