MCP (Model Context Protocol) server for kubefwd, enabling AI assistants like Claude to interact directly with kubefwd for debugging, monitoring, and managing Kubernetes port forwarding.
The kubefwd MCP server provides 23 well-named tools with consistent verb-noun naming (add_namespace, get_pod_logs, list_services). All tools have descriptions (most 80 - 250 chars, within the 10 - 1024 baseline). Input schemas are present and mostly complete with type declarations. However, critical gaps emerge: (1) Output schemas are entirely undocumented, no response field definitions visible for any tool, forcing LLMs to guess what data is returned. (2) Error handling is absent, no recovery guidance, error classification, or actionable messages. (3) Descriptions lack specificity on prerequisites, dependencies, and return structure. (4) Several destructive operations (remove_namespace, remove_service) lack dry-run or confirmation patterns. (5) Parameters accept free-form strings where enums are warranted (e.g., 'status' in list_services should enumerate 'active|error|partial|pending'). The tool set is well-composed (each does one thing), naming is clear, and read-only tools predominate, but documentation density and LLM-optimized descriptions fall short of production baselines.
Forward all services in a namespace to localhost. Adds /etc/hosts entries for each service. Returns list of discovered services with connection info.
Forward a single service to localhost. Returns local IP, hostnames (added to /etc/hosts), and mapped ports. Requires namespace and service_name.
Run comprehensive error diagnostics. Analyzes all port forward errors, system state, and logs to provide a health assessment and recommendations.
Search for services by name, port, or namespace. Useful for discovering services available to forward.
Get connection details for a forwarded service: IP address, hostnames, ports, and environment variables. Use after add_service to get ready-to-use connection strings. Requires service_name.
Get service endpoints showing which pods are backing the service and their IPs. Essential for understanding service topology. Requires namespace and service_name.
Output schemas completely undocumented. No response field definitions, types, or structures visible for any of the 23 tools. LLMs cannot plan downstream calls or extract data without guessing response shape.
Error handling entirely absent. No recovery guidance, error classification, or actionable messages. Tools like remove_namespace and remove_service are destructive but provide no dry-run, confirmation, or rollback mechanisms. LLMs have no path forward on failure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 70 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Get Kubernetes events in a namespace. Useful for diagnosing cluster issues and understanding why pods might be failing. Filter by resource kind/name. Requires namespace.
Get history of events, errors, or reconnections. Type parameter selects which history to retrieve. Can filter by service key and event type.
Get HTTP request/response traffic captured from a forwarded service or port forward. Returns recent HTTP transactions with request/response details.
Get kubefwd application logs. Filter by log level (debug, info, warn, error, all) and search terms.
Get performance metrics for port forwards. Scope controls detail level: 'summary' for overall stats, 'by_service' for per-service breakdown, or 'service_detail' for a specific service. Optionally limit to a specific service.
Get detailed information about a specific Kubernetes pod including status, containers, volumes, and events. Requires namespace and pod_name.
Get logs from a Kubernetes pod. Useful for debugging services. Returns recent log lines from the pod's container. Requires namespace and pod_name. Get pod names from list_pods or get_service output.
Get detailed information about a forwarded service including all port forwards, their status, and any errors.
List available Kubernetes namespaces with forwarding status. Use to discover what can be forwarded.
List services in a namespace with type, ports, and forwarding status. Use to discover what can be forwarded. Requires namespace.
List Kubernetes pods with status, ready state, restarts, and age. Filter by label selector or service name. Essential for finding which pods back a service. Requires namespace.
List all forwarded services with their status (active, error, partial, pending). Optionally include detailed port forward information.
Reconnect all services that are currently in an error state. Returns the count of services reconnection was triggered for.
Reconnect a service that has encountered errors. Useful for recovering from temporary network failures or pod restarts.
Stop all service forwards in a namespace. Removes /etc/hosts entries and cleans up network interfaces.
Stop forwarding a service. Removes /etc/hosts entries and releases the allocated IP. Requires key (e.g., 'servicename.namespace.context').
Sync a service's state with Kubernetes. Useful after making changes in Kubernetes (adding/removing pods, changing ports, etc.). Optionally force sync to skip debounce timer.
Enum parameters lack constraint declarations. 'status' in list_services and 'level' in get_logs accept free-form strings. Should enumerate allowed values (status: active|error|partial|pending; level: debug|info|warn|error|all) to prevent hallucinated input.
No pagination support visible. list_k8s_namespaces, list_k8s_services, list_pods, and list_services lack limit/offset/cursor parameters and total_count returns. Large Kubernetes clusters could return thousands of items, exhausting context.
Descriptions lack LLM-optimized structure. Missing WHEN-to-use guidance, prerequisites, and return-structure hints. E.g., add_service says 'Returns list of discovered services' but doesn't specify whether this is the newly-forward service or all services, or what fields are included.
Missing dependency hints and parameter relationships. Tools like get_connection_info accept optional namespace but don't explain fallback behavior if service_name is ambiguous. add_service accepts optional ports but doesn't specify behavior if omitted.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) absent. LLMs cannot easily distinguish which tools are safe to retry vs. which have side effects. Destructive tools (remove_*) should be annotated.