AI agent skill · by @automateyournetwork

Anta Validation

Validate Arista EOS network state against ANTA's pre-built 208-test catalogue, with structured pass/fail verdicts. Use for "is this switch healthy", "did my change break anything", "verify BGP/interfaces/hardware are correct", "run a health check on this device". Read-only. A test for a feature the device does not run reports not_applicable — never a failure — and no health percentage is ever emitted. For non-Arista devices, or an assertion ANTA's catalogue doesn't cover, use `pyats-dynamic-test` to author a custom aetest script instead.

Archived 2026-10-23 · Source updated 2026-10-11 · License: Apache-2.0. Check the original repository for the latest version.

SKILL.md instructions

# ANTA validation — the assertion layer

Every other NetClaw source **reads** state. This one **asserts** on it and returns a verdict you can
act on.

**Server**: `anta-mcp` (NetClaw-authored over ANTA 1.9.0, Apache-2.0, own virtualenv) · 4 tools ·
1,272 tokens · **208 tests** in the catalogue

## Which plane answers — read this before reaching for another server

Three servers touch Arista. They answer different questions, and picking the wrong one gives a
confidently wrong answer.

| Plane | Server | Answers |
|---|---|---|
| **Validation** | **this skill** | *does the state match what it should be* — pass/fail |
| Management | `arista-cvp-mcp` | *what does CloudVision say* — inventory, tags, compliance as CVP sees it |
| Device CLI | `pyats-*`, `multivendor-cli` | *what is the raw state* — show-command output |

**Use this skill to assert, not to fetch.** If the question is "what is the interface MTU", that is
the CLI plane. If the question is "is the MTU what it should be", that is this one.

## The verdicts — five, and they never merge

| Verdict | Means | Never counts as |
|---|---|---|
| `pass` | tested, expectation held | — |
| `fail` | tested, expectation did not hold | — |
| **`not_applicable`** | **the feature is not configured — nothing was tested** | `fail` |
| `skipped` | ANTA declined to run it | `pass` |
| `error` | device unreachable or the run broke | `fail` |

### `not_applicable` is the one that matters

ANTA natively reports a test for an unconfigured feature as a **failure**. Measured on a lab switch:

```
VerifyBGPPeerCount → failure
  "'show bgp summary vrf all' failed on veos1: BGP inactive"
```

That device has **no BGP at all**. Reporting it as a failure claims a BGP fault where there is no
BGP. The server reclassifies it to `not_applicable` and keeps the original message.

**When you report results**: say "BGP: not applicable — this device does not run BGP", never "BGP
test failed".

### There is no health percentage, and you should not compute one

`passed / total` is meaningless when `not_applicable` and `skipped` sit in the denominator. Forty
tests of which thirty are not applicable is not "25% healthy" — it is ten real answers and thirty
non-answers. The server **refuses** to emit a percentage. Report the five counts.

## Workflow

**1. Find the tests** (contacts no device):

```
anta_list_tests: category="routing.bgp"        # or keyword="ntp", or both
```

**2. Learn what a test needs** (contacts no device):

```
anta_describe_test: test="VerifyEOSVersion"    # returns its input schema
```

Do this whenever a test takes inputs. A test run without required inputs is reported as `skipped`
with the requirements listed — it does **not** guess a default and silently test the wrong thing.

**3. Run them**:

```
anta_run_tests:
  host: "172.20.20.4"
  tests: ["VerifyEOSVersion", "VerifyUptime", "VerifyNTP"]
  inputs: {"VerifyEOSVersion": {"versions": ["4.36.1F"]}, "VerifyUptime": {"minimum": 3600}}
```

Or by category: `category: "hardware"`.

## Reading a result honestly

- **An unreachable device returns `error` with zero results.** It is not a broken device — nothing
  was tested. Say "could not reach the device", never "the device failed its tests".
- **An empty selection returns `no_tests_selected`.** No test matched. That is not a healthy device.
- **A `fail` names observed and expected.** Quote both — "NTP expected synchronised, actual
  unsynchronised" is actionable; "NTP test failed" is not.

## Credentials and scope

`ANTA_USERNAME` / `ANTA_PASSWORD` come from the environment and are **never** tool arguments and
never appear in output. `ANTA_VERIFY_TLS` defaults to `true` and verifies both certificate trust and hostname.
For private PKI set `ANTA_CA_BUNDLE` to a trusted PEM bundle.
An explicit `false` lab override is disclosed as `tls_verified=false`; it does not disable SSH host-key checks.
See `docs/INTEGRATION-TLS-MIGRATION.md` for migration.

## Boundaries

- **EOS only.** ANTA is Arista's framework. This is not multivendor validation, and it must not be
  described as such.
- **Read-only.** ANTA tests; it does not configure. There is no remediation path here — if a test
  fails, fixing it goes through the normal change process with its CR gating.
- **On demand.** This is not continuous monitoring. For "what was it doing over time", use
  `zabbix-metrics-history`.