Skip to main content
Glama
Sign In
PCCheck MCP Server

PCCheck MCP Server

by jjackk0k
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Disk space & health

disk_space
Read-only

Check disk space usage and physical drive health for all drives. Identify full disks, available space, and potential drive failures using SMART status.

Instructions

All drives with size/free space plus physical disk health (SSD vs HDD, SMART status). Use for 'disk full', 'how much space do I have', or suspected failing drive. To find WHAT is taking space, follow up with scan_folder_sizes.

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_space"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare read-only and non-destructive. Description adds details on return values (disk health types) with no contradictions. Good 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences. First sentence states what tool returns; second gives usage cases and follow-up. No wasted words.

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 no output schema and no parameters, description fully covers return values and usage context. Enough for agent to understand what to expect.

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?

No parameters; schema coverage is 100%. Description appropriately doesn't need to add parameter info. Baseline 4 for zero-parameter tools.

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?

Clearly states verb 'get' implied, resource 'disk space and health', and specific attributes (size, free space, SSD vs HDD, SMART status). Distinguishes from sibling tools like scan_folder_sizes.

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?

Explicit use cases: 'disk full', 'how much space do I have', 'suspected failing drive'. Also tells when not to use (to find what's taking space) and suggests follow-up 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