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 dates and support status for systems in your inventory, including upgrade targets when specified.

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.4/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 return schema, parameter behaviors (e.g., related=true for include_related), and response guidance. 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.

Conciseness4/5

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

The description is well-structured: purpose, call indicator, examples, parameter guidance, response guidance, and return schema. Every section adds value. Slightly long but justified by the tool's complexity.

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

Completeness5/5

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

The description covers all essential aspects: purpose, when to use, parameter semantics, response structure, and response guidance. No significant gaps. Sibling differentiation is clear from the title and description.

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 descriptions cover all parameters at 100%, but the description enhances with practical usage guidance: how to scope with major/minor and the meaning of include_related with the related flag. This adds significant value beyond the schema.

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 clearly states the tool returns RHEL lifecycle information for systems in the requester's inventory. It uses specific verbs and resources, and distinguishes from sibling planning__get_rhel_lifecycle by focusing on inventory relevance. Examples further clarify 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 provides explicit use cases with example questions and parameter guidance (e.g., setting major/minor, include_related). It does not explicitly name the alternative tool for general lifecycle questions, but the presence of sibling planning__get_rhel_lifecycle implies the distinction.

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