Skip to main content
Glama
Sign In
SapperMCP

SapperMCP

by MasterX1582
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Get Disk Usage

get_disk_usage

Retrieves disk usage for the filesystem containing a given path, so you can check storage capacity and identify space constraints during debugging or hardening.

Instructions

Disk usage for the filesystem containing path.

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": "get_disk_usage"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathNo/

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden, and it discloses almost no behavior: it does not say what usage numbers come back (total, used, free), in what units, or whether it reaches across filesystems. The presence of an output schema covers the shape of the return value, but not the caveats. It does imply a non-destructive read through its name and phrasing, yet that is never stated outright.

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?

It is a single front-loaded clause with no padding, and the resource comes before the parameter detail. Possibly too terse for a tool whose behavior is not spelled out. It is minimal rather than informative.

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?

It is a simple tool with zero required parameters and an output schema, so the description does not need to explain the return values. However, the 'filesystem containing path' resolution logic, the default '/' behavior, and any permission or mount-related edge cases are left entirely unstated. For a single-parameter read tool that is tolerable, but not complete.

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?

The single parameter has 0% schema description coverage, but the phrase 'the filesystem containing `path`' adds real meaning: the path is resolved to its mount point, and usage is reported for that filesystem. The description also shows that this is a path to a file or directory rather than a device name. It omits formats, relative-path handling, and behavior under the '/' default.

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?

The description names a specific resource and scope: disk usage for the filesystem that contains `path`. That is enough to separate it from get_cpu_usage, get_memory_info, and the other get_* probes without opening the schema. It is a fragment with no verb, so it falls just short of the top score.

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?

It states no when-to-use and no exclusions, and never names a sibling tool or a condition under which that sibling should be chosen instead. The intent is only inferred from the tool name and from its one-line purpose statement. An agent has enough context to pick it in obvious cases and nothing more.

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