Skip to main content
Glama
AIops-tools

fabric-aiops

by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

aci_epg_segment

Read-only

Resolve an ACI EPG's segment by name: follow EPG→BD→VRF relations, expand provided and consumed contracts to filters—use when you know the EPG, not an endpoint.

Instructions

[READ] An ACI EPG's segment: bridge domain, VRF and contracts, by name.

Follows EPG → BD → VRF through the relations APIC resolved (cross-tenant
links into 'common' included) and expands the contracts the EPG provides
and consumes down to filter entries. Use it when you know the EPG but not
an endpoint in it.

A relation that is not 'formed' is reported as a finding with its state; a
read that failed is null with an entry in 'errors' (not empty — say it was
not read). An unenforced VRF means contracts do not restrict traffic in it.
'notChecked' lists what is not evaluated (vzAny, taboo, imported
contracts, preferred-group peers, service graphs).

Args:
    tenant: Tenant name (e.g. 'tenant-A').
    app: Application profile name.
    epg: EPG name.
    target: Target name from config (must be 'platform: aci').

Returns dict: {epg, bd, vrf, contracts:{contracts, returned, limit,
    truncated, filters, filtersTruncated, complete}, segmentResolved,
    notChecked,
    findings:[{rank, severity, signal, cause, action}], errors}.

Input Schema

NameRequiredDescriptionDefault
appYes
epgYes
targetNo
tenantYes

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?

Annotations only declare readOnlyHint=true, but the description adds substantial behavioral context: it follows APIC-resolved relations (including cross-tenant 'common' links), expands contracts to filter entries, explains that non-'formed' relations become findings, that failed reads are null with an 'errors' entry, and that an unenforced VRF does not restrict traffic. This is richer than 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 the [READ] tag and one-line purpose before the traversal, edge-case, and args sections. It is on the long side but each block (traversal semantics, error handling, notChecked scope) earns its place without redundancy.

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?

With no output schema, the description carries the return-shape burden and enumerates the full dict (epg, bd, vrf, contracts with truncation flags, segmentResolved, notChecked, findings, errors). Combined with the scope and error-handling details, an agent has everything needed to call and interpret it.

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?

Schema coverage is 0%, so the description must compensate, and it documents all four args including the critical constraint that target 'must be platform: aci'. Word-level semantics for tenant/app/epg are adequate though minimal beyond the example.

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+resource ('An ACI EPG's segment: bridge domain, VRF and contracts, by name') and describes the traversal it performs. It also implicitly distinguishes itself from sibling aci_endpoint_trace by noting 'Use it when you know the EPG but not an endpoint in it,' so an agent can tell the two apart.

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?

Gives a clear when-to-use condition ('when you know the EPG but not an endpoint in it') that effectively points away from the endpoint-trace sibling. There is no explicit when-not or named alternative, but the routing intent is unambiguous.

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