A Model Context Protocol server that provides tools for managing Karmada multi-cluster orchestration, including cluster management, policy configuration, and resource operations.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The Karmada MCP server has 10 tools defined in pkg/karmada/tools.go, but the source code excerpt does not show the actual tool implementations, only the toolset registration framework. This means I cannot verify input schemas, parameter descriptions, return types, or error handling for any tool. All 10 tools are registered via a factory pattern (ListClusters, CreatePropagationPolicy, etc.) but their JSON Schema definitions, parameter descriptions, and output structures are not visible in the provided code. Without seeing the actual tool definitions, I can only infer that tools exist by name. Per the hard scoring rule: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Since none of the 10 tools show visible schemas or detailed parameter descriptions in the excerpt, each scores very low. The naming is generally clear (verb_noun pattern: ListClusters, CreatePropagationPolicy, DeletePropagationPolicy, etc.), but descriptions are minimal one-liners. No input schemas, parameter types, or output documentation are visible in the provided excerpt.
No input schemas visible in source code. All 10 tools are inferred from registration calls, but their actual JSON Schema definitions (input parameters, types, constraints, required fields) are not shown in the provided excerpt.
Descriptions are generic one-liners (20-30 chars). Current descriptions like 'List all Karmada clusters' or 'Get a specific propagation policy' are too terse to guide LLM tool selection or explain when to use each tool vs alternatives.
Make tool definitions visible: Commit the actual ListClusters(), GetPropagationPolicy(), etc. implementations to the repo. Include the full JSON Schema for each tool's input parameters and documented return types.
Expand descriptions to 80-150 characters minimum. For each tool, answer: (1) What does it do? (2) When should the LLM call it? (3) What fields does it return? Example: 'ListClusters: Fetch all registered Karmada member clusters with names, health status, and member cluster IDs. Use this to discover available deployment targets before creating policies.'
Document all parameters with type, description, and constraints. For CreatePropagationPolicy, document: name (string, required, pattern), namespace (string, default 'default'), spec (object, required, describe policy rules structure). For CreateDeployment: image (string, required), replicas (integer, 1-100, default 1), labels (object, optional).
Implement pagination for all list tools. Add parameters: limit (1-100, default 20), offset or cursor. Return total_count and next_cursor so agents can fetch large result sets without context explosion.
Add dry-run support to CreatePropagationPolicy, CreateNamespace, CreateDeployment. Let agents preview resource definitions before committing. For DeletePropagationPolicy and DeleteUnstructuredResource, add an optional confirm=true parameter requiring explicit agent confirmation.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No parameter descriptions visible. Tools like CreatePropagationPolicy and CreateDeployment must accept parameters (e.g., name, namespace, spec), but no parameter documentation is shown. LLMs cannot infer what each parameter controls without explicit descriptions.
No output schema documentation visible. ListClusters, ListPropagationPolicy, ListDeployment should document return structure (fields, types), pagination (limit, offset, total count), and references downstream tools need (cluster_id, resource_id). Without this, LLMs cannot plan multi-step operations.
Destructive tools (DeletePropagationPolicy, DeleteUnstructuredResource) have no confirmation/dry-run pattern documented. Agents can delete resources without preview or confirmation, risking irreversible data loss.
No error handling guidance visible. Tools do not document error cases, recovery steps, or actionable error messages. E.g., if CreatePropagationPolicy fails due to invalid spec, the LLM receives no guidance on what to fix.
No pagination documented for list tools. ListClusters, ListPropagationPolicy, ListNamespace, ListDeployment should accept limit/offset or cursor parameters and return total count. Without pagination, large result sets risk exhausting context windows.
DeleteUnstructuredResource is overly generic. It accepts 'unstructured' resources (any K8s resource type), but the tool name and description do not clarify which resource types, required parameters (apiVersion, kind, name, namespace), or constraints. This invites incorrect invocations.
DeleteUnstructuredResource
Document error cases and recovery steps. For CreatePropagationPolicy: 'If validation fails, the error message lists invalid fields (e.g., invalid placement rule). Adjust spec and retry.' For DeleteUnstructuredResource: 'If resource not found, return available resources matching the resource type and namespace.'
Rename DeleteUnstructuredResource to a more specific pattern: delete_kubernetes_resource and require explicit parameters (apiVersion, kind, name, namespace) in the schema. Document which resource kinds are supported (Deployment, StatefulSet, ConfigMap, etc.).
Add tool annotations (per spec 2026-07-28) to signal to clients: readOnlyHint=true for list/get tools, destructiveHint=true for delete tools, idempotentHint=true for create tools if they are idempotent on duplicate names.
Implement structured error responses per recovery-guide pattern. Instead of raw error strings, return JSON with code, message, and recovery_suggestion. E.g., { code: 'INVALID_POLICY_SPEC', message: 'Rule 0: invalid selector syntax', suggestion: 'Selector must be valid Kubernetes LabelSelector. Review Karmada PropagationPolicy spec documentation.' }.