qnx-mcp

Overview Schema Source Related Servers Discussions Admin

Create and boot a QNX target

target_create

Build a new QNX OS 8.0 QEMU image in an isolated directory, boot it headless, and wait for root SSH access so you can create a ready-to-use QNX test target.

Instructions

Build a new QNX OS 8.0 QEMU image with mkqnximage in its own directory and boot it headless (KVM when available), then wait until root SSH works. Takes 20 s to 3 minutes. Fails with target_exists if the name is taken; a failed build or boot is cleaned up (QEMU stopped, directory removed, mkqnximage log kept). The SSH host keys mkqnximage generates are pinned. Extra mkqnximage options are restricted to: --aslr, --boot-size, --data-inodes, --data-size, --hostname, --perl, --python, --secpol, --secure-procfs, --sys-inodes, --sys-size, --time-servers, --tz, --valgrind (form --opt=value). The image runs dumper with sequential core names (unless --secpol is set), so crashing programs leave distinct core files.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

Name	Required	Description	Default
`ram`	No	Guest RAM, e.g. 1G or 2048M	1G
`arch`	No	Target CPU architecture	x86_64
`cpus`	No	Guest CPUs (1-4)
`name`	Yes	Target name such as 'tb' (lowercase letters, digits, '-', '_'); must be inside the server allowlist
`options`	No	Extra mkqnximage options, e.g. ['--hostname=dev1', '--data-size=512']
`boot_timeout_s`	No	Seconds to wait for SSH after boot

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 6, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses wall-clock duration, the exact error signal (target_exists), compensating cleanup on failure (QEMU stopped, directory removed, mkqnximage log retained), that generated SSH host keys are pinned, and the side effect that crashing programs leave distinct sequential core files. That is exactly the operational detail an agent needs before initiating a multi-minute mutation.

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?

Front-loaded with the primary action and duration, then error/cleanup behavior, then the option allowlist. The long option enumeration and the dumper-core trailing sentence are dense but each carries actionable constraint information, so little is wasted, though the final sentence is the least essential.

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?

For a long-running, side-effecting create-and-boot tool, everything an agent needs is present: runtime estimate, error mode, cleanup guarantees, security-relevant pinning, parameter allowlist, and runtime side effects. With annotations and an output schema already present, no meaningful gap remains.

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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: name is constrained by prior existence (target_exists) and by a server allowlist, and options is restricted to an explicit enumerated allowlist in --opt=value form, with the note that --secpol suppresses the sequential core naming. This is nontrivial constraint information beyond the schema's example array.

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?

States a concrete compound verb and resource: builds a QNX OS 8.0 QEMU image with mkqnximage into its own directory and boots it headless, then waits for root SSH. That is far more specific than the title alone. It does not explicitly contrast with the sibling target_start (which presumably boots an existing target), so an agent must infer the create-vs-boot distinction.

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?

Gives clear operating context: typical duration of 20 s to 3 minutes, the target_exists failure when a name is already taken (implying target_list/name checking first), and cleanup semantics on failure. It never names an explicit alternative such as target_start or target_list, so there is context but no stated exclusions.

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