Skip to main content
Glama
RedHatInsights

Red Hat Lightspeed MCP

Official
by RedHatInsights
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Get Application Streams relevant to the requester's inventory (includes lifecycle/support dates).

planning__get_relevant_appstreams
Read-onlyIdempotent

Retrieves application streams relevant to your inventory, including lifecycle dates. Use to identify current streams and find successor streams for upgrades.

Instructions

Get Application Streams relevant to the requester's inventory (includes lifecycle/support dates).

🟢 CALL IMMEDIATELY - No information gathering required.

Use this tool when the user asks about Application Streams in their environment (inventory, hosts, systems...), such as: "Which app streams are we running on RHEL 9?" "What successor app streams could we move to from our current streams?"

Use this tool over get_appstreams_lifecycle when the user asks about their inventory, hosts, systems...

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

If the user wants only streams currently running (what is installed/in use in inventory), set include_related=false. If the user asks whether newer versions exist, wants upgrade recommendations, or wants successor streams to consider, set include_related=true and review entries where related=true as potential candidates.

If the user needs an exhaustive catalog view of all streams available for a given component (e.g., "list all Node.js streams across RHEL 8/9/10"), use get_appstreams_lifecycle.

The backend computes relevance based on actual host data in the user's inventory. This tool does not perform any client-side filtering; all evaluation is performed by the backend.

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 Application Stream records relevant to the user's inventory. Each record contains: - name (str): Technical package or module name. - display_name (str): Human-friendly display name. - application_stream_name (str): Application Stream name. - stream (str): Stream identifier or 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'). - os_major (int | null): RHEL major version. - os_minor (int | null): RHEL minor version. - related (bool): Indicates if this is a related/successor stream (true) or currently in use (false).

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_relatedNoIf true, returns streams currently used plus related/successor streams. If false, returns only streams currently used in inventory.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

The description discloses that the backend computes relevance from actual host data, with no client-side filtering. It aligns with annotations (readOnlyHint, idempotentHint) and adds context about parameter effects. 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 with a clear summary, usage guidelines, parameter instructions, and return format. It is front-loaded with the actionable 'CALL IMMEDIATELY'. However, it is somewhat lengthy, including a detailed return schema which overlaps with the output schema, but each sentence serves a purpose.

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?

Given the complexity (3 optional parameters, output schema exists, multiple sibling tools), the description covers all necessary aspects: when to use, parameter behavior, output structure, and differentiation from alternatives. It leaves no gaps for an AI agent.

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

Parameters5/5

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

Although the input schema already has 100% coverage with descriptions, the tool description significantly enhances parameter semantics by explaining when to set major/minor ('to compute relevance only from systems on that version') and the practical difference between include_related=true/false ('streams currently used' vs 'successor candidates').

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 retrieves Application Streams relevant to the requester's inventory, with lifecycle/support dates. It specifies the resource ('app streams relevant to inventory') and verb ('Get'), and distinguishes it from the sibling tool 'get_appstreams_lifecycle' in the usage guidelines.

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

Usage Guidelines5/5

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

The description provides explicit when-to-use guidance with examples like 'Which app streams are we running on RHEL 9?' and direct contrasts with the sibling tool. It also explains parameter usage (major/minor for version scoping, include_related for successor queries) and when not to use this tool (use get_appstreams_lifecycle for exhaustive catalog).

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