Skip to main content
Glama
Sign In
Red Hat Lightspeed MCP

Red Hat Lightspeed MCP

Official
by RedHatInsights
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ocp-advisor__get_rule_content

Read-only

Fetch static, cluster-independent content for a known OCP Advisor or DVO rule, including its title, description, reason, resolution, risk, impact, tags, and documentation links.

Instructions

Get generic static content for one OCP Advisor or DVO-backed rule.

šŸŸ¢ CALL IMMEDIATELY when rule_id is already known.

Uses Insights Results Smart Proxy v2 GET /rule/{ruleId}/content. The response is generic, cluster-independent static content: title/description, generic description, reason, resolution, more_info/documentation links, total risk, impact, likelihood, publish date, tags, and groups.

This tool intentionally does not return cluster-specific rendered findings or DVO object details. Recommendation/report tools remain responsible for presenting rendered cluster or namespace details. If static content for a DVO or other source rule is unavailable, the upstream 404/503 is surfaced explicitly instead of being treated as an empty successful result.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "rule_id": "<rule_id>"
    },
    "name": "ocp-advisor__get_rule_content"
  }
}

Input Schema

NameRequiredDescriptionDefault
rule_idYesComposite OCP Advisor rule identifier in format rule.module|ERROR_KEY. Use the rule_id/check returned by list_rules or by OCP Advisor/DVO recommendation results.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.30

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, and the description adds real behavior: the upstream endpoint (Smart Proxy v2 GET /rule/{ruleId}/content) and, importantly, that upstream 404/503 for DVO or other source rules is surfaced as an explicit error rather than an empty success. That error-contract detail is genuinely useful beyond the annotation.

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?

Well front-loaded: the action and the immediate-call trigger come first, then endpoint, payload, and error behavior. Mild redundancy exists between the enumerated response fields and the statement that rendered findings are excluded, and the output schema already covers return values.

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?

For a simple one-parameter read, the description covers purpose, data scope, upstream source, and failure semantics, which is enough to call it correctly. Because an output schema exists, the enumerated response fields are partly redundant rather than necessary.

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

Parameters3/5

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

Schema coverage is 100% and the rule_id format (rule.module|ERROR_KEY) and provenance (from list_rules or recommendation results) are already in the schema. The description only echoes 'one OCP Advisor or DVO-backed rule', adding little beyond the structured field.

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?

States a specific verb and resource: 'Get generic static content for one OCP Advisor or DVO-backed rule.' It also carves out what the tool is not ('does not return cluster-specific rendered findings or DVO object details'), which separates it from advisor__get_rule_details and the recommendation/report siblings.

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?

Gives an explicit trigger ('CALL IMMEDIATELY when rule_id is already known') and a clear exclusion boundary (cluster-specific rendering belongs to recommendation/report tools). It does not name a specific sibling tool to use instead, so routing still takes some inference.

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

Deploy Server

Other Tools