Fleet Inventory Skill

This skill queries Red Hat Lightspeed to retrieve and display information about managed systems, registered hosts, and fleet inventory.

Prerequisites

Required MCP Servers: lightspeed-mcp (setup guide)

Required MCP Tools:

• get_host_details (from lightspeed-mcp) - Retrieve system inventory

• get_cve_systems (from lightspeed-mcp) - Find CVE-affected systems

Required Environment Variables:

• LIGHTSPEED_CLIENT_ID

• Red Hat Lightspeed service account client ID

• LIGHTSPEED_CLIENT_SECRET

• Red Hat Lightspeed service account secret

Prerequisite Validation

CRITICAL: Before executing any operations, execute the /mcp-lightspeed-validator skill to verify MCP server availability.

See Step 0 in the Workflow section below for implementation details.

Validation freshness: Can skip if already validated in this session. See Validation Freshness Policy.

When to Use This Skill

Use this skill directly when you need:

• List all systems registered in Red Hat Lightspeed

• Show systems affected by specific CVEs

• Display system details (OS version, tags, last check-in)

• Filter systems by environment, RHEL version, or tags

• Count systems matching criteria

• Verify system registration status

Use the /remediation skill when you need:

• Remediate vulnerabilities on systems

• Generate or execute playbooks

• Perform infrastructure changes

• End-to-end CVE remediation workflows

How they work together: Use this skill for discovery ("What systems are affected?"), then transition to the /remediation skill for action ("Remediate those systems").

Workflow

Step 0: Validate Lightspeed MCP Prerequisites

Action: Execute the /mcp-lightspeed-validator skill

Note: Can skip if validation was performed earlier in this session and succeeded. See Validation Freshness Policy.

How to invoke: Execute the /mcp-lightspeed-validator skill

Handle validation result:

• If validation PASSED: Continue to Step 1

• If validation PARTIAL (connectivity test unavailable):

• Warn user: "Configuration appears correct but connectivity could not be tested"

• Ask: "Do you want to proceed? (yes/no)"

• If yes: Continue to Step 1

• If no: Stop execution

• If validation FAILED:

• The validator provides error details and setup instructions

• Wait for user decision (setup/skip/abort)

• If user chooses "skip": Attempt Step 1 anyway (may fail)

• If user chooses "setup" or "abort": Stop execution

Example:

Before retrieving fleet inventory, I'll validate the Lightspeed MCP server configuration.

[Invoke mcp-lightspeed-validator skill]

✓ Lightspeed MCP validation successful. Proceeding with fleet inventory query...

Step 1: Retrieve System Inventory

Document Consultation (REQUIRED - Execute FIRST):

• Action: Read insights-api.md using the Read tool to understand the get_host_details response format and pagination handling

• Output to user: "I consulted insights-api.md to understand the get_host_details response format and pagination handling."

MCP Tool: get_host_details (from lightspeed-mcp)

Purpose: Query Lightspeed for comprehensive system information

Parameters: See references/01-parameter-reference.md for get_host_details/get_cve_systems parameters and response fields.

Verification Checklist:

• ✓ Systems list returned with metadata

• ✓ Total count matches expectation

• ✓ System details include RHEL version, tags, status

• ✓ No authentication errors (401/403)

Key Fields to Extract:

• id : Unique system identifier (use for remediation workflows)

• display_name / fqdn : Human-readable hostname

• rhel_version : OS version (critical for remediation compatibility)

• tags : Environment labels (production, staging, dev)

• stale : Whether system recently checked in (< 7 days)

• last_seen : Last Lightspeed client run timestamp

Step 2: Filter and Organize Systems

Document Consultation (REQUIRED - Execute FIRST):

• Action: Read fleet-management.md using the Read tool to understand fleet inventory reporting structure and best practices

• Output to user: "I consulted fleet-management.md to structure this inventory report."

Apply user-requested filters and grouping. See references/01-parameter-reference.md for filtering and sorting patterns.

Step 3: Query CVE-Affected Systems

MCP Tool: get_cve_systems (from lightspeed-mcp)

Purpose: Find systems affected by specific CVEs

Parameters: cve_id (CVE-YYYY-NNNNN, uppercase). See references/01-parameter-reference.md.

Verification Checklist:

• ✓ CVE ID matches request exactly

• ✓ System list includes remediation status for each

• ✓ Counts are accurate (affected, remediated, still vulnerable)

• ✓ remediation_available flag is present

Status Interpretation:

Status: "Vulnerable" → CVE affects this system, patch not applied → Action: Suggest remediation via /remediation skill

Status: "Patched" → CVE previously affected, now remediated → Action: No action needed, informational only

Status: "Not Affected" → System not vulnerable to this CVE → Action: Exclude from affected count

Step 4: Generate Fleet Summary

Create organized output. Read references/03-output-templates.md for report format (Overview, RHEL/Environment breakdown, System Details, Stale Systems).

Step 5: Offer Remediation Transition

When appropriate, suggest transitioning to the /remediation skill:

Next Steps

For CVE Remediation: If you need to remediate vulnerabilities on any of these systems, I can help using the /remediation skill:

Examples:

• "Remediate CVE-2024-1234 on web-server-01"
• "Create playbook for all RHEL 8 production systems affected by CVE-2024-5678"
• "Batch remediate critical CVEs on staging environment"

For System Investigation:

• "Show CVEs affecting web-server-01" (use cve-impact skill)
• "Analyze risk for production systems" (use cve-impact skill)
• "List critical vulnerabilities across the fleet" (use cve-impact skill)

Dependencies

Required MCP Servers

• lightspeed-mcp
• Red Hat Lightspeed platform access for system inventory and CVE data

Required MCP Tools

get_host_details (from lightspeed-mcp) - Retrieve all registered systems with metadata

• Parameters: Optional filters (system_id, hostname_pattern, tags, operating_system)

• Returns: List of systems with id, display_name, fqdn, rhel_version, tags, stale status

get_cve_systems (from lightspeed-mcp) - Find systems affected by specific CVEs

• Parameters: cve_id (string, format: CVE-YYYY-NNNNN)

• Returns: List of affected systems with vulnerability and remediation status

Related Skills

mcp-lightspeed-validator

• PREREQUISITE - Validates Lightspeed MCP server configuration and connectivity

• Use before: ALL fleet-inventory operations (Step 0 in workflow)

• Purpose: Ensures MCP server is available before attempting tool calls

• Prevents errors from missing configuration or credentials

cve-impact

• Analyze CVE severity and risk after identifying affected systems

• Use after: "What systems are affected by CVE-X?" → "What's the risk of CVE-X?"

cve-validation

• Validate CVE IDs before querying affected systems

• Use before: If CVE ID format is unclear, validate first

system-context

• Get detailed system configuration for specific hosts

• Use after: Fleet discovery identifies systems needing deeper investigation

/remediation (skill) - Transition to remediation workflows after discovery

• Use after: "Show affected systems" → "Remediate those systems"

Reference Documentation

• insights-api.md - Red Hat Lightspeed API patterns and response formats

• fleet-management.md - System inventory best practices and filtering strategies

Skill Orchestration Pattern

Information-First Workflow:

User Query: "Show the managed fleet" ↓ fleet-inventory skill (discovery) ↓ Systems identified: 42 total, 15 affected by CVE-2024-1234 ↓ User: "What's the risk of CVE-2024-1234?" ↓ cve-impact skill (analysis) ↓ CVSS 8.1, Critical severity, affects httpd package ↓ User: "Remediate CVE-2024-1234 on all production systems" ↓ /remediation skill (action) ↓ Playbook generated and executed

Key Principle: Always start with discovery before taking remediation actions. This ensures informed decisions based on actual fleet state.

Output, Examples, Error Handling

Read references/03-output-templates.md for report format. Read references/04-examples.md for fleet, CVE-affected, and environment-filter examples. Read references/05-error-handling.md for no-results, API errors, and stale system handling.

Best Practices

Start broad then filter; group by environment/RHEL/tier; highlight stale systems; offer /remediation transitions; use tables and percentages; declare document consultations; verify prerequisites first.