NanoKVM MCP Server

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

With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: it returns a JPEG image, resizes 4K images to 1080p by default to manage response size, and specifies default parameter values. However, it lacks details on potential errors, rate limits, or authentication needs, which are common for such tools.

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

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

The description is appropriately sized and front-loaded, starting with the core purpose, followed by return details, default behavior, and parameter explanations in a structured format (Args and Returns sections). Every sentence adds value without redundancy, making it efficient and easy to parse.

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

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

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete: it covers purpose, behavior, parameters, and returns. However, it lacks information on error conditions or performance implications (e.g., latency), which could be useful for an agent invoking this tool in varied contexts.

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

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

The description adds significant meaning beyond the input schema, which has 0% schema description coverage. It explains each parameter's purpose (e.g., max_width/max_height for pixel limits, quality for JPEG quality), provides default values, and clarifies special cases (use 0 for no limit). This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Capture') and resource ('screenshot from the target machine's display'), distinguishing it from sibling tools like nanokvm_click or nanokvm_move which involve interaction rather than capture. It explicitly mentions the output format (JPEG image) and the default resizing behavior for 4K images.

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

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

The description implies usage by stating it captures a screenshot for display or analysis, but does not explicitly guide when to use this tool versus alternatives like nanokvm_hdmi_status for display status or nanokvm_list_images for stored images. No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.

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