Skip to main content
Glama
AIops-tools

fabric-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

aci_faults_list

Read-only

List ACI fabric fault records by severity, worst first, to identify active network issues and optionally include cleared faults.

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

NameRequiredDescriptionDefault
limitNo
targetNo
severityNo
include_clearedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.12.0

TDQS

A4.7/5.0
Behavior5/5

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

With only readOnlyHint=true in annotations, the description adds substantial behavioral context: how 'active' is derived, that delegated records mirror faults raised elsewhere, that cleared faults retain stale descriptions, how sorting works within a severity, and that truncation makes 'latest' claims unsafe. These are non-obvious semantics an agent could not infer from the annotation alone.

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?

Front-loads purpose in the first line and the dense prose is mostly load-bearing semantics rather than filler. It is long, and the inline Returns block partially overlaps what an output schema would normally carry, but since no output schema exists that content is justified; only minor tightening is possible.

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 0% param coverage, the description supplies the return shape (faults, bySeverity.serverReported, returned/limit/truncated, delegatedRecords), per-parameter meaning, and interpretation caveats. Nothing needed to call or correctly interpret the tool appears to be 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?

Schema coverage is 0%, so the description carries the full burden and does so well: it enumerates the severity values (critical/major/minor/warning/info/cleared) that the schema's free-form string lacks, explains include_cleared's interaction with severity being omitted, gives limit's default and max, and specifies target must be 'platform: aci'.

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?

States a specific verb and resource ('[READ] ACI fabric faults') plus the ordering ('worst severity first'), which immediately distinguishes it from the other ACI siblings (aci_epg_segment, aci_endpoint_trace) that deal with topology rather than faults. An agent knows exactly what domain this operates on before opening the schema.

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?

Provides strong operational guidance: don't double-count delegated records, re-run with a higher limit when 'truncated' is true, and don't treat cleared descriptions as current state. It stops short of naming sibling alternatives (e.g. vs network_alerts) or explicit when-not-to-use conditions, so it lands at clear-context rather than full routing guidance.

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