infrahub-analyzing-data

Use mcp__infrahub__get_nodes with a kind and filters for typed reads, or mcp__infrahub__query_graphql for relationship traversal and aggregation. Discover available kinds and valid filter keys first with mcp__infrahub__get_schema or the infrahub://schema resource.

Query the topology design nodes and the realized DcimDevice objects separately, then diff the two sets by name or ID. Missing devices appear in the design set only, extra devices appear in reality only, and attribute mismatches are flagged per object.

Use MCP analysis for one-off questions, exploration, and informal policies. Use an InfrahubCheck when a stable policy must be enforced automatically on every proposed change, and a Transform when you need recurring scheduled reports exported as artifacts.

No. All writes via node_upsert, node_delete, and mutate_graphql land on an auto-created mcp/session-* branch. Changes reach the default branch only after propose_changes opens a Proposed Change that a human reviews and merges.

Empty edges usually mean a wrong kind name, a missing edges/node wrapper level, or a case-sensitive filter value mismatch. Verify the kind with get_schema, confirm each relationship level has its edges/node envelope, and retry without filters to confirm data exists.

The skill runs in a forked context with no visibility into the parent conversation, so it cannot infer your question. Without arguments it returns an error asking you to re-invoke with the question passed as args.