Skip to main content
Glama
anyvm-org

anyvm-mcp

Official
by anyvm-org
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

anyvm-mcp

MCP server for anyvm -- boot and manage BSD, illumos, Linux, Haiku, Android, GNU Hurd, and Plan 9 VMs with natural language. Works with Claude Code, GitHub Copilot, and any other MCP-compatible AI assistant.

Overview

anyvm-mcp is a Model Context Protocol (MCP) server that bridges AI coding assistants with the anyvm VM launcher. anyvm boots prebuilt guest images under QEMU -- no manual installation, no libvirt. Once installed, your AI assistant can:

  • Boot FreeBSD, OpenBSD, NetBSD, DragonFly BSD, GhostBSD, MidnightBSD, Solaris, OmniOS, OpenIndiana, Tribblix, Haiku, Ubuntu, openEuler, BlissOS (Android), Debian GNU/Hurd, and Plan 9 guests in the background

  • Target x86_64, aarch64, riscv64, sparc64, powerpc64, s390x and more (per-OS availability varies)

  • Execute commands inside running VMs over SSH for instant diagnostics

  • Read the serial console to debug boot failures

  • Map ports and sync folders (rsync / sshfs / nfs / scp / 9p) between host and guest

  • Stop VMs gracefully (guest shutdown with an ACPI fallback) or hard-kill via the QEMU monitor

The VM model mirrors the anyvm CLI: a VM is identified by its OS name plus optional release (e.g. freebsd + 14.3), not by user-invented names. The first boot of an OS/release downloads the image from the matching anyvm-org builder release, so allow several minutes; later boots reuse the cached image.

Related MCP server: virtualization-mcp

Requirements

Requirement

Notes

Python >= 3.10

QEMU

qemu-system-* on PATH (anyvm can also self-download pinned builds for some guests)

OpenSSH client

ssh on PATH (used for exec/stop)

An MCP-compatible AI assistant

Claude Code, GitHub Copilot in VS Code, or any other MCP client

Note: The anyvm.py launcher is bundled automatically -- no separate installation needed.

Installation

pipx install anyvm-mcp

Or with pip:

pip install anyvm-mcp

Or install from source:

git clone https://github.com/anyvm-org/mcp
cd mcp
pip install -e .

Quickstart

Claude Code

Add the server to ~/.claude/mcp.json (or the project-level .claude/mcp.json):

{
  "mcpServers": {
    "anyvm": {
      "command": "anyvm-mcp"
    }
  }
}

Restart Claude Code. You can now say things like:

"Boot a FreeBSD 14.3 VM with 2 CPUs and 2 GB RAM, then run uname -a in it."

"My OpenBSD VM won't answer SSH. Show me the serial console output and suggest a fix."

GitHub Copilot (VS Code)

Add the server to .vscode/mcp.json in your workspace (or the user-level settings):

{
  "servers": {
    "anyvm": {
      "type": "stdio",
      "command": "anyvm-mcp"
    }
  }
}

Generic MCP client (HTTP/SSE)

Run anyvm-mcp as an HTTP server:

anyvm-mcp --transport sse --host 127.0.0.1 --port 8000

Then point your MCP client at http://127.0.0.1:8000/sse.

CLI reference

usage: anyvm-mcp [-h] [--anyvm PATH] [--data-dir DIR]
                 [--transport {stdio,sse,streamable-http}]
                 [--host HOST] [--port PORT]

options:
  --anyvm PATH          Path to the anyvm launcher (default: bundled anyvm.py)
  --data-dir DIR        Directory for images, logs, and VM state (default: ~/.anyvm-mcp)
  --transport           MCP transport: stdio (default), sse, or streamable-http
  --host HOST           Bind host for HTTP transports (default: 127.0.0.1)
  --port PORT           Bind port for HTTP transports (default: 8000)

Available tools

Tool

Description

list_supported_os

Every guest OS anyvm can boot, with notes and SSH user

start_vm

Boot a guest in the background (os, release, arch, mem, cpus, ports, volumes, sync)

list_running_vms

Registered VMs with a live running/stopped probe

vm_info

State, SSH port/user/key, and serial-log path for one VM

exec_in_vm

Run a shell command over SSH inside a running VM

stop_vm

Graceful guest shutdown (SSH + ACPI fallback); force hard-kills via QEMU monitor

console_output

Tail the VM serial console log (works even when SSH is down)

Notes:

  • start_vm separates OS and release: os="freebsd", release="14.3" -- omit release for the builder's default release.

  • Plan 9 (9front) guests have no SSH; exec_in_vm is unavailable for them. Use console_output, or the VNC web console anyvm prints at boot.

  • Haiku's SSH user is user; all other guests use root.

Example conversations

Boot and inspect a VM

You:      Boot an OmniOS VM with 4 CPUs and 4 GB RAM and show me its uname.
Copilot:  [calls start_vm(os="omnios", cpus=4, mem_mb=4096)]
          VM omnios-r151054 is running (ssh -p 42761 root@127.0.0.1).
          [calls exec_in_vm(os="omnios", command="uname -a")]
          SunOS omnios 5.11 omnios-r151054 i86pc i386 i86pc

Debug a boot failure

You:      My NetBSD VM never comes up on SSH. What's wrong?
Copilot:  [calls console_output(os="netbsd", lines=200)]
          The console shows the kernel waiting on root device selection...

Cross-architecture testing

You:      Run my test script on Ubuntu riscv64.
Copilot:  [calls start_vm(os="ubuntu", arch="riscv64",
                          volumes=["/home/me/proj:/proj"], sync="rsync")]
          [calls exec_in_vm(os="ubuntu", command="cd /proj && sh run-tests.sh")]

Development

# Install with dev dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Run a single test file
pytest tests/test_vm_manager.py -v

License

MIT -- see LICENSE.

Available Tools

7 tools
console_outputA

Tail the VM's serial console log. Works even when SSH is down -- the tool for debugging boot failures, and the only way to see plan9 output.

ParametersJSON Schema
NameRequiredDescriptionDefault
osYes
linesNo
releaseNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It reveals the tool is a read-only tail operation, works without SSH, and handles plan9 output. However, it does not mention potential error states, behavior when VM is not running, or rate limits. This is minimally adequate but lacks depth.

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?

Two concise sentences with no wasted words. The first sentence states the action and resource, the second provides key context and value. Information is front-loaded and every sentence is necessary.

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

Completeness2/5

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

Given there are 3 parameters with 0% schema coverage and an existing output schema, the description is incomplete. It explains the tool's purpose but offers no guidance on parameter usage or output format. The user must rely solely on parameter names, which is insufficient for effective use.

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

Parameters1/5

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

The input schema has 0% description coverage, and the tool description provides no information about the parameters 'os', 'lines', or 'release'. The description adds no value beyond the schema's property names and types. For a tool where schema coverage is low, the description must compensate, which it fails to do.

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?

The description clearly states the action: 'Tail the VM's serial console log', specifies the resource, and distinguishes from siblings by highlighting it works even when SSH is down and is the only way to see plan9 output. This is specific and differentiates from sibling tools like exec_in_vm.

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

Usage Guidelines4/5

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

The description explicitly states when to use: 'Works even when SSH is down -- the tool for debugging boot failures, and the only way to see plan9 output.' It provides clear context for boot failure and plan9 scenarios but does not explicitly mention alternatives or when not to use.

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

exec_in_vmA

Execute a shell command over SSH inside a running VM and return the combined stdout/stderr. Not available for plan9 (no SSH).

ParametersJSON Schema
NameRequiredDescriptionDefault
osYes
commandYes
releaseNo
timeout_secNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral disclosure burden. It explains the basic operation (SSH execution, combined stdout/stderr) but omits details about authentication, state changes, error handling, or the fact that the command runs with default permissions. More transparency would be beneficial.

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 a single sentence that immediately conveys the tool's purpose, followed by a crucial limitation. No unnecessary words; it is front-loaded and efficient.

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

Completeness3/5

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

The description is functionally complete for a basic understanding but lacks contextual details such as the requirement that the VM must be running, the return format (though output schema exists), and potential failure modes. Given the tool's complexity, this is adequate but not thorough.

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

Parameters2/5

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

Schema description coverage is 0% and the description adds no parameter information. It does not explain what 'os' or 'command' entail, nor the purpose of 'release' or 'timeout_sec'. The description should compensate for the missing schema descriptions, but it does not.

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?

The description clearly states the action: 'Execute a shell command over SSH inside a running VM and return the combined stdout/stderr.' It distinguishes from sibling tools like list_supported_os, start_vm, console_output, etc., and includes a notable exception (plan9).

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

Usage Guidelines4/5

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

The description explicitly notes that the tool is not available for plan9 (no SSH), providing a clear when-not-to-use. However, it does not elaborate on when to use this tool over alternatives like console_output or mention prerequisites such as requiring the VM to be running.

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

list_running_vmsA

List all VMs this server has booted, with a live running/stopped state probe, SSH ports, and log locations.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.5/5.0
Behavior3/5

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

Disclosure of 'live running/stopped state probe' adds behavioral insight beyond a simple list, but lacks details on permissions, performance impact, or side effects. No annotations to compensate.

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?

Single, efficient sentence with no unnecessary words. All information is relevant and front-loaded.

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?

Given zero parameters and presence of an output schema, the description adequately covers input (none) and output details. Could mention output format or use cases.

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?

No parameters exist, so schema coverage is 100%. Description adds value by specifying what the list includes (state, SSH ports, log locations), meeting the baseline for zero-param tools.

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?

Description clearly states it lists VMs with live state probe, SSH ports, and log locations. Verb and resource are specific, but it does not explicitly differentiate from sibling tools like vm_info or start_vm.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., vm_info for detailed VM info). Implies usage for listing, but no when-not-to-use or context.

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

list_supported_osA

List every guest OS anyvm can boot (BSDs, illumos, Linux, Haiku, Android/BlissOS, GNU Hurd, Plan 9), with notes and the SSH user.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, but the description discloses the output includes notes and SSH user. It's a read-only list, and the description is transparent about what is included.

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 a single, front-loaded sentence that lists examples and important details (notes, SSH user). Every word earns its place; no waste.

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?

Given the tool has 0 parameters and an output schema, the description adds useful context about what the output contains. It is complete for a simple list tool.

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?

There are no parameters (0 count), so baseline is 4. The description adds no parameter info, but the schema coverage is 100%.

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?

The description clearly states the tool lists every guest OS anyvm can boot, enumerating specific families. It distinguishes from sibling tools like exec_in_vm, start_vm, etc., which are about execution or management, not listing.

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

Usage Guidelines4/5

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

The description does not explicitly state when to use or alternatives, but the context of sibling tools implies no other tool lists supported OS. Usage is clear from the purpose.

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

start_vmA

Boot a guest VM in the background. The first boot of an OS/release downloads the image (hundreds of MB -- allow several minutes). Returns SSH connection details on success. OS and release are separate: os='freebsd' release='14.3', not 'freebsd-14.3'. Omit release to get the default release.

ParametersJSON Schema
NameRequiredDescriptionDefault
osYes
archNo
cpusNo
syncNo
portsNo
mem_mbNo
releaseNo
volumesNo
snapshot_modeNo
boot_timeout_secNo

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description covers that booting happens in the background, returns SSH details, and first boot is slow. It lacks disclosure on potential conflicts, resource limits, or state changes beyond creation. Adequate but not comprehensive.

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?

Three sentences, each adding distinct value: purpose, performance caveat, and parameter clarification. No redundant or vague statements; information is front-loaded and efficient.

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

Completeness2/5

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

Given the complexity (10 parameters, no output schema, no annotations), the description is too sparse. Key details about optional parameters and expected return values beyond SSH info are missing, making it incomplete for an agent to use effectively.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It only explains two parameters (os and release) with formatting hints, leaving eight parameters (arch, cpus, ports, etc.) completely unexplained. This is insufficient for a tool with 10 parameters.

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?

The description clearly states the tool boots a guest VM in the background, specifying the action and resource. It distinguishes from sibling tools like list_supported_os or exec_in_vm by focusing on VM startup and return of SSH details.

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

Usage Guidelines4/5

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

Provides explicit guidance on first boot performance and the correct format for os and release parameters, including how to get the default release. However, it does not discuss when alternatives might be preferred or when not to use this tool.

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

stop_vmA

Stop a running VM: graceful guest shutdown over SSH with an ACPI fallback; force=true hard-kills QEMU via its monitor.

ParametersJSON Schema
NameRequiredDescriptionDefault
osYes
forceNo
releaseNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior4/5

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

With no annotations, description carries full burden. It explains the two behavioral paths (graceful shutdown with fallback and hard-kill), though it could clarify the fallback sequence.

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?

Two concise sentences, front-loaded with the main action, no superfluous words.

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

Completeness3/5

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

Description covers the main behavior but lacks parameter details and does not address output or edge cases. Output schema exists but is not leveraged in description.

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

Parameters2/5

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

Schema coverage is 0%, and description only explains 'force' parameter. Required parameter 'os' and optional 'release' are not described, leaving the agent with insufficient parameter semantics.

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?

Clearly states 'Stop a running VM' and details two shutdown methods (graceful via SSH/ACPI fallback and hard-kill via monitor), distinguishing it from sibling tools like start_vm and exec_in_vm.

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

Usage Guidelines4/5

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

Implies use cases for graceful vs force shutdown, but lacks explicit guidance on when to use force=true or prerequisites like VM must be running.

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

vm_infoB

Detailed info about one VM (state, SSH port/user/key, serial log path). Identify the VM by OS name and optional release.

ParametersJSON Schema
NameRequiredDescriptionDefault
osYes
releaseNo

TDQS

B3.3/5.0
Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It states the tool returns state, SSH port/user/key, and serial log path, but does not clarify if the VM must be running, if it is a read-only operation, or any side effects.

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

Conciseness4/5

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

The description is a single, front-loaded sentence that effectively communicates the tool's purpose and key parameters. It avoids unnecessary words.

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

Completeness3/5

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

Given the sibling tools and no output schema, the description lists returned fields (state, SSH port/user/key, serial log path) but does not confirm if this is exhaustive or mention other possible details. Adequate but not fully comprehensive.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It adds that 'os' identifies the VM by name and 'release' is optional, but does not explain constraints, formats, or how to obtain valid values.

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?

The description clearly states the tool retrieves 'detailed info about one VM' and lists specific fields (state, SSH port/user/key, serial log path). It distinguishes from siblings like list_running_vms (list all) and exec_in_vm (execute commands).

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for getting details about a specific VM identified by OS name and optional release, but does not provide scenarios or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 15 tool updatesv0.0.3
    • Changedconsole_output4 fields changed
      • removedInput schema / properties / name
        Removed value: -{
-  "title": "Name",
-  "type": "string"
-}
      • addedInput schema / properties / os
        Added value: +{
+  "title": "Os",
+  "type": "string"
+}
      • addedInput schema / properties / release
        Added value: +{
+  "default": "",
+  "title": "Release",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "name"
-]New value: +[
+  "os"
+]
    • Removedcreate_snapshot
    • Removedcreate_vm
    • Removeddelete_snapshot
    • Removeddestroy_vm
    • Changedexec_in_vm5 fields changed
      • removedInput schema / properties / name
        Removed value: -{
-  "title": "Name",
-  "type": "string"
-}
      • addedInput schema / properties / os
        Added value: +{
+  "title": "Os",
+  "type": "string"
+}
      • addedInput schema / properties / release
        Added value: +{
+  "default": "",
+  "title": "Release",
+  "type": "string"
+}
      • addedInput schema / properties / timeout_sec
        Added value: +{
+  "default": 120,
+  "title": "Timeout Sec",
+  "type": "integer"
+}
      • changedInput schema / required
        Previous value: -[
-  "name",
-  "command"
-]New value: +[
+  "os",
+  "command"
+]
    • Addedlist_running_vms
    • Removedlist_snapshots
    • Addedlist_supported_os
    • Removedlist_vms
    • Removednetwork_info
    • Removedrestore_snapshot
    • Changedstart_vm13 fields changed
      • addedInput schema / properties / arch
        Added value: +{
+  "default": "",
+  "title": "Arch",
+  "type": "string"
+}
      • addedInput schema / properties / boot_timeout_sec
        Added value: +{
+  "default": 1800,
+  "title": "Boot Timeout Sec",
+  "type": "integer"
+}
      • addedInput schema / properties / cpus
        Added value: +{
+  "default": 0,
+  "title": "Cpus",
+  "type": "integer"
+}
      • addedInput schema / properties / mem_mb
        Added value: +{
+  "default": 0,
+  "title": "Mem Mb",
+  "type": "integer"
+}
      • removedInput schema / properties / name
        Removed value: -{
-  "title": "Name",
-  "type": "string"
-}
      • addedInput schema / properties / os
        Added value: +{
+  "title": "Os",
+  "type": "string"
+}
      • addedInput schema / properties / ports
        Added value: +{
+  "default": [],
+  "items": {
+    "type": "string"
+  },
+  "title": "Ports",
+  "type": "array"
+}
      • addedInput schema / properties / release
        Added value: +{
+  "default": "",
+  "title": "Release",
+  "type": "string"
+}
      • addedInput schema / properties / snapshot_mode
        Added value: +{
+  "default": false,
+  "title": "Snapshot Mode",
+  "type": "boolean"
+}
      • addedInput schema / properties / sync
        Added value: +{
+  "default": "",
+  "title": "Sync",
+  "type": "string"
+}
      • addedInput schema / properties / volumes
        Added value: +{
+  "default": [],
+  "items": {
+    "type": "string"
+  },
+  "title": "Volumes",
+  "type": "array"
+}
      • changedInput schema / required
        Previous value: -[
-  "name"
-]New value: +[
+  "os"
+]
      • changedOutput schema / (root)
        Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "start_vmOutput",
-  "type": "object"
-}New value: +null
    • Changedstop_vm4 fields changed
      • removedInput schema / properties / name
        Removed value: -{
-  "title": "Name",
-  "type": "string"
-}
      • addedInput schema / properties / os
        Added value: +{
+  "title": "Os",
+  "type": "string"
+}
      • addedInput schema / properties / release
        Added value: +{
+  "default": "",
+  "title": "Release",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "name"
-]New value: +[
+  "os"
+]
    • Changedvm_info4 fields changed
      • removedInput schema / properties / name
        Removed value: -{
-  "title": "Name",
-  "type": "string"
-}
      • addedInput schema / properties / os
        Added value: +{
+  "title": "Os",
+  "type": "string"
+}
      • addedInput schema / properties / release
        Added value: +{
+  "default": "",
+  "title": "Release",
+  "type": "string"
+}
      • changedInput schema / required
        Previous value: -[
-  "name"
-]New value: +[
+  "os"
+]
  2. 13 tool updatesv0.0.2
    • First observedconsole_output
    • First observedcreate_snapshot
    • First observedcreate_vm
    • First observeddelete_snapshot
    • First observeddestroy_vm
    • First observedexec_in_vm
    • First observedlist_snapshots
    • First observedlist_vms
    • First observednetwork_info
    • First observedrestore_snapshot
    • First observedstart_vm
    • First observedstop_vm
    • First observedvm_info
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0
Disambiguation5/5

Each tool has a distinct purpose: listing supported OS, executing commands, viewing console, starting, listing all VMs, getting VM info, and stopping VMs. No overlap.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (list_supported_os, exec_in_vm, start_vm, etc.) with no deviations.

Tool Count5/5

7 tools cover the core VM lifecycle (start, stop, exec, console, list, info) and supported OS queries, which is well-scoped for the server's purpose.

Completeness4/5

Covers most essential operations: start, stop, execute commands, console output, listing, and details. Missing destroy/reboot but still functional.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Homelab MCP Server

    washyu
    A
    license
    B
    quality
    A
    maintenance
    Enables AI assistants to manage homelab infrastructure through automated service installation (Jellyfin, Pi-hole, Ollama, Home Assistant, Frigate NVR), VM operations, AI accelerator support (MemryX, Coral TPU, Hailo-8), and Terraform state management with SSH-based discovery and deployment.
    58
    4
    MIT

  • virtualization-mcp

    sandraschi
    A
    license
    B
    quality
    A
    maintenance
    Enables AI assistants to manage virtual machines, sandboxes, and dev environments through VirtualBox, Hyper-V, and Windows Sandbox, supporting VM lifecycle, ISO downloads, networking, and unattended installs.
    9
    14
    MIT

  • ProxmoxEmCP

    PureGrain
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to manage Proxmox VE infrastructure, including VMs, containers, storage, and cluster operations via natural language.
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/anyvm-org/mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server