Provides tools for searching and retrieving Red Hat Knowledge Centered Support (KCS) solutions and support cases, including getting solution details by ID, searching cases, and obtaining case details.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Red Hat API MCP Server search for RHEL 8 kernel panics"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This project implements a Model Context Protocol (MCP) server that provides tools for interacting with Red Hat APIs, making it easy to integrate with LLM applications.
Related MCP server: RHOAI Observability MCP
The server exposes the following Red Hat API tools:
Search Red Hat KCS Solutions - Search for knowledge base solutions
Get Solution by ID - Retrieve full solution content
Search Red Hat Cases - Find cases matching a query
Get Case Details - Retrieve detailed information about a specific case
Python 3.13 or higher
UV package manager (recommended Python package manager)
Red Hat API offline token (obtained from your Red Hat account)
fastmcp (pip install fastmcp or uv pip install fastmcp)
UV is the recommended package manager for Python projects:
curl -LsSf https://astral.sh/uv/install.sh | sh# Clone the repository
git clone <your-repository-url>
cd redhat-api-mcp
# Install dependencies with UV (recommended)
uv pip install -r requirements.txt
# Or with pip
pip install -r requirements.txtVisit the Red Hat API Token Management page per KCS
Log in to your Red Hat account
Generate an offline token
Copy and save the token securely
Create a .env file in the project root with your Red Hat API token:
# Create .env file
echo "RH_API_OFFLINE_TOKEN=your_offline_token_here" > .envReplace your_offline_token_here with your actual offline token from step 1.
You can run the server using fastmcp:
# Using UV (recommended)
uv run fastmcp run redhat_mcp_server.py
# Or using pip
fastmcp run redhat_mcp_server.pyThis will start the MCP server on port 8000, allowing you to interact with your tools using any MCP client.
To install the server in Claude Desktop, add this configuration to your Claude Desktop config file:
{
"mcpServers": {
"redhat": {
"command": "fastmcp",
"args": [
"run",
"/path/to/your/redhat-api-mcp/redhat_mcp_server.py"
],
"env": {
"RH_API_OFFLINE_TOKEN": "your_actual_offline_token_here"
}
}
}
}Search for Red Hat KCS Solutions and Articles.
search_kcs(query: str, rows: int = 50, start: int = 0) -> List[Dict]Parameters:
query (str): Search terms (supports advanced Solr syntax)
rows (int, optional): Number of results to return (default: 50, max: 100)
start (int, optional): Starting index for pagination (default: 0)
Returns: List of solution objects with id, title, score, and view_uri
Get a Red Hat solution by its ID and extract structured content.
get_kcs(solution_id: str) -> DictParameters:
solution_id (str): The KCS solution ID
Returns: Dictionary with title, environment, issue, resolution, and root_cause
Search for Red Hat support cases.
search_cases(query: str, rows: int = 10, start: int = 0) -> List[Dict]Parameters:
query (str): Search terms
rows (int, optional): Number of results to return (default: 10)
start (int, optional): Starting index for pagination (default: 0)
Returns: List of case objects with case_number, summary, status, product, etc.
Get detailed information about a specific Red Hat support case.
get_case(case_number: str) -> DictParameters:
case_number (str): The Red Hat case number (e.g., "01234567")
Returns: Detailed case information with summary, description, severity, and comments
For detailed information about using advanced Solr query expressions with the Red Hat Hydra API, see expression.md.
The server includes sophisticated prompt templates for case analysis:
Case Summary: Generates C.A.S.E. format summaries
Case Resolution: Provides investigation workflows
Multi-phase Analysis: Advanced case resolution protocols
You can override default API endpoints by adding these to your .env file:
# Optional: Custom API endpoints
RH_API_BASE_URL=https://access.redhat.com
RH_SSO_URL=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/tokenThis project is licensed under the MIT License - see the LICENSE file for details.
Note: This MCP server requires a valid Red Hat account and API access. Ensure you have the appropriate permissions for the Red Hat services you intend to access.
Get case details by case number.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| case_number | Yes | The case number (e.g., "04145487") |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'get case details,' which implies a read operation, but it does not mention authentication needs, side effects, rate limits, or any other behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it is under-specified. While there is no unnecessary wording, the sentence is too minimal to provide meaningful guidance beyond the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description does not need to explain return values. However, there is no usage guidance, no behavioral context, and no clarification of the session_id parameter, which leaves the description incomplete for an agent choosing and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%. The description adds no meaning beyond what the schema already provides for case_number, and it says nothing about session_id, which is otherwise undocumented in both the schema and the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and resource ('case details') with a specific retrieval criterion ('by case number'). It is easy to tell this fetches a single case rather than searching, though it does not explicitly differentiate from sibling tools like search_cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus search_cases or the KCS tools. The description only implies the obvious condition that you would use it when you already have a case number, but it does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific solution by ID and extract structured content
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | No | ||
| solution_id | Yes | The ID of the solution to retrieve |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the burden. It implicitly communicates a read-only operation through 'Get' and notes that it 'extract[s] structured content,' but it does not disclose authentication needs, error behavior, or any side effects. For a simple get operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every word contributes to the core purpose and the retrieval-by-ID distinction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the main parameter is documented. However, the session_id parameter is entirely unexplained in both the schema and the description, and there is no guidance about when this tool is preferable to search_kcs. These gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%. The solution_id parameter is described in the schema and reinforced by the description, but session_id has no schema description and is not explained in the tool description. The description does not compensate for the undocumented parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), names the resource ('solution'), and qualifies it as retrieval by ID plus structured extraction. This clearly distinguishes it from the search siblings and from get_case, which targets a different resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific solution by ID' provides clear context: the tool should be used when an agent already has a solution ID and wants structured content. It does not explicitly state when not to use it or name alternatives, but the intended trigger is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Red Hat cases and return a list of case numbers.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Number of results to return (default: 10) | |
| query | Yes | Search query string | |
| start | No | Starting index for pagination (default: 0) | |
| session_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the output ('list of case numbers') but does not disclose pagination behavior, result ordering, query syntax, authentication needs, or other operational traits beyond what the schema already shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, front-loaded sentence with no filler. Every word contributes to the core purpose, and it is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to explain return values, and the tool is relatively simple. However, with no annotations and minimal usage guidance, the description feels bare-bones; an agent still lacks context on query scope or how this search differs from sibling searches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents 3 of 4 parameters (query, rows, start) with basic descriptions, leaving session_id undocumented. The description adds context about searching Red Hat cases but provides no additional detail on query semantics or parameter behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search') and resource ('Red Hat cases'), and specifies the return type ('list of case numbers'). It is distinguishable from siblings like search_kcs and get_case, though it does not explicitly name the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_kcs or get_case. There are no exclusions or conditionals stated, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Red Hat KCS Solutions and return a list with Solution IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Number of results to return (default: 50) | |
| query | Yes | Search query string | |
| start | No | Starting index for pagination (default: 0) | |
| session_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool searches and returns a list of Solution IDs; it does not mention pagination behavior, session usage, rate limits, or any operational caveats. The minimal disclosure is not misleading but leaves significant behavior undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no wasted words. The core action and result are immediately front-loaded, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description and schema are sufficient for a basic invocation, and the output schema provides return value context. However, it lacks guidance on alternatives and leaves session_id unexplained, so an agent may not fully understand edge cases or when to prefer sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (query, rows, and start are described, session_id is not). The description itself adds no parameter-level meaning beyond what the schema already contains, and it does not compensate for the undocumented session_id parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('Red Hat KCS Solutions'), and a defined output ('a list with Solution IDs'). This clearly distinguishes it from sibling tools like get_kcs or search_cases without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the sibling tools (get_kcs, get_case, search_cases). Usage is only implied by the name and basic wording; there are no exclusions, prerequisites, or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_caseget_kcssearch_casessearch_kcsScored across 4 tools
Each tool targets a distinct action-resource pair: search vs get, and KCS vs cases. There is no overlapping or ambiguous functionality between the four tools.
All tool names follow a consistent verb_noun snake_case pattern, using search_ or get_ prefixes. The naming makes the purpose of each tool immediately clear.
With four tools covering two resource types, the server is tightly scoped and every tool earns its place. This is an appropriate size for a focused Red Hat support API integration.
The server provides both search and detail retrieval for KCS solutions and cases, which covers the core read-only workflow for this domain. There are no obvious gaps that would leave an agent unable to accomplish a typical KCS or case lookup task.
Read and write KukGit repositories, files, issues and pull requests from an AI assistant.
Search your knowledge bases from any AI assistant using hybrid RAG.
Get authoritative answers about Redpanda documentation and search API references.
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
