openshift-installer-checker
Related Servers
Alternatives to openshift-installer-checker
No user-submitted related servers found.
Related Servers
- FlicenseAqualityAmaintenanceClones 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-
- FlicenseNot gradedqualityBmaintenanceEnables analysis of local Git repositories via standard git commands, providing insights like line authorship, commit frequency, code churn, and co-changed files.-
- AlicenseAqualityCmaintenanceAnalyzes 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.238 npm1MIT
- FlicenseBqualityDmaintenanceEnables analysis and querying of Git repository content (both public and private) through a unified tool that provides repository summaries, file structures, and full content optimized for LLM consumption.1-
- FlicenseAqualityBmaintenanceEnables agents to autonomously investigate deployment health by inspecting Kubernetes resources, comparing live cluster state against Git, and correlating findings with Dynatrace problems.111-
- FlicenseNot gradedqualityCmaintenanceEnables users to profile public GitHub repositories via a single tool, checking for Spring/Java structure such as pom.xml, src/main/java, Java file counts, and Spring layer annotations to assess suitability for deep local analysis.-
TDQS
Scored across 3 tools
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.
All tool names follow the same imperative verb_noun pattern: fetch_repo_content, scan_cluster, check_feasibility. Naming style is consistent and predictable.
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.
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.