Nutanix AIops

vm_get

Read-only

Retrieve a single Nutanix VM by extId and return its current ETag for safe downstream writes.

Instructions

[READ] One VM by extId, with its current ETag surfaced for downstream writes.

Args:
    vm_ext_id: VM extId as returned by vm_list.
    target: Prism Central target name from config; omit for the default.

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": {
      "vm_ext_id": "<vm_ext_id>"
    },
    "name": "vm_get"
  }
}

Input Schema

Name	Required	Description	Default
`target`	No
`vm_ext_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 28, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true, and the description reinforces that with '[READ].' More importantly, it discloses a behavioral detail beyond annotations: the ETag is surfaced for downstream writes, which is useful context for optimistic concurrency. It doesn't mention auth requirements or rate limits, but for a read operation this is adequate.

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?

The description is extremely concise: a single sentence for purpose plus two short argument descriptions. It is front-loaded with the core action and scope, with zero wasted words.

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

Completeness4/5

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

For a simple read tool with no output schema, the description provides enough to call it correctly: it states the required identifier, its source, the optional target, and the ETag behavior. It could go further by explaining when the ETag matters or what happens if the VM doesn't exist, but it is largely complete.

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 coverage is 0%, so the description must compensate. It explains that vm_ext_id is the VM extId returned by vm_list, and that target is the Prism Central target name from config, omitting for the default. Both parameters are covered with meaning beyond the schema's bare types.

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

Purpose4/5

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

The description opens with a specific verb+resource: '[READ] One VM by extId.' This clearly distinguishes it from vm_list (listing) and vm_update/vm_delete (writes). However, it doesn't explicitly name siblings or state what sets it apart beyond the read vs write distinction.

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

Usage Guidelines3/5

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

Usage is implied: fetch one VM by its extId. The description notes 'extId as returned by vm_list,' which suggests a natural workflow (list then get). But it does not state when to prefer vm_get over vm_list or other alternatives, nor does it provide explicit exclusions or conditions.

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