List every VCF appliance this server can talk to.

Start here. Returns each target's name, product, address, auth scheme, how many API operations it serves, and whether it is currently answering. The target name from this list is what every other tool expects.

Find VCF API operations by intent, across ~7,700 indexed operations.

Search the way you would describe the task -- "commission hosts", "rotate passwords", "expand cluster", "list segments" -- rather than guessing a path. Results are ranked and include method, full request path, summary and operationId.

Args: query: What you want to do, in plain words. target: Restrict to one appliance (sddc, vcenter, nsx, ops, installer, vsan-dp). Strongly recommended when you know it. method: Restrict to GET/POST/PATCH/PUT/DELETE. limit: Maximum results (default 25). include_deprecated: Include operations VCF 9.1 marks deprecated.

Show the full signature of one API operation before calling it.

Identify the operation either by operation_id (from vcf_search_api) or by method plus path. Returns path/query parameters, the resolved request body schema with required fields marked, and response schemas.

Always do this before a POST/PATCH/PUT -- VCF request bodies are large and unforgiving, and the schema names the required fields.

Args: depth: How deep to expand nested schemas (1-6, default 3). Raise it when a nested object shows "truncated". max_properties: Cap properties rendered per object (default 60).

Call a VCF API operation. Authentication is handled for you.

This performs real operations against real infrastructure. Reads are safe; POST/PATCH/PUT/DELETE change the estate, and some are irreversible (decommissioning a host, deleting a workload domain). Every mutating call is recorded to the audit log. Check vcf_describe_api first when writing.

Long-running operations return HTTP 202 and a task id -- follow it with vcf_task rather than assuming success.

Args: target: Appliance name from vcf_targets. method: GET, POST, PATCH, PUT or DELETE. path: Full request path including any base prefix, exactly as vcf_search_api reports it (e.g. "/v1/hosts", "/policy/api/v1/infra/segments/web-seg"). Substitute real ids for {placeholders}. query: Query parameters as an object. body: JSON request body. timeout: Seconds to wait (VCF operations can be slow; default 300). max_response_chars: Shrink oversized responses to fit (default 20000).

Check, or wait on, a long-running VCF task.

Most mutations return a task id instead of a result. This reports the task's current status and, when it fails, which subtask failed and why.

Args: target: sddc or installer. task_id: The id returned by vcf_call. wait_seconds: Poll until the task reaches a terminal state or this many seconds elapse. 0 (default) checks once and returns.

Test a spec against VCF's validation endpoint WITHOUT executing it.

SDDC Manager and the Installer pair most mutating endpoints with a validation twin that takes the same request body and checks it end to end -- POST /v1/clusters/validations for POST /v1/clusters, and so on. This is the safe way to iterate on a spec before committing it.

Give the real path (e.g. "/v1/hosts") or the validation path directly; the twin is resolved automatically, run, and polled to completion. Returns validated true/false plus each failed check with its error.

Targets without the /validations convention (vCenter uses ?action=check operations) get a list of the nearest check-style operations instead.

Args: target: Appliance name from vcf_targets (sddc and installer have the richest validation surface). path: The operation you intend to run, or its /validations path. body: The same JSON body you would give the real operation. wait_seconds: How long to poll for the validation verdict.

Snapshot the estate: domains, clusters, hosts, gateways, alerts.

One call that answers "what have I got?" across SDDC Manager, vCenter, NSX and Operations. Unreachable appliances are reported inline rather than failing the whole snapshot.

Args: targets: Restrict to specific appliances (default: all with a recipe). per_section_limit: Items shown per section before summarising.

Show recent mutating calls made through this server.

Every POST/PATCH/PUT/DELETE is logged with target, path, status and a redacted body. Use it to answer "what did I change?" -- including changes made by an earlier session.