Data Analyzer

Skill: infrahub-analyzing-data

The Data Analyzer answers operational questions against a live Infrahub instance through the Infrahub MCP server: correlating data across node types, detecting drift, tracing service impact, and auditing data quality. You ask in plain language, and the skill chooses the schema lookups and queries that answer it.

When to use

• Answering ad-hoc operational questions about live infrastructure data
• Cross-referencing two or more node types to find relationships or gaps
• Investigating the blast radius of a change before executing it
• Auditing data quality (missing fields, stale records, naming violations)
• Exploring schema structure and data before writing a generator or check
• Producing one-time or on-demand reports

What it produces

A findings report built from live queries, not a stored artifact:

• A header naming the policy or question, the scope, and a checked/compliant/violations count with a compliance percentage
• Per-violation detail: object name, ID, kind, what was violated, and a suggested fix, so each row carries everything needed to act on it
• A remediation hint matched to the violation type: an mcp__infrahub__node_upsert call, a rename, a generator run, or a suggestion to add an InfrahubCheck for a policy worth enforcing on every future change
• For a run covering several policies, a summary table (checked/pass/fail/status per policy) before the per-violation detail

Example prompts

• "Are all devices following the naming convention <site>-<role>-<number>?"
• "Which devices are in the PAR01 maintenance window starting tonight?"
• "Show me all BGP sessions missing a prefix-list"
• "What services depend on devices in rack PAR01-A01?"

Key rules enforced

• Schema discovery before raw GraphQL: kinds and filters are confirmed via get_schema (or the infrahub://schema resource) before reaching for query_graphql, so a typo in a kind name surfaces as an introspection miss rather than a failed query
• Typed reads for single-kind fetches: get_nodes/search_nodes are preferred over raw GraphQL when the question only needs objects of one kind
• Writes are branch-isolated: node_upsert, node_delete, and mutate_graphql land on an auto-created mcp/session-* branch, never the default branch, until propose_changes opens a Proposed Change for a human to merge
• All objects of a kind by default: compliance queries don't filter unless the check is intentionally scoped, since a filter typo can silently shrink the audit population
• Explicit join keys for correlation: cross-query correlation matches on the same key (id or human_friendly_id) on both sides, because a mismatched key returns a silent "no violations" rather than an error
• Reports lead with the count: policy, scope, and the checked/compliant/violation totals come before per-violation detail, with a remediation hint attached to each

Common mistakes it catches

Mistake	What the skill does instead
Reaching for raw GraphQL without checking the schema first	Confirms kind and filter names via get_schema/infrahub://schema before querying
Treating the edges/node response as a flat list	Navigates response.<Kind>.edges[].node explicitly, so a dropped wrapper doesn't read as "no data"
Adding filters to a compliance query "just in case"	Queries all objects of a kind by default, and only scopes intentionally
Joining two queries on mismatched keys	Uses the same explicit key on both sides, so a broken join fails loudly instead of reporting false compliance
Writing straight to the default branch	Lands writes on an auto-created session branch; propose_changes stages them for review
Burying the compliance percentage in a violation list	Leads the report with policy and counts, then drills into per-violation detail

Requirements

The Data Analyzer skill requires the Infrahub MCP server to be configured and connected to your AI tool. See the MCP server docs for setup instructions.

tip

Without MCP, the AI can still query Infrahub data by constructing GraphQL API calls directly. The interaction is more verbose and less intuitive, but functional.

Types of analysis

Analysis type	Example question
Compliance	"Are all devices following the naming convention <site>-<role>-<number>?"
Service impact	"Which services are hosted on devices in Rack A-03?"
Maintenance windows	"Which devices are in a maintenance window, and what BGP sessions depend on them?"
Drift detection	"Which realized devices differ from their topology design object?"
Capacity	"Which racks are over 80% utilized?"
Inventory gaps	"Which devices have no platform or OS version recorded?"
Change impact	"What BGP sessions, services, and IP allocations depend on this prefix?"

How it works

The skill reads the schema with get_schema, fetches objects with get_nodes or search_nodes, and falls back to query_graphql for questions that span several kinds. There is no single-object tool: fetching one object means filtering get_nodes by ids or hfid. For multi-step analysis, queries run sequentially or in combination, and the results are joined in the AI's context rather than in the database. The report gives counts, the affected objects, and the suggested next step for each violation.

Not sure this is the right skill?

See Which skill do I use? for how the Data Analyzer differs from the Check Manager and the Transform Manager.