We are implementing a NIDS (NetEdge) MCP toolset. We must choose a strategy for delivering and integrating our toolset into OpenShift clusters, and it'll save time and effort later if we decide now where it's going to be located and how it will get built for production.

Integrate the toolset directly into the openshift-mcp-server repository under pkg/toolsets/netedge. This repository serves as the convergence point for MCP work from multiple teams.

Title: Diagnosis with Agent Evals: Building an MCP Server for Network Troubleshooting

Session Type: 25-minute Session

Track: Security & Operations / MCP Best Practices

Troubleshooting Kubernetes network ingress and DNS issues is notoriously complex, requiring deep domain knowledge and context hopping between multiple layers (HAProxy, CoreDNS, generic K8s resources). While LLMs promise to democratize this knowledge, giving them raw kubectl access is risky and often ineffective. In this session, we present our journey building and rigorously validating a production-grade NetEdge MCP server. We detail how we evolved from a "Phase 0" prototype using gen-mcp to a robust Go implementation, but more importantly, we ask the hard question: Do these specialized MCP tools actually help agents solve these networking problems better?

To solidify these concepts, let’s walk through a real example on OpenShift. We will attempt to install the OpenShift Pipelines Operator as a cluster extension, but we’ll initially misconfigure its RBAC to trigger the preflight checks. Then we’ll fix the permissions.

apiVersion: v1
kind: ServiceAccount
metadata:

podman --version
podman version 5.0.1
tilt version
v0.33.12, built 2024-03-28

start Kind with a local registry. Just use the regular Kind with registry script

create this graph with: opm alpha render-graph registry.redhat.io/redhat/redhat-operator-index:v4.14 --package-name quay-operator

1. Introduction
2. Java Operator SDK
   1. Overview
   2. Detailed Analysis
   3. Top Contributors
3. Quarkus Operator SDK
4. Overview