Skip to main content
Glama
DustinTrap

kvm-pilot

by DustinTrap
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

support_matrix

Read-onlyIdempotent

Query a read-only, offline matrix of tested device, firmware, and capability combinations to check what has been exercised on real hardware before running actions.

Instructions

What has actually been exercised on real hardware, per device+firmware+capability (read-only, offline — no device call).

Aggregated from the test-run ledger shipped in the package (the same data behind the wiki Hardware-Compatibility page), with each combo's derived maturity level (#98) joined from the shipped firmware registry. This is EVIDENCE, not a guarantee: a capability listed in never_exercised (or a combo with no row at all) is unverified on that hardware — treat it as mock-only/alpha maturity and confirm destructive steps with the user. status is "fail" when every recorded live attempt failed (e.g. RM1PE V1.5.1 firmware_update, #94/#95). Filters are case-insensitive; product matches as a substring.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vendorNoFilter: device vendor, case-insensitive exact match (e.g. 'GL.iNet', 'Dell').
productNoFilter: product name, case-insensitive substring (e.g. 'RM1PE', 'iDRAC').
firmware_versionNoFilter: exact firmware version string as the device reports it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.0
    • addedInput schema / properties / firmware_version / description
      Added value: +"Filter: exact firmware version string as the device reports it."
    • addedInput schema / properties / product / description
      Added value: +"Filter: product name, case-insensitive substring (e.g. 'RM1PE', 'iDRAC')."
    • addedInput schema / properties / vendor / description
      Added value: +"Filter: device vendor, case-insensitive exact match (e.g. 'GL.iNet', 'Dell')."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover read-only/idempotent/no-destructive, but the description adds substantial context beyond them: no device call is made, the data is a shipped ledger rather than a live probe, it is 'EVIDENCE, not a guarantee', and missing rows imply unverified alpha/mock-only status. It even explains the meaning of the `status` value ('fail' = every recorded live attempt failed).

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 core definition is front-loaded in the first sentence and the rest earns its place by defining the evidence semantics. It is slightly cluttered by internal issue references (#98, #94/#95) and a wiki cross-reference that an agent does not need to invoke the tool.

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?

With no output schema, the description does the work of explaining the return shape: rows per device+firmware+capability, a `status` field, and a `never_exercised` list. It stops short of describing the full field set or how maturity levels are derived, but an agent has enough to interpret results and act correctly.

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?

Schema coverage is 100% and the schema descriptions already specify case-insensitive exact match for vendor and substring for product, so the description's 'Filters are case-insensitive; product matches as a substring' largely restates structured data. The phrase 'per device+firmware+capability' hints at how filters combine, but no syntax or edge-case detail is added, so the baseline 3 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 opening line states a specific resource and scope: what has been exercised on real hardware, keyed by device+firmware+capability. It also distinguishes itself from live-query siblings by declaring 'read-only, offline — no device call', so an agent can tell it apart from `capabilities` or `healthcheck` without opening the schema.

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?

Usage context is clear: consult this before treating a capability as verified, and 'confirm destructive steps with the user' when a combo is unverified. It does not explicitly name the sibling alternative (e.g. live `capabilities`) or state when this tool should not be used, so it stops short of a 5.

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

Deploy Server

Other Tools