Loading ToolBench
A Kubernetes-native tool that reconstructs the service dependency graph from Kubernetes/Kustomize manifests and exposes it as an MCP server for AI agents, with SQLite graph, CLI, Mermaid diagrams and Markdown docs
Kubedian demonstrates solid tool design with 19 well-named, read-only tools covering Kubernetes service topology queries. All tools have descriptions (avg ~180 chars, within baseline 194), clear verb-noun naming (service_*, find_*, list_*, datastore_*), and input schemas with types and descriptions. Tool annotations (readOnlyHint) are present. However, output schemas are not documented in the source code, responses are inferred from query function returns but not formally declared. Parameter descriptions are present but sometimes lack format/constraint details (e.g., 'environment' accepts 'development, staging, production, test, all' but this is stated in description text, not as an enum). Error handling is not visible in the provided code, no recovery guidance or error categorization. All tools are read-only (no destructive operations), reducing security risk but also limiting composition complexity.
List every service that reads/writes/queues/caches a given datastore.
Reverse lookup by env var or secret/configmap KEY NAME (e.g. 'POSTGRES_HOST'): which workloads consume it, from which Secret/ConfigMap, through which env var, in which environment. Names only — never values. Set partial=true for substring matching.
Reverse lookup by port number: which services listen on it (containerPort / Service port / targetPort) and which Ingress or VirtualService routes route to it.
Index health: when it was built, counts, and render fallbacks.
Catalog of every Kubedian tool (grouped by category) plus server identity, the active graph DB and a summary of its index. Call this to answer 'what tools does Kubedian have?' or to pick the right tool for a question.
All external APIs the platform depends on, and who calls each.
Output schemas not documented. Tool responses are inferred from query function returns but no formal schema declarations visible in source. LLMs cannot plan downstream tool calls or extract fields reliably without documented return types.
Environment parameter accepts multiple values ('development, staging, production, test, all') but is not declared as an enum in schema. Constraint is stated in description text only, forcing LLMs to parse natural language rather than selecting from a machine-readable list.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
List namespaces with services, job/cronjob counts, and cross-namespace call counts.
Everything that lives in a namespace, grouped by node type (services, jobs, secrets/configmaps, PVCs, HPAs, service accounts, roles…), plus an aggregate of its cross-namespace relations: which namespaces it calls / is called from, by edge type, with example edges.
All workloads in a namespace: Deployments/StatefulSets (services), Jobs and CronJobs.
What this service depends on (services, db, cache, queue, external, storage/PVC, service account, routing targets).
Which services call this one (incoming http_calls / routes).
Deep-dive complement to service_context: the COMPLETE technical composition of one service in one call — full identity (per-container roles/resources/probes, ports, env var names), bundle siblings (workloads from the same overlay, e.g. api+worker+beat), config consumed (secrets/configmaps with key NAMES only — never values), storage with mount paths, autoscaling, ServiceAccount + granted RBAC roles, NetworkPolicy connectivity in both directions (permissions, never calls), and routing exposure with ports.
PRIMARY tool: full context for a service in ONE call — its identity (workload kind, replicas, ports, service account), who calls it, what it calls, its datastores, external dependencies, routing (Istio/Ingress), storage (PVCs), identity (ServiceAccount) and autoscaling (HPA). Every edge cites provenance (explicit vs heuristic) and source file.
A MermaidJS diagram (string) for a service (scope='focus') or the whole topology (scope='all'). Paste into Obsidian, GitHub or mermaid.live.
Blast radius: every service transitively affected if this one fails.
Every port fact for a service: containerPorts, the k8s Service's port->targetPort wiring, and how it is exposed via Ingress/VirtualService (with the routed port when declared).
Find services / datastores / external APIs by name or namespace.
Secrets and ConfigMaps a service consumes: KEY NAMES ONLY (never values), with consumption mode (env_from / env_key_ref / volume_mount) and, for valueFrom wiring, the env var -> key mapping.
Find a request path between two services, following http_calls and Istio/Ingress routes_to (so paths through a gateway are traced too).
No error handling or recovery guidance visible in source code. If a service name is not found or an invalid environment is passed, the response structure and guidance for LLM retry is not documented.
Pagination not visible for list-returning tools. service_search, list_namespaces, list_external_dependencies, service_callers, service_callees accept 'limit' but no offset/cursor or total_count documented. Large result sets risk context window exhaustion.
Tool composition risk: service_context and service_composition both return 'full context' for a service. Descriptions do not clearly distinguish when to use one vs the other, risking LLM confusion and duplicate calls.