Model Context Protocol server for Azure Kubernetes Service (AKS) operations, providing tools for cluster management, monitoring, networking, compute resources, and Kubernetes operations.
This MCP server has 10 tools with highly inconsistent definition quality. Many tools lack visible input schemas in the source code provided, and descriptions are present but generic. The tools are split between Azure control-plane operations (call_az, aks_advisor_recommendation, get_aks_vmss_info) and Kubernetes cluster operations (call_kubectl, helm_*, cilium_status, hubble_observe, inspektor_gadget_observability). While tool names follow a reasonable verb_noun pattern, the schema and parameter documentation are severely deficient. Critical issues include: (1) No visible input parameter type definitions for most tools, only tool names and descriptions are shown; (2) descriptions are present but fall below the 50-200 char optimal range and lack actionable guidance (e.g., 'Execute arbitrary Azure CLI (az) commands with security validation' is 84 chars but provides no parameter constraints or error recovery hints); (3) No documented output schemas for any tool; (4) No parameter type declarations visible in the source snippets; (5) No evidence of input validation, enum constraints, or format specifications; (6) Dangerous tools like call_az and call_kubectl accept free-form command strings with minimal guardrails, no mention of injection prevention or command whitelisting. The codebase shows test files and handler files, but actual tool registration code with full schemas is not visible in the provided source excerpt, forcing a conservative score.
Tools (10)
aks_advisor_recommendationread onlyauth50/100
Get Azure Advisor recommendations for AKS clusters to optimize cost, performance, reliability, and operational excellence
call_azwriteauthsource verified43/100
Execute arbitrary Azure CLI (az) commands with security validation to prevent credential leakage and token exfiltration attacks
call_kubectlwriteauth42/100
Execute kubectl commands against a Kubernetes cluster with unified interface supporting various operations
cilium_statusread onlyauth43/100
Check Cilium network plugin status in Kubernetes clusters
get_aks_vmss_inforead onlyauth50/100
Get Virtual Machine Scale Set (VMSS) information for AKS node pools
No input schemas visible for most tools. Tools like inspektor_gadget_observability, helm_install, helm_upgrade, helm_uninstall, cilium_status, and hubble_observe have no documented parameter definitions in the source excerpt. Descriptions reference file locations (gadgets.go, helm.go, cilium.go) but actual schema registration code is not shown.
Free-form command execution tools (call_az, call_kubectl) accept arbitrary strings with no visible injection prevention, command whitelisting, or validation. This violates security pattern:tool-gateway and pattern:secret-injection. Descriptions mention 'security validation' but no details on how commands are sanitized or which operations are allowed.
No output schemas documented for any of the 10 tools. LLMs cannot plan downstream tool calls without knowing what data is returned, what fields are present, or how to extract IDs for chaining. This breaks pattern:tool-chain.
Recommendations
Add complete input schemas for all 10 tools. For each tool, document: parameter names, types (string, number, boolean, array, object), constraints (enum values, min/max, regex patterns), required vs. optional, and human-friendly descriptions (50-200 chars). Example for call_kubectl: parameters.command = {type: 'string', description: 'kubectl command to execute. Allowed operations: get, describe, list, logs, exec, port-forward, apply, delete. Commands are validated against a whitelist. Example: get pods -n kube-system', enum: ['get', 'describe', 'list', 'logs', 'exec', 'port-forward'], pattern: '^[a-z-]+\s+.*$'}.
Add documented output schemas for all tools. For each, declare what fields are returned, their types, and what they mean. Example for aks_advisor_recommendation: {type: 'object', properties: {recommendations: {type: 'array', items: {type: 'object', properties: {category: {type: 'string', enum: ['cost', 'performance', 'reliability', 'operational-excellence']}, severity: {type: 'string', enum: ['high', 'medium', 'low']}, description: {type: 'string'}, remediation: {type: 'string'}}}}}}.
Expand tool descriptions to 100-200 chars for Helm tools. Replace 'Install Helm charts in Kubernetes clusters' with 'Install a Helm chart into a Kubernetes cluster. Requires chart name or URL, optional namespace (default: default), optional values file, and optional release name. Returns release name, status (deployed/failed), and version installed.'
Implement command whitelisting for call_az and call_kubectl. Instead of accepting arbitrary commands, define allowed operations (e.g., get, describe, list for kubectl; group list, vm show for az) and validate input against this list. Return a clear error if a command is not whitelisted: 'Command "delete pods" is not allowed. Permitted operations: get, describe, list, logs, exec. Use helm_uninstall for destructive operations.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 23 points across a rubric change (v1 → v2)
52/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
52
<=2025-11-25
v2
2026-03-09
F
29
-
v1
helm_upgradewriteauth38/100
Upgrade Helm releases in Kubernetes clusters
hubble_observeread onlyauth40/100
Observe network traffic using Hubble in Kubernetes clusters
inspektor_gadget_observabilityread onlyauth35/100
Inspektor Gadget tool for observability and system-level debugging in Kubernetes clusters
Destructive tool (helm_uninstall) lacks confirmation/dry-run guidance. Description does not mention any safeguards against accidental deletion. Per pattern:confirmation-request, irreversible operations must support a confirm-before-execute pattern.
Generic, under-specified parameter names and descriptions. Many parameters are named generically (e.g., 'command' in call_kubectl) without indicating what values are valid, what format is expected, or what happens on invalid input. No enums, no constraints, no error recovery hints.
Minimal descriptions for Helm tools. helm_install (34 chars), helm_upgrade (34 chars), helm_uninstall (41 chars) fall below the 50-char minimum for effective LLM guidance. These are far too vague to help an LLM decide when to call them vs. similar tools.
No error handling or recovery guidance. None of the tools' descriptions explain what errors are possible, what the LLM should do if a command fails, or what fields in the response indicate success/failure. Per pattern:recovery-guide, errors must tell the agent what to do next.
Add confirmation/dry-run support for helm_uninstall. Add a parameter dry_run: boolean (default: true) so the tool can preview what will be deleted. Document in the description: 'To uninstall without confirmation, pass dry_run=false. Recommended: always run with dry_run=true first to preview what will be deleted.'
Document error cases and recovery paths for all tools. For each, describe common failures (e.g., 'Chart not found: try helm search to list available charts', 'Namespace does not exist: create it with kubectl create namespace'). Structure errors as {code, message, recovery_hint}.
Add parameter descriptions that include constraints. For timeout in call_az, add: 'Timeout in seconds (1-3600). Default: 300. If exceeded, the command is killed and an error is returned.' For node_pool_name in get_aks_vmss_info, add: 'Optional: specific node pool name (e.g., nodepool1). If omitted, VMSS info for all pools is returned.'
Return per-tool metadata in responses to support chaining. For example, helm_install should return {release_name, namespace, chart_version, status, deployment_id} so downstream tools (like helm_upgrade) can reference the release by ID without a lookup call.
For observability tools (cilium_status, hubble_observe), document what data they expose and when to call them. E.g., 'cilium_status returns health summary (running, degraded, error) and connectivity status. Call this first to check network health before troubleshooting with hubble_observe.' Add these as tool annotations or description cross-references.
Add type validation and coercion inside tools. For numeric params like timeout, validate that the input is a positive integer; for subscription_id, validate UUID format. Return actionable errors: 'Invalid timeout: "abc", must be an integer between 1 and 3600 seconds.'
Document idempotency guarantees. For helm_install, clarify: 'Idempotent: calling with the same chart name and release name will either skip (if already installed with same version) or upgrade (if version differs). Does not create duplicates.' For helm_uninstall, clarify: 'Idempotent: uninstalling a non-existent release returns success (no error).'
Add examples of successful responses in tool descriptions or return schema. E.g., for aks_advisor_recommendation: 'Returns an array of recommendation objects: [{category: "cost", severity: "high", description: "Downsize VM SKU", estimated_savings: "$1200/month"}]'.