Loading ToolBench
MCP server for JetKVM hardware control, providing tools for device management, screen observation, keyboard/mouse input, and power control via WebRTC
JetKVM MCP server demonstrates strong naming conventions (verb_noun pattern: jetkvm_list_devices, jetkvm_open_control, jetkvm_key_press) and comprehensive parameter descriptions. All 19 tools have clear, actionable descriptions (avg ~120 chars) explaining WHAT they do and WHEN to use them. Input schemas are well-structured with typed parameters and enums (e.g., detail: ["basic"]). However, output schemas are not documented in the source code, responses are inferred but not formally specified. Error handling is present but lacks recovery guidance (no 'try X instead' patterns). Tool composition is excellent: clear separation of concerns (observe vs control vs power), idempotent operations via operation_id/expected_generation fencing, and proper chaining (open_control → capture_screen → close_control). Security is strong: no secrets in parameters, destructive operations clearly marked, and generation-based fencing prevents stale calls. Minor gaps: some parameter descriptions could be more explicit about constraints (e.g., freshness_ms range), and no documented pagination or result limits.
Captures a PNG from an existing video handle. Automatically attempts one Shift wake for sleeping/no-signal video when the handle and policy permit input; disable_wake opts out.
Closes an owned control handle after input neutralization.
Returns capability state without creating a WebRTC session. Capability does not imply authorization.
Reads one fenced control handle without creating a session.
Reads power state from an existing control handle.
Reads source-attributed basic status over HTTP. It never creates or takes over a WebRTC session.
Output schemas not documented in source code. Tool responses are inferred but not formally specified, preventing LLMs from planning downstream operations or extracting required fields.
Error handling lacks recovery guidance. Errors should tell LLMs what to do next (e.g., 'Device not found. Call jetkvm_list_devices to see available devices'). Current error responses likely return raw status codes without actionable guidance.
Parameter constraints not fully explicit in descriptions. freshness_ms, idle_timeout_ms, and array bounds (e.g., 'one to sixteen' actions) should include min/max ranges in descriptions, not just in schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Presses and releases one bounded key chord.
Presses and releases one validated US-layout key.
Lists configured devices that are explicitly exposed to MCP without contacting them.
Captures a PNG from an existing video handle. Automatically attempts one Shift wake for sleeping/no-signal video when the handle and policy permit input; disable_wake opts out.
Opens an explicitly confirmed, fenced WebRTC control handle.
Clicks coordinates bound to one fresh observation and generation.
Uses only the server-owned observation_id to bind coordinates.
Runs one bounded drag bound to a server-owned observation_id.
Uses only the server-owned observation_id to bind coordinates.
Runs one bounded scroll action.
Performs a power action (on, off, reset, hold) on a device.
Runs one to sixteen deterministic input actions.
Types fully prevalidated printable US-layout text.
jetkvm_run_actions has complex nested action objects with optional properties (type, x, y, button, path, etc.). Description does not explain which properties are required for each action type or provide examples of valid action structures.
Pointer tools (click, move, drag, scroll) reference observation_id and frame dimensions but do not document what observation_id format is, how it relates to jetkvm_observe/jetkvm_capture_screen, or whether coordinates must be normalized.