This OVN-Kubernetes MCP server has 28 tools covering Kubernetes cluster inspection, OVN/OVS networking diagnostics, and kernel-level network analysis. STRENGTHS: All 28 tools have descriptions (critical baseline met). All tools are READ_ONLY, reducing security risk. Parameters are typed (schema: objects, string, enum constraints on tcpdump/pwru). WEAKNESSES: Descriptions are terse (avg ~50 chars, well below the 194-char production baseline). Only 6 tools have visible input schemas in the code (tcpdump, pwru, and a few others); many tool schemas are inferred from filenames rather than explicitly visible in tool registration code (e.g., ovn-show, get-conntrack, sos-list-plugins lack visible schema definitions). Several input parameters lack descriptions (e.g., tcpdump's 'interface' param has no description in the visible code). Output schemas are NOT documented, LLMs cannot determine what fields to expect in responses. Error handling is present (errorReporting=true) but guidance is not visible in the code. Tools like 'ovs-vsctl', 'ovs-ofctl', 'ovs-appctl' accept free-form command strings with no validation or constraint documentation, inviting hallucinated or invalid commands.

• Document explicit input and output schemas for all 28 tools. Use JSON Schema with proper type, description, enum, and pattern constraints. Add example response bodies in tool documentation.
• Expand tool descriptions from ~50 chars to 100 - 200 chars. Answer: What does it do? When should the LLM call it? What data does it return? Example: 'Retrieve container logs from a Kubernetes pod. Call this to debug application errors or inspect service behavior. Returns structured log entries with timestamps and log levels.'
• Replace free-form 'command' parameters (ovs-vsctl, ovs-ofctl, ovs-appctl) with structured parameters. Either: (1) define enums for common operations (e.g., list_bridges, get_port_stats), or (2) add validation and detailed error templates for invalid commands.
• Implement pagination (limit, offset/cursor, total_count) on all list tools. Cap default and max results at 50 items. Document the limit in tool descriptions.
• Add error message templates to guide LLM recovery. Example: 'Pod not found in namespace {namespace}. Try resource-list to see available pods, or check namespace spelling.'
• Standardize tool naming: use underscores (get_conntrack vs get-conntrack), verb_noun style (get_ip_config vs get-ip), and make tool names self-documenting by including the resource type.
• Add per-parameter descriptions to all tools. Example for tcpdump: interface → 'Network interface name or regex (e.g., eth0, veth*, bond0). Required on multi-interface nodes.'
• Document which tools require cluster access vs can read from must-gather bundles. This helps LLMs choose the right tool for live vs post-mortem debugging.