Skip to main content
Glama
Sign In
SapperMCP

SapperMCP

by MasterX1582
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

List Disks

list_disks

Lists mounted partitions with filesystem type, usage, and I/O counters, helping you inspect disk layout and activity for system debugging or security hardening.

Instructions

Mounted partitions with fstype, usage and IO counters.

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

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose the returned fields (fstype, usage, IO counters), which implies a read-only, non-destructive snapshot. It does not state whether counts are cumulative since boot, whether unmounted devices are excluded, or any permission requirements, leaving real behavioral questions unanswered.

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?

A single short fragment with zero padding and the key output fields front-loaded. It is efficient, though it reads as a caption rather than a sentence, which slightly weakens orientation for an agent.

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?

The tool is simple (no parameters), an output schema exists to explain return values, and the description correctly focuses on what is enumerated. Missing is any hint of read-only safety or when this beats sibling listing tools, but for a zero-arg read tool with a schema, this is close to sufficient.

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 tool takes zero parameters, so there is nothing to disambiguate and the baseline applies. The description spends its words on output content rather than restating absent inputs, which is the right use of space for a no-arg tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (mounted partitions) and lists what is returned (fstype, usage, IO counters), but it omits an explicit verb and never distinguishes this disk-listing tool from sibling list_* tools beyond the resource noun. An agent can guess it enumerates mounted filesystems, but the purpose statement is a noun phrase rather than a clear verb+resource claim.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no reference to any alternative such as list_directory for filesystem contents or list_listening_ports for network state. The only implicit signal is 'mounted partitions', which mildly scopes it away from raw block devices, but nothing tells the agent when to reach for this tool versus a directory listing.

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