Skip to main content
Glama
AIops-tools

io.github.AIops-tools/olvm-aiops

Official

storage_capacity_rca

Identifies and ranks storage-domain capacity problems worst first, flagging critical free-space shortfalls, low-space warnings, and inactive domains using engine thresholds and correlated events.

Instructions

[READ] Storage-domain problems ranked worst first, in one call.

Critical when free space is below the engine's critical blocker (the engine then refuses new disks and snapshots); medium below the low-space warning, or when thin disks are committed beyond capacity while space is low (low on its own); high when an attached domain is inactive, unknown or mixed. Warning-or-worse events naming a storage domain (for example "deactivated by system") are attached to it. Unattached domains such as the default image repository are skipped. A domain whose thresholds are unset (the engine reports 0) is reported low with its measured free space: nothing — not the engine, not this tool — will warn before it fills, and how full is too full is not recorded anywhere to read. Over-commit on its own is a planning limit, and its signal carries actual use next to it: do not report an over-committed domain as short of space unless a low-space or blocker finding says so. Report findings in rank order and quote their signal.

Args: events_limit: Recent warning-or-worse events to correlate, 1-1000 (default 200). events_window_hours: Ignore events older than this many hours, 1-720 (default 24). target: Engine target name from config; omit to use the default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNo
events_limitNo
events_window_hoursNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full burden. It is exceptionally transparent: declares it's a read operation, explains severity logic in detail, covers edge cases (unset thresholds, over-commit), states what events are attached, and what is skipped. It also tells the agent how to interpret signals (report in rank order, quote signal). No behavioral surprise is left undisclosed.

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?

The description is detailed but every sentence earns its place. It is structured logically: purpose first, then severity conditions, edge cases, and finally parameter explanations. No fluff or redundancy. The information density is high while remaining readable.

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 tool's complexity (RCA with multiple severity levels, edge cases, and return behavior), the description covers everything an agent needs to know: what it returns (ranked findings), how to interpret signals, what is skipped, and how to handle exceptions. Since there is no output schema, the description adequately explains the return format. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description includes an 'Args' section that fully explains each parameter: events_limit (range 1-1000, default 200), events_window_hours (range 1-720, default 24), and target (engine target name, omit for default). This goes beyond the schema's bare titles and defaults, providing complete semantics.

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 clearly states the tool's purpose: lists storage-domain problems ranked worst first, in one call. It specifies the resource (storage domains) and the action (list problems ranked). It also differentiates from sibling tools by its focus on capacity RCA rather than listing or getting domains. The severity definitions add clarity.

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 gives clear context on when to use it: when free space is below critical or warning thresholds, or when domains are inactive/unknown. It explicitly states what it skips (unattached domains) and how it handles edge cases like unset thresholds and over-commit. However, it does not name alternative tools or explicitly say 'use this instead of X', though the behavior is well-defined.

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