Skip to main content
Glama
RedHatInsights

Red Hat Lightspeed MCP

Official

Returns life cycle dates for all RHEL majors and minors.

planning__get_rhel_lifecycle
Read-onlyIdempotent

Retrieve lifecycle dates and support timelines for Red Hat Enterprise Linux versions, including major, minor, and extended support details.

Instructions

Returns life cycle dates for all RHEL majors and minors.

🟢 CALL IMMEDIATELY - No information gathering required.

Use this tool when the user asks for RHEL versions and lifecycle timelines, including major versions, minor versions, or extended support types (EUS/E4S/ELS).

For "major-only" versions and timelines (for example, "RHEL 8 lifecycle overview"), call this tool and then focus on rows where minor is null. Filtering is performed by you, not the MCP tool.

For a specific minor (for example, "RHEL 9.2 EUS lifecycle"), call this tool and then focus on entries matching the requested major and minor. Interpretation of date windows or version selection is done by you.

When the user mentions dates or "expiring within N days", call this tool and interpret the start_date / end_date values to identify relevant versions. Interpretation of date windows or version selection is done by you.

Returns: dict: A response object containing: - data: A list of RHEL lifecycle records - name (str): System name - start_date (str): Start date of support - end_date (str): End date of standard support - support_status (str): Status of support, e.g. retired, upcoming_release, supported - display_name (str): How the system should be presented to the customer - major (int): Major system version - minor (int): Minor system version - end_date_e4s (str | null): End date of Update Services for SAP Solutions support - end_date_els (str | null): End date of Extended Life-cycle Support - end_date_eus (str | null): End date of Extended Update Support

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

Annotations indicate readOnlyHint, idempotentHint, and openWorldHint, and the description aligns perfectly. It adds value by detailing that no parameters are needed, the tool should be called immediately with no prior gathering, and that post-processing is required. This extends beyond the annotations, which don't convey these specifics.

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 with clear sections and front-loaded purpose. However, it repeats the sentence 'Interpretation of date windows or version selection is done by you' twice, slightly reducing conciseness.

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 tool has an output schema (implicitly described in the 'Returns' block) and no required parameters. The description fully covers the return format and fields, and addresses multiple use cases. No additional information is needed for correct invocation.

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?

With zero parameters and 100% schema coverage, baseline is 4. The description adds meaning by explaining the tool returns all records and that filtering is the agent's responsibility. No further detail needed.

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 the tool returns 'life cycle dates for all RHEL majors and minors', using a specific verb and resource. It clearly differentiates from sibling tools like planning__get_relevant_rhel_lifecycle, which imply filtering, while this tool returns all data.

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?

Provides explicit when-to-use guidance: 'when the user asks for RHEL versions and lifecycle timelines'. Includes specific instructions for major-only, minor-specific, and date-related queries. However, it does not contrast with sibling tools or state when to avoid this tool.

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