What can you do with this server?

The KVMFleet MCP Server enables AI assistants to interact with KVM Fleet's infrastructure management platform for device management, auditing, and security compliance. * List devices – View all KVM devices in the organization, including online/offline state and recent health metrics (e.g., "is X online?", "what's in the fleet?") * Get device health – Retrieve a detailed health snapshot for a specific device, including temperature, uptime, agent version, and last-seen timestamp (requires a device UUID) * Query audit log – Retrieve recent audit events with optional filters for action type, result (success, failure, denied), and limit (1–500 events); useful for questions like "were there failed logins overnight?" * Verify audit integrity – Re-walk the per-org audit hash chain to confirm it is intact, providing compliance reassurance * List open console sessions – Show all currently active (unended) console sessions in the organization Opt-in write tools are also described (power actions, ISO mount/unmount, access request approval, ending sessions, acknowledging alerts), though these may not be enabled by default. All access is RBAC-enforced and fully audited server-side.

How do I use KVMFleet MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@KVMFleet MCP Server How many devices are currently offline?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

KVMFleet MCP Server

Official

by KVMFleet

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

@kvmfleet/mcp — MCP server for KVM Fleet

A Model Context Protocol server that lets AI assistants (Claude Desktop, Cursor, Continue, etc.) work across your KVM Fleet fleet through the official REST API. All access is RBAC-enforced, policy-checked, and audited server-side.

What you can ask it to do

Read mode (default):

"How many devices do I have? Which are offline?"
"Show me failed logins in the last 24 hours."
"What approvals are waiting on me right now?"
"Generate this month's NIS2 compliance snapshot — surface the dropped controls."
"What alerts fired overnight?"
"Verify my audit log integrity."
"When was my audit chain last anchored to a witness?"
"Why was alice@acme.co denied access to srv-pdx-3 yesterday?" (logged decision + reason)
"Show the CPU-temp trend for R7525-NORD-1 over the last 12 hours."
"Run the compliance-evidence workflow for ISO 27001 and give me an auditor link." (prompt)

Write mode (opt-in, see below):

"Power-cycle host R7525-NORD-1."
"Mount ubuntu-24.04.iso on R7525-NORD-1 — I'll reinstall."
"Approve the access request from alice@acme.co for the kernel-patching ticket."
"End the console session that's been open more than 8 hours on srv-pdx-3."
"Acknowledge the disk-full alert on the prod database host."

Related MCP server: Parallels RAS MCP Server

Tools

Reads (always available)

Tool	Maps to
`list_devices`	`GET /v1/devices`
`get_device_health`	`GET /v1/devices/{id}`
`get_power_state`	`GET /v1/devices/{id}/power`
`get_device_metrics`	`GET /v1/devices/{id}/metrics`
`query_audit_log`	`GET /v1/audit/events`
`verify_audit_integrity`	`GET /v1/audit/integrity`
`get_audit_chain_head`	`GET /v1/audit/head`
`get_inclusion_proof`	`POST /v1/audit/inclusion-proof`
`list_audit_witnesses`	`GET /v1/audit-witnesses`
`list_open_console_sessions`	`GET /v1/console-sessions?open_only=true`
`list_access_grants`	`GET /v1/access-grants`
`list_policies`	`GET /v1/policies`
`list_policy_evaluations`	`GET /v1/policy-evaluations`
`list_alerts`	`GET /v1/alerts/history`
`list_isos`	`GET /v1/isos`
`list_team`	`GET /v1/team`
`get_compliance_config`	`GET /v1/compliance`
`get_compliance_score`	`POST /v1/reports/{framework}?format=json`
`render_compliance_report`	`POST /v1/reports/{framework}` (json / csv)
`list_report_shares`	`GET /v1/report-shares`

list_policy_evaluations returns logged past decisions — each with one result and one human-readable reason. It is not a live rule-by-rule trace.

Writes (opt-in via `KVMFLEET_MCP_ALLOW_WRITES=true`)

Tool	Maps to	Confirm?
`power_action`	`POST /v1/devices/{id}/power`	yes for off / off_hard / cycle
`request_access`	`POST /v1/devices/{id}/access-requests`	—
`approve_access`	`POST /v1/access-grants/{id}:approve`	—
`deny_access`	`POST /v1/access-grants/{id}:deny`	—
`revoke_access`	`POST /v1/access-grants/{id}:revoke`	yes
`mount_iso`	`POST /v1/devices/{id}/iso:mount`	yes
`unmount_iso`	`POST /v1/devices/{id}/iso:unmount`	—
`end_console_session`	`POST /v1/console-sessions/{id}:end`	yes
`acknowledge_alert`	`POST /v1/alerts/history/{id}/acknowledge`	—
`resolve_alert`	`POST /v1/alerts/history/{id}/resolve`	—
`create_report_share`	`POST /v1/report-shares`	yes (publishes an external link)

Write tools requiring confirm: true will refuse the call with a clear error if the LLM omits the flag. This protects against "AI accidentally power-cycled prod".

Prompts

Curated, one-shot governance workflows — invoke them as slash-commands in clients that surface MCP prompts (e.g. Claude Desktop). Each composes only the tools above and is verb-bounded: it assembles and summarises; it never attests, detects, or diagnoses.

Prompt	Composes	Produces
`compliance-evidence <framework>`	`render_compliance_report` + `get_inclusion_proof` + (writes) `create_report_share`	an evidence pack: report summary, offline-verifiable proof bundle, optional auditor link
`access-review [days]`	`list_access_grants` + `query_audit_log`	a who-accessed-what summary over the window for a human reviewer
`audit-integrity-check`	`verify_audit_integrity` + `get_audit_chain_head`	the chain re-walk result + current chain head
`policy-posture`	`list_policies` + `list_policy_evaluations`	configured rules + how they have been deciding access

Install

npm install -g @kvmfleet/mcp

Or use npx directly in the Claude Desktop config below.

Get an API token

Log into app.kvmfleet.io.
Account → API tokens → Create token.
Copy the token (shown exactly once).

The token inherits your current org role. Power actions / ISO mount / console-session end require org_admin or operator. Revoke any time from the same page — it stops working immediately.

Wire up Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "kvmfleet": {
      "command": "npx",
      "args": ["-y", "@kvmfleet/mcp"],
      "env": {
        "KVMFLEET_API": "https://app.kvmfleet.io",
        "KVMFLEET_TOKEN": "kvmf_paste_your_token_here"
      }
    }
  }
}

Restart Claude Desktop. Read tools are now available.

Enabling write mode

Add KVMFLEET_MCP_ALLOW_WRITES to the env block:

{
  "mcpServers": {
    "kvmfleet": {
      "command": "npx",
      "args": ["-y", "@kvmfleet/mcp"],
      "env": {
        "KVMFLEET_API": "https://app.kvmfleet.io",
        "KVMFLEET_TOKEN": "kvmf_paste_your_token_here",
        "KVMFLEET_MCP_ALLOW_WRITES": "true"
      }
    }
  }
}

When unset (or anything other than the literal string "true"), write tools are not advertised to the LLM at all. When enabled, destructive actions still require an explicit confirm: true arg.

What the platform still enforces

The MCP layer is a thin SDK. The platform does the real work on every call:

RBAC — power actions need org_admin/operator; approving an access request needs the appropriate role; the token inherits the operator's role.
Policy engine — time-of-day rules, require_mfa, max_concurrent_sessions, approval_required, etc. all fire on agent-originated calls the same way they fire on human-originated ones.
JIT access — a power action against a device that requires JIT access will refuse if there's no active grant.
4-eyes approval — an operator approving their own access request is refused server-side.
Audit chain — every action lands as an audit-event row in the per-org hash chain. The agent's calls are tagged via the x-kvmfleet-mcp-client header so a human auditor can correlate.
Rate limits — per-device, per-user, per-action limits apply unchanged.

If a call is refused, the error from the platform is surfaced verbatim so the LLM can read it and act on it.

Privacy

The token is sent to your KVM Fleet platform only — never to Anthropic, the MCP package, or any third party. Read the platform's Privacy Policy for what's logged on our side (audit-event row per call).

Local dev

cd kvmfleet/mcp
npm install
npm run build
npm start                                              # reads only
KVMFLEET_MCP_ALLOW_WRITES=true npm start               # reads + writes

Roadmap

MSP context-switch — KVMFLEET_MSP_PARENT_ORG_ID env to scope tools to a single managed customer.
Tagged audit rows — the platform will surface actor_type=agent on audit rows originating from the MCP, so compliance reviewers can split human vs. agent action history.
Token-scope enforcement — once API tokens grow a scope: read | write field on the platform, the MCP will refuse to expose writes on a read-only token.

License

Available Tools

5 tools

get_device_healthB

Detailed health snapshot for a single device: temperature, uptime, agent version, last seen.

ParametersJSON Schema

Name	Required	Description	Default
`device_id`	Yes

TDQS

B3.3/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 full burden. It implies a safe read operation by mentioning 'health snapshot' with no side effects, but does not explicitly state read-only nature or potential failure modes.

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?

Single sentence of 10 words is concise and front-loaded with the core action. However, it could have included brief but important context without becoming verbose.

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 low complexity (1 param, no output schema, no annotations), the description covers key fields but omits output structure, error scenarios, or any further behavioral cues. 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 coverage is 0% with no parameter description. The description adds only that the tool is for a single device, implying device_id is the identifier. This is minimal beyond the schema's type and requiredness.

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 a specific verb ('get health snapshot') and resource ('single device'), listing concrete fields (temperature, uptime, agent version, last seen). It distinguishes from siblings that list devices or audit logs.

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 versus alternatives like list_devices. The description implies it requires a device_id but does not provide contextual cues for selecting this over other tools.

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

list_devicesA

List all KVM devices in the operator's organisation, with online/offline state and recent health metrics. Use this to answer 'what's in the fleet' or 'is X online' questions.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses that the tool lists devices with state and metrics (indicating a read operation) but lacks details about performance, pagination, or any other behavioral traits. Minimal but sufficient for a simple list-all tool.

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 succinct sentences, front-loaded with the core action ('List all KVM devices') and no redundant 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?

Given no output schema, the description adequately covers the tool's purpose and output scope. It could be slightly more specific about the health metrics, but overall it is complete for this simple 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?

The tool has no parameters, and the description does not need to add meaning beyond the schema, which covers 100%. Baseline score of 4 applies.

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 all KVM devices with state and health metrics, and the usage examples ('what's in the fleet', 'is X online') differentiate it from sibling tools like get_device_health, which likely targets a single device.

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 usage context ('Use this to answer...') but does not mention when not to use it or directly compare to siblings, though the examples imply its scope.

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

list_open_console_sessionsA

List currently-open (unended) console sessions in the org.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, and the description merely restates the action without disclosing permissions, pagination, or other behavioral traits beyond the basic listing.

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 sentence, front-loaded with the action, every word essential for a simple list tool.

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 zero parameters, no output schema, and a simple purpose, the description fully covers what the tool does and suffices for an agent to invoke it.

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?

With zero parameters, baseline is 4. The description adds no parameter details but none are needed; it compensates by clarifying the resource scope.

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 uses a specific verb (List), resource (console sessions), and qualifier (currently-open/unended in the org), clearly distinguishing it from sibling tools which focus on devices, audits, etc.

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?

The description implies usage for viewing open sessions but provides no explicit guidance on when to use or avoid, nor mentions alternatives among siblings.

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

query_audit_logB

Recent audit events for the org, optionally filtered. Useful to answer questions like 'who started a console session today' or 'were there failed logins overnight'.

ParametersJSON Schema

Name	Required	Description	Default
`action`	No
`result`	No
`limit`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description only mentions 'recent' events without specifying the time range, ordering, or that it is a read-only operation. This leaves significant behavioral gaps.

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 two sentences long, front-loaded with the core purpose, and contains no extraneous information.

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 three parameters, no output schema, and no annotations, the description is too minimal. It lacks details on response format, pagination, or any limitations, making it incomplete for a tool of this complexity.

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?

With 0% schema description coverage, the description only alludes to filtering but does not explain the specific parameters (action, result, limit) beyond the schema definitions.

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 it provides recent audit events with optional filtering, and gives specific example questions, distinguishing it from sibling tools like 'verify_audit_integrity'.

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?

While the description gives example questions to illustrate usage, it does not explicitly state when to use this tool versus siblings or when not to use it.

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

verify_audit_integrityA

Re-walk the per-org audit hash chain on the server and report whether it's intact. Use this when a user wants compliance reassurance.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations provided, so the description must disclose behavioral traits. It describes the main action but does not state whether the tool is read-only, if it requires special permissions, or if it has performance implications (e.g., heavy computation from re-walking the chain). This leaves important gaps.

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 sentences: the first states the action and outcome, the second gives usage guidance. No fluff, front-loaded with core information.

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?

Without an output schema, the description should detail the return value. It vaguely says 'report whether it's intact', which implies a boolean or status, but lacks specifics on format or additional data. For a simple tool, this is adequate but not fully 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?

The tool has zero parameters, and the schema coverage is 100%. The description does not need to add parameter semantics. Baseline score of 4 is appropriate.

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: 'Re-walk the per-org audit hash chain' and the result: 'report whether it's intact'. It distinguishes this tool from siblings like query_audit_log by focusing on integrity verification.

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?

Explicitly says 'Use this when a user wants compliance reassurance', providing a clear usage context. Does not state when not to use, but the context strongly implies it's for integrity checks, not general log queries.

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.

5 tool updatesv0.1.0May 14, 2026
- First observedget_device_health
- First observedlist_devices
- First observedlist_open_console_sessions
- First observedquery_audit_log
- First observedverify_audit_integrity

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-05-14 19:10 across 5 tools

Disambiguation5/5

Each tool targets a distinct aspect: device health, device listing, console sessions, audit events, and audit integrity. No overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., get_device_health, list_devices). No mixing of conventions.

Tool Count5/5

With 5 tools, the server is well-scoped for monitoring and auditing a KVM fleet. No unnecessary tools.

Completeness4/5

Covers device health, listing, sessions, and audit, but lacks operations to start/stop console sessions or manage devices. Minor gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

AIStatusDashboard
io.github.aistatusdashboard
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Monitoring Observability
2
UsageMax public observability A
io.github.SYMBaiEX
Read-only MCP for AI usage profiles, leaderboards, stats, and docs; no writes or private data.
AI & Machine Learning Observability
41
ambiscribe
io.ambiscribe
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Monitoring Observability Security
2
ORANO Personal Context MCP
io.github.manuvamp
Read-only MCP server: let AI agents read your ORANO saved-video library, tasks, and memory.
Knowledge & Memory Entertainment & Media Project Management
1

Related MCP Servers

NetBox MCP Server
Search Databases
chadkunsman
A
license
Not graded
quality
C
maintenance
A read-only FastMCP server that enables AI assistants to query and retrieve network infrastructure information from NetBox using natural language.
Updated 4 months ago (2026-06-03 23:59 UTC)
MIT
Parallels RAS MCP Server
Monitoring Virtualization App Automation
RMITBLOG
A
license
A
quality
D
maintenance
A read-only MCP server that provides visibility into Parallels Remote Application Server infrastructure, policies, and sessions through the RAS REST API. It enables AI assistants to query site settings, published applications, and license status without performing any modifications.
Updated 4 months ago (2026-05-23 10:00 UTC)
41
2
MIT
@rarecloudio/mcp-serverofficial
Cloud Platforms Developer Tools Payments & Billing
RareCloudio
A
license
A
quality
B
maintenance
Read-only MCP server for the RareCloud API, enabling AI agents to list servers, browse the catalog, check billing, and plan deployments.
Updated 18 days ago (2026-09-10 07:05 UTC)
100
17 npm
MIT
proxmox-mcp
Virtualization Observability
edymol
A
license
A
quality
C
maintenance
A read-only MCP server for Proxmox VE that provides AI assistants with structured visibility into cluster nodes, guests, storage, and Docker workloads. It is designed to prevent any mutating operations by construction.
Updated 2 months ago (2026-08-01 23:01 UTC)
12
MIT

@kvmfleet/mcp — MCP server for KVM Fleet

What you can ask it to do

Tools

Reads (always available)

Writes (opt-in via KVMFLEET_MCP_ALLOW_WRITES=true)

Prompts

Install

Get an API token

Wire up Claude Desktop

Enabling write mode

What the platform still enforces

Privacy

Local dev

Roadmap

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

@rarecloudio/mcp-serverofficial

Writes (opt-in via `KVMFLEET_MCP_ALLOW_WRITES=true`)