kvm-pilot

access_paths

Read-onlyIdempotent

Check which independent recovery paths are live for a device and whether any out-of-band route survives appliance failure, with paths grouped by shared failure domain to avoid false redundancy.

Instructions

Which INDEPENDENT recovery paths are live for the device — the lockout view.

Rolls up the REST API, appliance-SSH, target-SSH, out-of-band power, and console-HID paths, each labeled by its failure domain so redundancy is not oversold: several live paths that all ride the same appliance are ONE independent domain. summary.out_of_band_live=false means every path shares the appliance's fate — a fully hung box can't be recovered remotely. summary.out_of_band is live, down (the path exists but management access to its plane failed — restore it) or none (no such path).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "access_paths"
  }
}

Input Schema

Name	Required	Description	Default
`profile`	No	Profile name from ~/.config/kvm-pilot/config.toml selecting which KVM/BMC (and its managed host) this call targets. Omit to use the server's default (KVM_PILOT_PROFILE).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.0Oct 19, 2026

addedInput schema / properties / profile / description

Added value: +"Profile name from ~/.config/kvm-pilot/config.toml selecting which KVM/BMC (and its managed host) this call targets. Omit to use the server's default (KVM_PILOT_PROFILE)."

First observedv0.1.0Jul 31, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the description does not need to repeat that. It adds valuable context by explaining the meaning of key output fields (`summary.out_of_band_live`, `summary.out_of_band` states) and the concept of failure domains, which helps an agent interpret the result correctly. It does not mention authentication or rate limits, but the added output semantics provide meaningful behavioral clarity beyond annotations.

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 front-loaded with the core purpose and then elaborates on path types and output interpretation. It is slightly long for a single optional parameter tool, but each sentence contributes useful detail without redundancy. Minor room for tightening, but well-structured overall.

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 the complexity of aggregating multiple recovery paths and the absence of an output schema, the description provides essential interpretation of the summary fields and the distinction between independent domains. It does not fully enumerate all possible output fields, but the key semantics for decision-making are covered. An agent would understand what the tool returns and how to act on it.

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

Parameters3/5

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

The only parameter, `profile`, has full schema description coverage (100%), so the schema already explains its meaning and default behavior. The tool description adds no parameter-specific information, which is acceptable given the high coverage. Baseline 3 applies.

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 states a specific purpose: reporting which independent recovery paths are live, framed as 'the lockout view'. It rolls up named path types and highlights redundancy domains, making it distinguishable from generic health or capability tools. However, it does not explicitly name or contrast with sibling tools, so the differentiation is implicit rather than stated.

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 phrase 'the lockout view' implies when to use this tool, and the interpretation of `summary.out_of_band` states provides context for reading results. But there is no explicit guidance on when to prefer this over alternatives like `healthcheck` or `appliance_status`, nor any when-not-to-use conditions.

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