Skip to main content
Glama
RedHatInsights

Red Hat Lightspeed MCP

Official
by RedHatInsights
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Returns RHEL lifecycle information for systems in the requester's inventory.

planning__get_relevant_rhel_lifecycle
Read-onlyIdempotent

Retrieves RHEL lifecycle details for your inventory, including support status and end dates. Optionally suggests supported upgrade paths.

Instructions

Returns RHEL lifecycle information for systems in the requester's inventory.

🟢 CALL IMMEDIATELY - No information gathering required.

Use this tool when the user asks about RHEL lifecycle in their own environment, for example:

  • Which RHEL versions are we currently running, and when do they go out of support?

  • What future RHEL 8 minor versions could we upgrade to that are still supported?

When the question is scoped to a specific RHEL major (or major/minor), set major (and optionally minor) so relevance is calculated only from systems on that version.

If the user wants only what is currently running, set include_related=False (default, not needed to be specified).

If the user wants upgrade options or newer streams related to what they run today, set include_related=True and look at items where related=true as potential targets.

Response guidance:

  • Summarize support status and end dates in plain language.

  • If a version is retired or near end-of-support, call out the impact (loss of updates, risk).

  • Provide recommended actions (e.g., plan upgrade, evaluate supported minor versions).

Returns: str: A JSON-encoded response object containing: - meta: Metadata including: - count (int): Number of records returned. - total (int): Total number of matching records. - data: A list of RHEL lifecycle records relevant to the user's inventory. Each record contains: - name (str): RHEL version name. - display_name (str): Human-friendly display name. - os_major (int | null): RHEL major version. - os_minor (int | null): RHEL minor version. - start_date (str | null): Planned start date (ISO format). - end_date (str | null): Planned end-of-life date (ISO format). - support_status (str): Support status (e.g. 'Supported', 'Retired'). - count (int): Number of systems running this RHEL version. - lifecycle_type (str): Type of RHEL version (e.g. 'mainline', 'extended update support (EUS)', 'extended life-cycle support (ELS)', 'update services for SAP solutions (E4S)'). - related (bool): True when include_related=true and the version is a suggested upgrade target.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
majorNoRestricts relevance evaluation to systems running this RHEL major version.
minorNoUsed together with major to further restrict relevance evaluation to a specific minor version. Requires major to be specified.
include_relatedNoWhen true, returns both RHEL versions observed in inventory and additional higher-minor or future versions of the same major that are still supported but not yet deployed (marked as related=true). When false, returns only RHEL versions actually observed in the requester's inventory.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds value by explaining the 'related' flag behavior and the scoping constraints for major/minor. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-organized with sections (call-to-action, examples, parameter guidance, response guidance, return format) but is verbose, especially in re-stating the return schema inline. The front-loaded call-to-action is good, but some redundancy reduces conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's purpose, parameter behavior, output structure (including inline schema), and provides response guidance. For a read-only tool with rich annotations, it is sufficiently complete. The only minor gap is lack of explicit error handling notes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaningful context: it explains that major/minor restrict relevance evaluation, and include_related includes future versions marked as related=true. This goes beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states 'Returns RHEL lifecycle information for systems in the requester's inventory.' This is a specific verb-resource pair that clearly distinguishes from siblings like planning__get_rhel_lifecycle (general) and planning__get_relevant_appstreams (different lifecycle type). The title and name also reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a prominent 'CALL IMMEDIATELY' prompt and provides concrete example questions. It explains when to use include_related and how to scope with major/minor. While it lacks explicit when-not-to-use statements, the guidance is clear and practical.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RedHatInsights/insights-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server