Skip to main content
Glama
Hadar301

openshift-installer-checker

by Hadar301

check_feasibility

Determines if an application can be deployed on your OpenShift/Kubernetes cluster by comparing repository requirements against cluster resources, returning a yes/no feasibility check.

Instructions

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": [...]} }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
repo_urlYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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.

Deploy Server

Other Tools