Skip to main content
Glama
Hadar301

openshift-installer-checker

by Hadar301
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

OpenShift/Kubernetes Installer Checker - MCP Server

An MCP (Model Context Protocol) server that analyzes git repositories to extract application installation requirements and validates them against OpenShift/Kubernetes clusters.

Features

šŸ” Repository Analysis

  • Git Repository Support: Fetches README and deployment files from GitHub/GitLab repositories

  • YAML Parsing: Extracts resource requirements from Helm charts, Kubernetes manifests, ConfigMaps, and CRDs

  • Smart Extraction: Identifies CPU, memory, GPU, storage requirements, and node selectors

  • CRD Detection: Extracts Custom Resource Definition requirements from deployment manifests

šŸ–„ļø Cluster Scanning

  • Resource Discovery: Scans connected OpenShift/Kubernetes clusters for available resources

  • Node Analysis: Detects CPU, memory, GPU capacity and allocatable resources

  • Current Usage Tracking: Monitors real-time resource consumption (via metrics-server)

  • GPU Model Detection: Identifies specific GPU models (A100, H100, MI250, etc.) from node labels

  • GPU Memory Detection: Extracts GPU VRAM from node labels (e.g., 24GB for A10G, 80GB for A100)

  • Targeted Scanning: Optimized scanning that only fetches resources needed for validation (30-50% faster)

  • Storage Classes: Lists available storage classes and default configurations

  • Operator Detection: Scans for installed operators (OpenShift OLM)

  • CRD Inventory: Lists all Custom Resource Definitions in the cluster

āœ… Feasibility Checking

  • Resource Validation: Compares requirements against cluster capacity

  • GPU Class Validation: Validates GPU models/classes, not just quantity

    • Datacenter-class requirements (A100, H100, H200, MI250, etc.)

    • Specific model matching (e.g., "A100/L4", "H100 or newer")

    • Rejects consumer GPUs (RTX, GTX, T4) for datacenter requirements

  • GPU Memory Validation: Validates GPU VRAM requirements (critical for LLM workloads)

    • Compares required vs available GPU memory (e.g., 24Gi vs 80GB A100)

    • Clear error messages when GPU memory is insufficient

  • CRD Conflict Detection: Checks for CRD name conflicts, API group mismatches, and version compatibility

  • Available Resource Calculation: Uses current usage to determine actually available resources

  • Confidence Scoring: Provides high/medium/low confidence based on available data

šŸ¤– MCP Integration

  • Claude Code: Works seamlessly with Claude CLI

  • Cursor: Integrates as MCP tool in Cursor IDE

  • Multi-Platform: Supports both GitHub and GitLab repositories

Related MCP server: Sentinel Solutions MCP Server

Installation

  1. Clone this repository:

git clone https://github.com/Hadar301/mcp-openshift-installer-checker.git
cd mcp-openshift-installer-checker

  1. Install dependencies using uv:

uv sync

  1. (Optional) Set up GitHub/GitLab tokens to avoid rate limits:

cp .env.example .env
# Edit .env and add your tokens

  1. (Optional) Log in to your OpenShift/Kubernetes cluster for scanning features:

# For OpenShift
oc login <cluster-url>

# For Kubernetes
kubectl config use-context <context-name>

Prerequisites

Required

  • Python 3.10+

  • uv package manager: pip install uv

Optional (for cluster scanning)

  • oc (OpenShift CLI) or kubectl (Kubernetes CLI)

  • metrics-server installed in cluster (for current usage tracking)

  • Active cluster connection (oc login or kubectl config use-context)

Usage

As an MCP Server (with Claude Code or Cursor)

Configure for Claude Code

First, clone the repository:

git clone https://github.com/Hadar301/mcp-openshift-installer-checker.git
cd mcp-openshift-installer-checker
uv sync

Then edit ~/.claude.json and add the MCP server configuration to the project where you want to use it. For example, to configure it for your home directory (/Users/yourusername):

{
  "projects": {
    "/Users/yourusername": {
      "mcpServers": {
        "openshift-installer-checker": {
          "type": "stdio",
          "command": "uv",
          "args": [
            "--directory",
            "/path/to/mcp-openshift-installer-checker",
            "run",
            "python",
            "main.py"
          ],
          "env": {
            "GITHUB_TOKEN": "<your-github-token>"
          }
        }
      }
    }
  }
}

Note:

  • Replace /Users/yourusername with your actual home directory path

  • Replace /path/to/mcp-openshift-installer-checker with the actual path where you cloned the repository

  • Replace <your-github-token> with your GitHub personal access token

Then use Claude Code:

claude chat

Ask Claude:

Configure for Cursor

First, clone the repository:

git clone https://github.com/Hadar301/mcp-openshift-installer-checker.git
cd mcp-openshift-installer-checker
uv sync

Then edit ~/.cursor/mcp.json:

{
  "mcpServers": {
    "openshift-installer-checker": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/mcp-openshift-installer-checker",
        "run",
        "python",
        "main.py"
      ],
      "cwd": "/path/to/mcp-openshift-installer-checker",
      "env": {
        "GITHUB_TOKEN": "<your-github-token>"
      }
    }
  }
}

Note: Replace /path/to/mcp-openshift-installer-checker with the actual path where you cloned the repository, and <your-github-token> with your GitHub personal access token.

Then ask in Cursor chat: "Analyze installation requirements for https://github.com/your/repo and check if it can be installed"

How It Works

Phase 1: Repository Analysis

  1. URL Parsing: Extracts platform (GitHub/GitLab), owner, and repository name

  2. README Fetching: Downloads README.md via GitHub/GitLab API

  3. Deployment File Discovery: Searches common paths (helm/, deploy/, k8s/, manifests/, etc.)

  4. YAML Parsing: Extracts resource specifications from Kubernetes manifests

  5. CRD Extraction: Identifies Custom Resource Definitions to be installed

  6. Requirement Aggregation: Combines requirements from multiple sources

Phase 2: Cluster Scanning (if cluster available)

  1. CLI Detection: Tries oc first (OpenShift), falls back to kubectl

  2. Targeted Scanning: Only fetches resources needed based on requirements (performance optimization)

  3. Node Scanning: Collects capacity, allocatable resources, GPU models, and GPU memory

  4. Usage Tracking: Fetches current resource consumption (requires metrics-server)

  5. Storage Classes: Lists available storage provisioners (only if storage required)

  6. Software Inventory: Scans for installed operators and CRDs (only if needed)

  7. Available Calculation: Computes free resources (allocatable - used)

Phase 3: Feasibility Checking

  1. Resource Validation: Compares CPU, memory, GPU against cluster capacity

  2. GPU Model Validation: Validates GPU class/model requirements

    • Datacenter-class: A100, H100, H200, L4, L40, MI250, MI300, etc.

    • Consumer GPUs rejected: T4, RTX, GTX, Quadro, Titan

  3. GPU Memory Validation: Validates GPU VRAM requirements

    • Compares required memory (e.g., 24Gi, 80GB) against available GPU memory

    • Critical for LLM deployments (Llama-70B needs 80GB, DeepSeek-V3 needs 600GB+)

  4. Storage Validation: Checks for available storage classes

  5. CRD Conflict Detection: Identifies potential CRD conflicts

  6. Confidence Scoring: Assigns confidence level based on available data

Phase 4: LLM Analysis

Returns structured data for Claude/Cursor to analyze and present to user

Project Structure

mcp-openshift-installer-checker/
ā”œā”€ā”€ main.py                                    # MCP server entry point
ā”œā”€ā”€ .env.example                               # Example environment variables
ā”œā”€ā”€ pyproject.toml                             # Project dependencies (uv)
ā”œā”€ā”€ uv.lock                                    # Dependency lock file
ā”œā”€ā”€ LICENSE                                    # MIT license
ā”œā”€ā”€ README.md                                  # This file
ā”œā”€ā”€ src/
ā”‚   ā”œā”€ā”€ __init__.py
ā”‚   ā”œā”€ā”€ cluster_analyzer/
ā”‚   ā”‚   ā”œā”€ā”€ scanner.py                        # Cluster resource scanner (with targeted scanning)
ā”‚   ā”‚   ā””ā”€ā”€ __init__.py
ā”‚   ā”œā”€ā”€ cluster_checker/
ā”‚   ā”‚   ā”œā”€ā”€ feasibility.py                    # Requirement validation (with GPU memory checks)
ā”‚   ā”‚   ā””ā”€ā”€ __init__.py
ā”‚   ā””ā”€ā”€ requirements_extractor/
ā”‚       ā”œā”€ā”€ extractor.py                      # Main orchestrator
ā”‚       ā”œā”€ā”€ git_handler.py                    # GitHub/GitLab API client
ā”‚       ā”œā”€ā”€ __init__.py
ā”‚       ā”œā”€ā”€ parser/
ā”‚       ā”‚   ā”œā”€ā”€ yaml_parser.py               # YAML resource extraction
ā”‚       ā”‚   ā””ā”€ā”€ __init__.py
ā”‚       ā”œā”€ā”€ models/
ā”‚       ā”‚   ā”œā”€ā”€ requirements.py              # Pydantic data models
ā”‚       ā”‚   ā””ā”€ā”€ __init__.py
ā”‚       ā””ā”€ā”€ utils/
ā”‚           ā”œā”€ā”€ resource_comparisons.py      # CPU/memory comparison utilities
ā”‚           ā””ā”€ā”€ __init__.py
ā””ā”€ā”€ test/
    ā”œā”€ā”€ test_crd_detection.py                # CRD conflict detection tests
    ā”œā”€ā”€ test_gpu_model_validation.py         # GPU model validation tests
    ā”œā”€ā”€ test_command_injection_protection.py # Security tests
    ā”œā”€ā”€ test_extraction.py                   # Requirement extraction tests
    ā”œā”€ā”€ test_usage_tracking.py               # Resource usage tracking tests
    ā”œā”€ā”€ failed_attempt.md                    # Test documentation
    ā””ā”€ā”€ successful_attempt.md                # Test documentation

Example Queries for Claude/Cursor

Once configured as an MCP server, you can ask Claude or Cursor:

  1. Basic Analysis:

  2. Feasibility Checking (requires cluster connection):

  3. GPU Validation:

  4. CRD Conflict Detection:

    • "Will installing this operator conflict with my existing CRDs?"

    • "What CRDs will be created by this application?"

Claude/Cursor will automatically:

  1. Call the analyze_app_requirements tool

  2. Scan the connected cluster (if available)

  3. Validate requirements against cluster capacity

  4. Check for CRD conflicts

  5. Present results in a clear, formatted output

System Requirements for Scanning

Cluster Access

  • Active connection to OpenShift/Kubernetes cluster

  • oc (OpenShift CLI) or kubectl installed and in PATH

  • User logged in with read permissions

Troubleshooting

Cluster Not Available

If cluster scanning fails:

  • Verify CLI tool is installed: oc version or kubectl version

  • Check cluster connection: oc whoami or kubectl cluster-info

  • The tool continues to work for repository analysis even without cluster access

Metrics Server Not Available

If usage tracking fails:

  • Install metrics-server: kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

  • Feasibility checks fall back to allocatable resources (still functional)

GPU Models Not Detected

If GPU models show as empty:

  • Check if nodes have GPU labels: kubectl get nodes -o json | jq '.items[].metadata.labels'

  • GPU device plugins (NVIDIA, AMD) add these labels automatically

  • Manual labeling: kubectl label node <node-name> nvidia.com/gpu.product=NVIDIA-A100-SXM4-40GB

MCP Server Not Connecting

  1. Check the MCP config file path is correct

  2. Verify uv is installed: uv --version

  3. Try running manually: uv run python main.py

  4. Use the MCP Inspector to debug: npx @modelcontextprotocol/inspector uv run python main.py

Contributing

Contributions welcome! This project focuses on building practical MCP servers for DevOps automation.

Development Setup

git clone https://github.com/Hadar301/mcp-openshift-installer-checker.git
cd mcp-openshift-installer-checker
uv sync

Running Tests

# Test CRD detection
PYTHONPATH=. uv run python test/test_crd_detection.py

# Test GPU validation
PYTHONPATH=. uv run python test/test_gpu_model_validation.py

Code Structure

  • src/cluster_analyzer/ - Cluster resource scanning with targeted optimization

  • src/cluster_checker/ - Feasibility validation with GPU memory checks

  • src/requirements_extractor/ - Repository analysis and requirement extraction

  • test/ - Test scripts

  • main.py - MCP server entry point

License

MIT

Available Tools

3 tools
check_feasibilityA
Check if an application CAN BE DEPLOYED on the user's cluster.

āš ļø ONLY USE THIS when user explicitly asks about deployment/installation:
- "can I deploy X on my cluster?"
- "can I install X?"
- "is my cluster compatible with X?"
- "will X work on my cluster?"

ā›” DO NOT USE when user only asks about requirements without mentioning deployment.
For "what are the requirements?" questions, use fetch_repo_content instead.

This tool scans BOTH the repository AND the cluster, then compares them.

Args:
    repo_url: Full GitHub or GitLab repository URL
              Examples:
              - https://github.com/nvidia/nemo
              - https://gitlab.com/project/repo

Returns:
    Dictionary with the following keys:

    - success (bool): Always check this first! If False, check the 'error' field.

    - _summary (dict): **READ THIS FIRST!** Quick overview with:
      - readme_found (bool): True if README exists with substantial content
      - readme_length_chars (int): Character count of all markdown files
      - deployment_files_count (int): Number of K8s/Helm files found
      - deployment_file_paths (list): First 10 deployment file paths
      - has_cluster_info (bool): Whether cluster scan succeeded
      - has_feasibility_check (bool): Whether feasibility analysis is available

    - readme_content (str): Combined content of ALL markdown files from the repository.
      This field will ALWAYS be populated (may say "No README found" if truly empty).
      Length typically 10,000-500,000 chars for real projects.

    - deployment_files (list): List of Kubernetes/Helm YAML files found.
      Each item has: {"path": "...", "content": "...", "parsed_resources": {...}}
      This list will contain 0+ items. Empty list means no K8s manifests found.

    - yaml_extracted_requirements (dict): Structured requirements from YAML parsing.
      Contains hardware/software/CRD requirements extracted automatically.

    - cluster_info (dict|null): Cluster scan results (nodes, GPUs, storage, etc.).
      Will be null if cluster not accessible.

    - feasibility_check (dict|null): Detailed YES/NO analysis comparing repo vs cluster.
      Will be null if cluster not accessible.

    - instructions_for_llm (str): Read this! It contains important context and warnings.

CRITICAL - HOW TO USE THE RESPONSE:
    1. CHECK 'success' field first
    2. **READ '_summary' FIELD** - it shows what data is available at a glance
    3. Use _summary.readme_found to determine if README exists
    4. Use _summary.deployment_files_count to see how many K8s files were found
    5. READ 'readme_content' - it contains all documentation (README, guides, etc.)
    6. CHECK 'deployment_files' - if empty, repo may not have K8s manifests
    7. READ 'instructions_for_llm' - it has important warnings and cluster info
    8. USE 'feasibility_check' for automated comparison results
    9. NEVER say "no README" if _summary.readme_found is True
    10. NEVER say "no deployment files" if _summary.deployment_files_count > 0

OUTPUT FORMATTING RULES:
    1. Summarize all requirements vs cluster resources in a table
    2. Consider every deployment option (don't group into categories)
    3. Provide final YES/NO answer for each installation type
    4. Don't add installation instructions

Example response structure:
    {
        "success": True,
        "readme_content": "# MyApp

[12,000+ chars of documentation]...", "deployment_files": [ {"path": "helm/values.yaml", "content": "...", "parsed_resources": {...}}, {"path": "k8s/deployment.yaml", "content": "...", "parsed_resources": {...}} ], "yaml_extracted_requirements": { "hardware": {"cpu": "4", "memory": "8Gi", "gpu": {"nvidia.com/gpu": "1"}}, "software_inferred": ["NVIDIA GPU Operator"] }, "cluster_info": {"nodes": {...}, "gpu_resources": {...}}, "feasibility_check": {"can_install": False, "reasons": [...]} }

ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYes

TDQS

A4.9/5.0
Behavior5/5

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 discloses that the tool scans both repository and cluster and compares them, details the return format extensively (including success handling, _summary field, instructions_for_llm, and never-say rules), and warns about potential pitfalls. This goes well beyond a basic description and fully informs the agent of expected behavior and how to interpret results.

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 long but well-structured with headers, warnings, emojis, and an example response. Purpose and usage are front-loaded, while output handling and formatting rules are organized in sections. It is verbose out of necessity given the complexity, but every section adds value. Slight deduction for length that could intimidate or slow parsing, though it remains appropriately scoped.

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?

With no annotations and no output schema, the description is the sole source of context. It covers purpose, when to use, parameter format, detailed return structure (including all keys and their meanings), critical usage steps, and output formatting rules. An agent has everything needed to call this tool correctly and interpret its results, making it fully complete.

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?

Schema description coverage is 0%, but the description explains the only parameter (repo_url) with guidance: 'Full GitHub or GitLab repository URL' and provides real examples for both platforms. This adds meaning that the bare schema lacks, fully compensating for the schema gap.

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 opens with a clear statement: 'Check if an application CAN BE DEPLOYED on the user's cluster.' It names the exact resource (application) and action (deployment feasibility). It also differentiates from sibling tools by explicitly stating when NOT to use it and pointing to fetch_repo_content for requirement-only questions, making it easy for an agent to select the right tool.

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?

It provides explicit trigger scenarios ('only use when user explicitly asks about deployment/installation') with concrete example queries, and exclusion rules ('DO NOT USE when user only asks about requirements without mentioning deployment'). It names the alternative tool (fetch_repo_content) for the excluded case, giving clear routing guidance.

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

fetch_repo_contentA
Extract and list application requirements from a repository. NO cluster involvement.

āš ļø ALWAYS USE THIS TOOL when user asks about requirements WITHOUT mentioning cluster:
- "what are the requirements for X?"
- "what does X need to run?"
- "analyze requirements for X"
- "list the requirements for X"
- "what hardware/software does X need?"

KEY: If the question is ONLY about the app's needs (not about "can I install it?"), use this tool.

ā›” DO NOT USE when user asks about deployment/installation/compatibility with their cluster.
For those questions, use check_feasibility instead.

This tool ONLY analyzes the repository. It does NOT:
- Scan any cluster
- Check cluster compatibility
- Determine if installation is possible

Args:
    repo_url: Full GitHub or GitLab repository URL
              Examples:
              - https://github.com/nvidia/nemo
              - https://gitlab.com/project/repo

Returns:
    Dictionary containing:
    - success: Boolean indicating if the operation was successful
    - repo_info: Repository metadata (platform, owner, repo name)
    - readme_content: README text for LLM to analyze
    - deployment_files: List of deployment YAML files with content and parsed resources
    - yaml_extracted_requirements: Summary of requirements found in YAML files
    - instructions_for_llm: Guidance for the LLM on how to analyze the data

Example:
    >>> fetch_repo_content("https://github.com/kubernetes/kubernetes")
    {
        "success": True,
        "repo_info": {...},
        "readme_content": "# Kubernetes...",
        "deployment_files": [...],
        "yaml_extracted_requirements": {...}
    }
ParametersJSON Schema
NameRequiredDescriptionDefault
repo_urlYes

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it handles this well: it clearly states the tool ONLY analyzes the repository and does NOT scan a cluster, check compatibility, or determine installation feasibility. It does not explicitly mention side effects or network/auth behavior, but the operational exclusions are strong enough to prevent common misuse.

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 longer than minimal, but every section serves a purpose: trigger phrases, exclusions, parameter details, and return structure. Some redundancy exists ('NO cluster involvement' appears several ways), but the formatting with warnings, bullet lists, and an example keeps it scannable.

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?

There is no output schema, so the description correctly enumerates the return dictionary keys and provides a full usage example. Combined with the parameter guidance and explicit behavioral exclusions, the agent has everything needed to invoke the tool correctly and interpret its result.

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?

The schema has zero description coverage for repo_url, but the description fully compensates by specifying 'Full GitHub or GitLab repository URL' and providing concrete examples for both platforms. This gives the agent exactly the format and valid input space 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 opens with a specific verb-resource pair ('Extract and list application requirements from a repository') and immediately disambiguates from siblings by stating 'NO cluster involvement' and pointing to check_feasibility for cluster questions. The tool's scope is unmistakable.

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?

It gives explicit trigger phrases for when the tool should always be used, a KEY decision rule ('not about can I install it?'), and an explicit DO NOT USE condition that routes deployment/installation/compatibility questions to check_feasibility. This is exemplary routing guidance.

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

scan_clusterA
Scan the connected OpenShift/Kubernetes cluster for available resources.

This performs a FULL cluster scan, returning all available resources.

USE THIS TOOL WHEN:
- User asks "what resources are available in my cluster?"
- User asks "what does my cluster have?"
- User asks "scan my cluster"
- User wants to know their cluster's capabilities WITHOUT comparing to any app
    For Example, questions like:
        - "How many available GPUs are on the cluster?"
        - "How many available CPU cores are on the cluster?"
    And also question that might regard other cluster resources.

DO NOT USE when user asks about installing/deploying an app (use check_feasibility instead)
DO NOT USE when user asks about app requirements (use fetch_repo_content instead)

Returns comprehensive cluster information including:
- Node resources (CPU, memory, allocatable, available, usage)
- GPU availability, models, and memory (VRAM)
- Storage classes
- Installed operators (OpenShift only)
- Custom Resource Definitions (CRDs)

Fails with clear error if cluster is not accessible.

Returns:
    Dictionary containing:
    - success: Boolean indicating if the operation was successful
    - cluster_info: Node resources, GPU info, storage classes, operators, CRDs
    - error: Error message if cluster not accessible

Example:
    >>> scan_cluster()
    {
        "success": True,
        "cluster_info": {
            "nodes": {...},
            "gpu_resources": {
                "total_gpus": 4,
                "gpu_models": ["NVIDIA-A10G"],
                "gpu_memory_mb": 23028
            },
            "storage_classes": [...],
            "operators": [...],
            "crds": [...]
        }
    }
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses that this is a full-cluster scan, lists the categories of information returned, and states that it fails with a clear error if the cluster is inaccessible. It could go further by noting side effects or resource cost, but for a no-parameter scan tool this is strong disclosure.

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. It is somewhat longer than strictly necessary because the returned information and example partially duplicate the bullets, but the organization makes it easy to parse and the length is justified by the usage guidance.

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?

For a zero-parameter tool with no output schema and no annotations, the description is complete: it states what the tool does, when to use it, what it returns, and how it behaves on failure. The inline return dictionary and example fill the gap left by the absent output schema.

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?

The input schema has zero parameters, so there is nothing for the description to explain about parameters. With a 100% schema coverage baseline and no params, a score of 4 is appropriate; the description adds no unnecessary parameter information.

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 states a specific verb and resource: 'Scan the connected OpenShift/Kubernetes cluster for available resources.' It clearly distinguishes itself from siblings by defining scope as a full cluster scan rather than app feasibility or repo content fetching.

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 an explicit 'USE THIS TOOL WHEN' section with concrete user queries, and a 'DO NOT USE' section naming check_feasibility and fetch_repo_content as alternatives. This leaves no ambiguity about when to invoke this tool versus its siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.0
    • First observedcheck_feasibility
    • First observedfetch_repo_content
    • First observedscan_cluster
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: fetching repo requirements, scanning cluster resources, and comparing the two for feasibility. The descriptions include explicit usage rules and 'DO NOT USE' guidance, so an agent should not confuse them.

Naming Consistency5/5

All tool names follow the same imperative verb_noun pattern: fetch_repo_content, scan_cluster, check_feasibility. Naming style is consistent and predictable.

Tool Count5/5

Three tools is appropriate for a single focused workflow: gather repo requirements, gather cluster state, and assess feasibility. Each tool is necessary and none feels redundant.

Completeness5/5

The server covers the full lifecycle of its purpose: extracting requirements from a repository, scanning the cluster, and combining the two in a feasibility check. No obvious dead ends or missing operations for the stated domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Sentinel Solutions MCP Server

    noodlemctwoodle
    A
    license
    A
    quality
    C
    maintenance
    Analyzes Microsoft Sentinel solutions from GitHub repositories to map data connectors to Log Analytics tables and query security content like detections and playbooks. It provides instant access to the official Content Hub or private repositories through a high-performance pre-built index.
    23
    8 npm
    1
    MIT

  • git-repo-analyzer-mcp

    AntonyWhatsup
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables analysis of local Git repositories via standard git commands, providing insights like line authorship, commit frequency, code churn, and co-changed files.
    -

  • RepoRescue MCP

    wenjieding327
    F
    license
    A
    quality
    A
    maintenance
    Clones and inspects public GitHub repositories to extract evidence like manifests, dependencies, and version hints, and can run allow-listed repos in isolated Docker containers for reproducible verification.
    4
    -