MCP Server for VMware AVI (NSX Advanced Load Balancer) — exposes 28 tools (22 read, 6 write) for AVI Controller and AKO Kubernetes operations. Inspect and toggle virtual services, drain pool members, check SSL certificate expiry, Service Engine health and analytics, and troubleshoot the AKO pod.
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
28 tools with consistent naming (verb_noun pattern) and descriptions. Schemas are visible and properly typed. However, descriptions are terse (average ~80 chars, baseline 194), parameters lack depth, output schemas are undocumented, and error handling is absent. Tool composition is sound, each tool has one responsibility, but LLM-facing quality (description clarity, parameter constraints, recovery guidance) is below A-grade standards. This is a competent but not exceptional implementation.
Tools (28)
ako_amko_statusread onlyauthsource verified70/100
Check AMKO (Avi Multi-Cluster Kubernetes Operator) status for multi-cluster Ingress
ako_clustersread onlyauthsource verified62/100
List Kubernetes clusters configured for AKO integration
ako_config_diffread onlyauthsource verified70/100
Show differences between desired and current AKO Helm configuration
ako_config_showread onlyauthsource verified70/100
Show the current Helm configuration of the AKO release
ako_config_upgradewriteauthsource verified70/100
Upgrade the AKO Helm release to match desired configuration
Descriptions are terse (average ~80 chars vs. baseline 194 chars). Many are bare action statements without context for when to call them, dependencies, or what they return. E.g., 'List all Virtual Services' does not explain when to call vs_status, vs_analytics, or vs_error_logs instead.
Output schemas are undocumented. Tool definitions show input parameters but not the structure of returned data. LLMs cannot plan multi-tool chains without knowing what fields a response contains (e.g., does vs_list return controller names? pool IDs?). This forces agents to guess and risks failed chaining.
Expand tool descriptions from ~80 chars to 100 - 200 chars. Add: (1) what the tool does, (2) when to call it instead of similar tools, (3) what data it returns, (4) any prerequisites. Example: 'vs_list, List all Virtual Services. Use this to discover VirtualServices before calling vs_status (for detailed state), vs_analytics (for metrics), or vs_error_logs (for error analysis). Returns service names, status, and pool assignments. Call vs_list first if you only have a partial service name.'
Document output schemas for all 28 tools. For each, publish a sample response showing field names, types, and nesting. This enables agents to plan tool chains. Example: 'vs_list returns {"services": [{"name": str, "status": str, "enabled": bool, "pool_names": [str], "ip": str}], "controller": str, "total": int}'.
Add parameter constraints to descriptions. For 'days' in ssl_expiry_check, add '(range 1 - 365, default 30)'. For 'controller' in vs_list, add 'Must match a configured controller name; see server instructions or run "vmware-avi list-controllers" to discover valid names.'
Add error handling guidance to each tool description. Example: 'If the controller is unreachable, error will indicate network/auth failure, verify controller connectivity and credentials. If a Virtual Service name does not exist, error will list similar names.'
For write operations (vs_toggle, pool_member_*, ako_config_upgrade, ako_sync_force, ako_restart), document side effects and reversibility. Example: 'vs_toggle, Enable or disable a Virtual Service. WARNING: Disabling stops traffic immediately (not graceful). Use pool_member_disable for graceful drain. This action is reversible by calling vs_toggle again with the opposite flag.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
First recorded score · v2 rubric
58/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
58
<=2025-11-25
v2
70/100
Diagnose issues with a specific Ingress object and its AVI Virtual Service mapping
ako_ingress_mapread onlyauthsource verified70/100
Show mapping between Kubernetes Ingress objects and AVI Virtual Services
ako_logsread onlyauthsource verified70/100
Retrieve logs from the AKO pod for debugging and troubleshooting
ako_restartwriteauthsource verified68/100
Restart the AKO pod to resolve runtime issues
ako_statusread onlyauthsource verified70/100
Check AKO (Avi Kubernetes Operator) pod status and health in the Kubernetes cluster
ako_sync_diffread onlyauthsource verified70/100
Show differences between Kubernetes Ingress objects and what AKO created on the AVI Controller
ako_sync_forcewriteauthsource verified70/100
Force AKO to resynchronize Ingress objects to the AVI Controller
ako_sync_statusread onlyauthsource verified70/100
Check if AKO has synchronized Ingress objects to the AVI Controller
ako_versionread onlyauthsource verified68/100
Get the installed version of AKO (Avi Kubernetes Operator)
pool_listread onlyauthsource verified62/100
List all load balancing pools configured on the AVI Controller
pool_member_disablewriteauthsource verified70/100
Disable a pool member (graceful drain)
pool_member_enablewriteauthsource verified70/100
Enable a pool member (restore traffic)
pool_membersread onlyauthsource verified70/100
List pool members and their health status (up/down/disabled)
se_healthread onlyauthsource verified62/100
Check Service Engine health status, CPU, memory, and network metrics
se_listread onlyauthsource verified62/100
List all Service Engines with their status and configuration
No error handling guidance. When a tool fails (controller unreachable, pool not found, permission denied), there is no indication of whether the error is retryable, user-fixable, or fatal. Agents cannot recover intelligently.
Parameter descriptions lack specificity. 'controller' is described as 'Controller name (optional; defaults to configured default controller)' but does not explain what happens if the named controller does not exist, or how to discover available controller names. 'days' in ssl_expiry_check has no range constraint (e.g., 1 - 365).
Write operations (vs_toggle, pool_member_enable, pool_member_disable, ako_config_upgrade, ako_sync_force, ako_restart) lack confirmation or dry-run guidance. No indication in tool description that these are irreversible or if they support a confirmation flow.
Tool descriptions do not clarify selection logic. When multiple similar tools exist (e.g., ako_status, ako_version, ako_logs, ako_config_show), descriptions do not explain why an LLM should choose one over another. The server instructions address this in _TARGET_RULE, but tool descriptions should be self-contained.
No pagination or result limits documented. Tools like vs_list, pool_list, ssl_list, se_list return potentially large result sets. Descriptions do not state whether results are paginated, capped, or streamed. Without limits, large responses can blow context windows.
Add idempotency declarations to tool descriptions. Example: 'Calling vs_toggle(name="svc", enable=true) twice returns the same state both times; safe to retry on transient failures.'
Consider adding enums for constrained parameters. Example: ako_logs could accept 'tail' as an enum (50, 100, 500, 1000) or a bounded integer (1 - 10000) rather than free-form int.
Add discovery guidance. Since agents often do not know resource names ahead of time, note where lookup tools exist. Example: 'pool_members requires a pool name. Call pool_list first to discover available pool names.'
Clarify multi-controller scope. vs_list can target different controllers, but all other tools use the default. Add a server instruction or tool description stating: 'Only vs_list accepts a controller parameter. All other tools run against the configured default controller. To query a different controller, call vs_list(controller="other") first; other tools cannot then switch controllers without restarting.'
Document AKO context selection. The 'context' parameter in AKO tools is a kubeconfig context name. Add to descriptions: 'Provide the kubeconfig context name matching your Kubernetes cluster. Defaults to the configured default context. Run "kubectl config get-contexts" to see available contexts.'
Add WRITE tool confirmation patterns. For irreversible operations (ako_config_upgrade, ako_restart, pool_member_disable), consider a two-step pattern: (1) a dry-run/preview tool that shows what will happen, (2) a confirmation tool. Or document in the description: 'Calling this tool will [specific side effect]. No dry-run available; call carefully.'
Remove or document the 'tail' parameter default in ako_logs. If it defaults to 50, say so. If it accepts any integer, add a constraint (e.g., 1 - 10000).
Clarify pool member IP vs. name. 'server' parameter is described as 'Server IP address', confirm this is IP (not hostname or ID) in both the description and any validation error messages.