Ask Aruba/HPE docs for a compact cited answer.

Use this for prose/how-to questions when you want a short answer instead of raw retrieval hits. Exact endpoint/schema questions should still use lookup_api first.

Evaluate already-retrieved observations against a declarative compliance policy.

Pure, bounded, read-only evaluation only -- this never calls invoke_tool/invoke_read_tool or any backend itself, and never fetches anything. Fetch device/config/inventory state first (e.g. one or more invoke_read_tool results), then pass the already-retrieved data here as observations alongside a declarative policy. The architecture is inspired by NAPALM's compliance_report (a fixed comparison- operator dispatch table evaluated over structured state) and by Nornir-style aggregate run counts, but is implemented independently in pipeline/compliance.py with this repository's own bounds and conventions -- no eval/exec, no arbitrary expressions, no dynamic imports, and no write/destructive tool is ever reachable from here.

Args: observations: bounded (max 100) list of objects, one per device/ entity already retrieved by the caller (e.g. a single invoke_read_tool result, or one element of a list response). Never fetched by this tool. policy: bounded (max 50) list of rule objects, each with "field" (a dotted/indexed path, e.g. "interfaces[0].status" or "firmware.version" -- Mapping key lookup and Sequence integer indexing only, never eval/attribute access), "operator" (one of "eq", "ne", "lt", "le", "gt", "ge", "contains", "in", "regex_fullmatch", "version_gte", "version_range", "exists", "not_exists"), and "expected" (required for every operator except exists/not_exists). Optional per-rule "id" (defaults to "rule_"), "severity" ("critical"/"error"/"warning"/ "info", default "error", informational only -- it does not change pass/fail logic), and "optional" (bool, default False -- a missing field on an optional rule is reported "skipped" instead of "error"). A structurally invalid policy (unknown operator, malformed field path, an "expected" shape that does not match its operator, an unparsable regex/ version value, or exceeding a bound) is rejected before any observation is evaluated. policy_id: free-text label carried through into the report and artifact only. max_result_entries: bounded per-rule result detail cap (default 200, max 500). Aggregate counts always reflect the true total even when the detail list is capped -- see "results_truncated"/"results_total".

Returns "ok", "compliant" (True only when every rule for every observation passed or was explicitly skipped -- never True while any "fail"/"error" result exists), "counts" (pass/fail/error/skipped totals), "observations" (per-observation compliant flag + counts), "results" (bounded per-rule detail), "results_total"/ "results_truncated", and "artifact" (a compliance_report-shaped payload suitable for pipeline.artifact_contracts.write_artifact -- never written to disk by this tool). A structurally invalid policy/ observations input fails closed with "ok": False and a bounded "error" message before any rule evaluation begins.

Find a client by name / MAC / IP.

Find a device by serial number.

Find tools by query. Combines semantic search + tool-name keyword match.

Call this first when you need an action. The returned name is what you pass to invoke_read_tool for read-only tools or invoke_tool for writes. Results are deduplicated; semantic matches are annotated match='semantic', name-overlap matches match='keyword', and safety flags mirror backend ToolAnnotations. Results are compact by default; set include_schema=True only when you need the full JSON schema for a selected tool. Optional platform, server, normalized capability, curated/generated origin, and exact OpenAPI operation-ID filters apply to both keyword and semantic matches.

Args: query: What you want to do. e.g. "create a VLAN", "disconnect a client". top_k: 1-10 results (default 5). include_schema: Include full JSON schemas in results. Defaults to False to keep MCP responses compact. platform: Filter by normalized platform, such as central, glp, mist, clearpass, or apstra. server: Filter by exact backend server name, such as aruba-monitoring. capability: Filter by read, diagnostic, write, or destructive. origin: Filter by curated or generated implementation. operation_id: Filter by an exact generated OpenAPI operationId.

Return the global (org-wide) scope-id.

Call a read-only Aruba tool by name (from find_tool).

This refuses tools that are not annotated read-only. Use invoke_tool only for write/destructive tools after explicit user intent.

Args: cursor: Opaque next_cursor value from a previous truncated response, to resume it from where it left off. Only ever returned by this tool for capability "read" tools -- it is process-local (invalidated by a server restart), integrity protected, time-limited, and bound to this exact tool name and these exact arguments. A malformed/tampered/expired/mismatched cursor returns an error and never reaches the backend.

Dispatch a bounded, ordered batch of read-only tool calls in one round trip.

Nornir-inspired bounded fan-out: each entry in calls is dispatched sequentially (no concurrency in this version -- deterministic ordering and rate-limit safety over throughput) through the identical read-only gate/response-bounding path invoke_read_tool itself uses. One call's failure never aborts the rest: every call gets its own ordered result entry plus rolled-up aggregate counts, never a raised exception and never a success-shaped failure. A write/destructive/unknown tool named in any entry is rejected for that entry alone and never reaches the backend (same gate as invoke_read_tool).

Args: calls: bounded (max 25) ordered list of call objects, each with required "name" (exact backend tool name from find_tool), optional "arguments" (object, default {}), optional "id" (caller-supplied correlation string, max 100 chars, unique within the batch -- defaults to the call's list index as a string), and optional "cursor" (an opaque next_cursor from a previous truncated single-call or batch-item read of this exact tool+arguments, resumed exactly like invoke_read_tool's own cursor argument). "arguments" is bounded to 20,000 serialized bytes and 8 levels of nesting per call -- an oversized/malformed call entry is rejected with status "invalid_call" before any dispatch is attempted for that entry, and never included in a validation-error message (so a secret placed in "arguments" is never echoed back). Duplicate ids reject the whole batch before any dispatch: correlating results by id is the point of supplying one, and silently returning two entries with the same id would make that impossible.

Rate limiting is charged per backend call, not per batch, so a 25-call batch draws 25 tokens from the same bucket a single invoke_read_tool call draws one from.

Returns "ok" (True only when every call in the batch succeeded -- never True while any failure exists), "results" (ordered list, one entry per call, each with "index", "id", "tool", "server", "status" -- one of "ok", "error", "blocked", "unknown_tool", "invalid_cursor", "invalid_call" -- and either "result" (on "ok") or "error" (bounded to 500 characters, otherwise)), "counts" ("total"/"succeeded"/ "failed"), "failed_ids" and "failed_indexes" (both ordered, one entry per failed call), and "truncated" (True when the response had to be shrunk to fit the configured byte budget -- CENTRALMCP_ROUTER_BATCH_RESPONSE_MAX_BYTES, default 300000). Each item additionally gets its own share of that budget while dispatching, so no single call can consume the whole batch's budget. The returned response is strictly within budget.

Call an Aruba tool by name (from find_tool). Arguments is a kwargs dict.

Example: invoke_tool("create_vlan", {"vlan_id": 200, "vlan_name": "Guest"})

Dispatches through the owning backend's FastMCP tool manager, so arguments get FastMCP validation/coercion and the router's request Context is forwarded — this is what lets the async, ctx-requiring destructive ops tools (reboot_device/port_bounce/poe_bounce/disconnect_client) reach their confirmation elicitation. (FastMCP injects ctx here and strips it from the published schema, so callers only pass name + arguments.)

List devices (paginated).

List Central scopes (sites, groups, global) — ID + name (paginated).

List sites (paginated).

Exact Aruba Central API lookup — endpoints, schemas, fields, enum values.

Use INSTEAD of search_docs for "what enum values does field X accept", "which endpoint configures Y and with what method", or "what fields does schema Z have". Authoritative answers from the parsed OpenAPI specs. Returns [] when the specs hold no confident answer — fall back to search_docs in that case.

Build a bounded, read-only, plan-only recurring reconciliation schedule.

Never creates an OS timer, cron job, or GitHub Actions schedule, and never executes a tool -- this only validates a cadence and resolves a bounded set of currently enabled tools into a schedule specification. Write/destructive tools are always excluded from the executable entry list (reported in "excluded" instead, with a reason), regardless of whether the caller explicitly requested them.

Args: cadence: either a named cadence string ("hourly", "daily", "weekly") or an object such as {"kind": "interval_minutes", "interval_minutes": 30} or {"kind": "cron", "expression": "*/15 * * * *"}. Validated structurally only -- never parsed into an actual next-run time or registered as a real schedule. tools: exact tool names to resolve via the loaded catalog. Omit to fall back to the platforms/servers filters below. platforms: normalized platform filter (e.g. "central", "glp") applied to the loaded catalog when tools is omitted. servers: exact backend server name filter (e.g. "aruba-monitoring") applied to the loaded catalog when tools is omitted. max_entries: safety ceiling on schedule entries (default 50, max 100).

Returns "ok", "cadence" (validated descriptor), "entries" (read/diagnostic tools only), "excluded" (everything else, with a reason), "dry_run" (always True), and "artifact" (a router_reconciliation_plan-shaped payload suitable for pipeline.artifact_contracts.write_artifact -- never written to disk by this tool).

Build a deterministic, read-only dependency/order plan across enabled backend tools.

Never executes any tool. Every resolved tool reference is checked only against the currently loaded, enabled backend catalog (the same index find_tool searches) -- an unresolved or ambiguous reference is reported explicitly, never guessed or silently dropped.

Args: steps: bounded (max 25) list of step specs. Each step is a dict: - "id": optional stable step id (str); defaults to "step_". - "tool": exact tool name to resolve via the loaded catalog (preferred -- deterministic, exact match, never guessed). - "hint": free-text action description used only when "tool" is omitted; resolved via the same bounded keyword search find_tool uses (no semantic/embedding guessing). Marked "ambiguous" when multiple close-scoring candidates exist. - "depends_on": list of step ids (or exact tool names) that must run before this step. include_candidates: include up to 5 scored candidate tools per unresolved/ambiguous step. Defaults to False to keep the plan compact.

Returns "ok", "steps" (resolved metadata per step), "order" (topological order, or None whenever any step/dependency is unresolved or the graph has a cycle), "acyclic", "cycles", "unresolved_step_ids", "unresolved_dependencies", and "artifact" (a router_dependency_plan-shaped payload suitable for pipeline.artifact_contracts.write_artifact -- never written to disk by this tool). This never calls invoke_tool/invoke_read_tool.

Search Aruba/HPE documentation (Central config, APIs, NAC, VSG).

For EXACT API questions (enum values, endpoints, schema fields) prefer lookup_api — it is lossless; this is fuzzy retrieval.