vmware-avi

get_virtual_service_status

Read-onlyIdempotent

Retrieve detailed status for a single Virtual Service by exact name, covering VIP, pool, health, connections, and throughput. Use after listing services to verify runtime state.

Instructions

[READ] Detailed status for one Virtual Service: VIP, pool, health, connections, throughput.

Returns one detail block, not a list. Use list_virtual_services first for the exact name — a name that does not match exactly fails. If the runtime read fails, the block says so (with the HTTP status) and health is UNKNOWN. Then get_virtual_service_analytics for metrics, get_virtual_service_error_logs for 5xx.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "get_virtual_service_status"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	Exact Virtual Service name.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.4.0Oct 18, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover safety (readOnly, idempotent, non-destructive), but the description adds non-obvious behavior: exact-match name resolution fails otherwise, and a failed runtime read is reported in-band with HTTP status while health becomes UNKNOWN. That failure-mode disclosure is exactly the extra context annotations cannot supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with the read tag and purpose, then failure behavior, then alternative routing. No filler; each clause carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be spelled out, and the description still characterizes the single-block shape and degraded/failure response. Combined with the prerequisite and sibling routing, an agent has everything needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines 'name'; the description goes beyond it by specifying exact-match semantics and the list-first workflow to obtain a valid value. This adds real meaning over the schema, though it is a single well-documented parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (detailed status for one Virtual Service) and enumerates the payload it returns (VIP, pool, health, connections, throughput). It explicitly contrasts itself with list_virtual_services ('one detail block, not a list'), so an agent can tell it apart from its siblings without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit prerequisite ('Use list_virtual_services first for the exact name') and routes to alternatives for adjacent needs ('get_virtual_service_analytics for metrics, get_virtual_service_error_logs for 5xx'). When/when-not and named alternatives are all present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.