`mcp`

Speak Model Context Protocol on stdio so an agent on this host can collaborate with vrtmv. Same binary, same API token as auth. Signed the same way as every other vrtmv release.

One path to a running server

Install the signed binary — Installation. The tarball README is the verification procedure (cosign verify-blob against the Sigstore bundle). MCP is a subcommand of that binary, not a second download.
Store the API token as the same OS user the agent will run as:
```
vrtmv auth <token>
```
Print the agent fragment with this binary's absolute path:
```
vrtmv mcp --print-config
```
Paste that JSON into the agent's MCP servers config (Claude Desktop, Cursor, Grok, …). The file is the agent's; this command only prints the fragment. It does not embed the token — vrtmv auth already stored it.
Restart the agent. Ask it to call vrtmv_whoami. If that returns your account, the server is registered and authenticated.

The agent must run as the same user that ran vrtmv auth. VRTMV_API_KEY still overrides the stored token if you set it in that user's environment.

Flags

Argument / flag	Purpose
(none)	Stdio MCP server. Stdout is the protocol.
`--print-config`	Print the agent fragment and exit. Stdout is JSON, not the protocol.

Tools

Tool	Calls the API?	What it returns
`vrtmv_whoami`	yes (`GET /v1/account`)	The authenticated account
`vrtmv_assess`	no	Same JSON as `vrtmv assess --json`
`vrtmv_migrate`	yes (Index + billing)	Package identifiers, counts, artifact paths. `confirm=true` (or `preflight=true`).
`vrtmv_verify`	usage/sign only	Same JSON as `vrtmv verify --json`
`vrtmv_data_discover`	no	Same JSON as `vrtmv data discover --json`
`vrtmv_data_plan`	no	Artifact paths + attestation. `confirm=true`. Never executes.
`vrtmv_db_plan`	yes (Index)	Database version attribution vs the target OS
`vrtmv_db_upgrade_path`	yes (Index edges)	Ranked curated upgrade paths. Executes nothing.
`vrtmv_get_status`	yes (`GET /v1/version`)	Public release status. Not the internal board.
`vrtmv_whats_new`	yes (version + findings)	Releases and this account's later fixes (newest 50 considered)
`vrtmv_export_collaboration`	yes (account + findings)	Newest 50 findings: id, title, dates, status, release
`vrtmv_updates`	yes (version + findings)	One poll for releases and this account's newest 50 findings
`vrtmv_ask_question`	sometimes (`POST /v1/questions`)	Local answer, or a tracked id. `confirm=true`.
`vrtmv_list_questions`	yes (`GET /v1/questions`)	This account's questions
`vrtmv_get_question`	yes (`GET /v1/questions/:id`)	One question; 404 if not yours
`vrtmv_report_finding`	yes (`POST /v1/findings`)	Id of a redacted finding. `confirm=true`.
`vrtmv_list_findings`	yes (`GET /v1/findings`)	This account's findings (newest 50 by default)
`vrtmv_get_finding`	yes (`GET /v1/findings/:id`)	One finding; 404 if not yours

vrtmv_assess takes exactly one of root, image, ssh — a path on this host, never file contents. It is the free front door: local, unbilled.

vrtmv_migrate is the same path as vrtmv migrate. Preflight is free and writes nothing. A real migrate requires confirm=true, seats the VM once per the billing model, and writes the attestation and role under out. The tool result is package identifiers and paths, not playbook bytes. vrtmv_verify does not bill: /v1/attest/sign records no usage, and kind verify is seat-only. Only usage kind migration is billable.

vrtmv_data_discover / vrtmv_data_plan / vrtmv_db_plan / vrtmv_db_upgrade_path are the data and database lane: plan-only. source_offline is the explicit assertion that the source was quiesced. Live vrtmv run --db-upgrade stays on the CLI with --db-backup-dir.

Findings and questions are this account only. Another tenant's id is 404, not 403. Writes to those queues are capped at 10 per minute and 50 per rolling day — tighter than the plan's API rate limit — so a runaway agent cannot fill triage.

This is not the hosted Index adapter. Workload data stays on this host.