Skip to main content
Glama
AIops-tools

fabric-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

aci_faults_list

List ACI fabric faults by severity, revealing active and cleared records to identify the most critical issues first.

Instructions

[READ] ACI fabric faults, worst severity first.

Rows are fault RECORDS, not incidents: a record with 'delegated: true'
mirrors a fault raised on another object, so one condition can appear
twice — do not count them as separate problems. 'active' comes from
severity only; a cleared fault ('active: false') keeps its original
description, which is not current state. 'bySeverity.serverReported' is
APIC's own totalCount per level. Within one severity, rows are sorted
newest first among the rows APIC returned; when a level is truncated, rows
beyond the page may be newer — raise the limit before claiming "latest".

Args:
    severity: One of critical/major/minor/warning/info/cleared; omit for
        every active level.
    include_cleared: Also read cleared faults when no severity is given.
    limit: Max rows (default 50, max 500). The result carries
        returned/limit/truncated; re-run with a higher limit when
        'truncated' is true rather than treating the list as complete.
    target: Target name from config (must be 'platform: aci').

Returns dict: {severities, faults:[{rank, code, severity, active, lifecycle,
    delegated, dn, scope, pod, node, aboutDn, cause, descr, changeSet,
    lastTransition, ...}], returned, limit, truncated,
    bySeverity:{serverReported}, delegatedRecords, note}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
targetNo
severityNo
include_clearedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so excellently. It discloses that rows are fault records rather than incidents, that delegated records may duplicate conditions, that 'active' is severity-derived only, and that cleared faults retain stale descriptions. It also explains sorting/truncation semantics and APIC's own severity counts.

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 dense but every sentence earns its place, covering essential behavioral nuances that would otherwise be invisible. It is front-loaded with the core purpose and a formatted Args section, making it easy to scan despite its length.

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?

For a complex read tool with no output schema and no annotations, the description is remarkably complete. It documents the return dict shape, pagination fields, severity counts, and the meaning of delegated records, so an agent can invoke it and interpret results correctly without external context.

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?

Schema coverage is 0%, and the description compensates fully. It documents severity values and omission behavior, include_cleared semantics, limit default/max and truncation handling, and target's required 'platform: aci' value. Each parameter gains meaning beyond its bare name and type.

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 clearly identifies the tool as a read operation for ACI fabric faults ordered worst-severity-first, which is specific enough to orient an agent. It does not explicitly distinguish itself from sibling tools, but no sibling appears to target ACI faults, so the scope is sufficiently clear.

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 clear operational guidance: how to choose severity, when to use include_cleared, and how to handle truncated results by re-running with a higher limit. It does not mention alternatives or exclusion criteria, but no sibling tool covers the same ACI fault domain, so this is acceptable.

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