qnx-mcp

Overview Schema Source Related Servers Discussions Admin

Deploy and run on a QNX target

deploy_and_run

Destructive

Deploy a host-built QNX executable to the target and run it once with captured output, timeout, and crash core retrieval. Use for short-lived programs; supports running pre-installed target binaries too.

Instructions

Snapshot a host-built QNX executable, copy it to the target (content-addressed under /tmp/qnx-mcp/apps, SHA-256 verified on the target) and run it once via the qnx-mcp-run helper: own process group, stdin /dev/null, stdout and stderr captured separately (capped, truncation reported), wall-clock timeout; when the program ends the rest of its process group is killed too. Returns outcome (exited | crashed | killed | timeout | stopped | exec_failed), exit_code or signal_name, and for crashes the exact core_path obtained from dumper (DCMD_DUMPER_NOTIFYEVENT pulse, then DCMD_DUMPER_GETPATH), moved into the run's own directory. Checks the ELF arch and loader first. Arguments are an array, never interpreted by a shell. For long-running programs use run_start. To run a program that is already installed on the target, pass remote_binary (a target path) and no binary: an executable regular file below /tmp or /data (QNX_MCP_REMOTE_BINARY_ROOTS) and outside /tmp/qnx-mcp, never a shell or anything in /proc/boot, /bin, /sbin, /usr or /system (checked by real path on the target). get_crash then needs binary= to symbolise a crash.

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": {
      "target": "<target>"
    },
    "name": "deploy_and_run"
  }
}

Input Schema

Name	Required	Description
`cwd`	No	Working directory on the target
`env`	No	Extra environment variables for the program
`args`	No	Program arguments, one element per argv entry
`binary`	No	Host path of the executable, usually build.artifacts[].path
`target`	Yes	Target name such as 'tb' (lowercase letters, digits, '-', '_'); must be inside the server allowlist
`timeout_s`	No	Kill the program after this many seconds
`core_wait_s`	No	How long to wait for dumper to finish a core
`max_output_kb`	No	Cap for each of stdout and stderr
`remote_binary`	No	Instead of binary: absolute path of an executable already on the target below /tmp or /data, e.g. /data/opt/svc/sensord

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations: content-addressed storage under /tmp/qnx-mcp/apps with SHA-256 verification on target, isolated process group killed on exit, stdin /dev/null, separately captured and capped streams with truncation reported, wall-clock timeout, ELF arch/loader precheck, and args never shell-interpreted. For the remote_binary path it defines the permitted roots and the forbidden paths with real-path checking, which is rare and valuable. It stops short of saying whether the deployed snapshot persists after the run (the destructiveHint implies leftover state), so it is not exhaustive.

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 core action in the first clause, and nearly every sentence carries operational information. However, it is a single dense paragraph with heavily nested parentheticals (dumper internals, pulse/GETPATH details, path allowlists), which makes it harder to scan than it needs to be; splitting the mode rules and crash details into separate sentences would cost nothing.

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 nine-parameter mutation tool with an output schema, the description covers the full lifecycle: preconditions (ELF arch/loader check, target allowlist), runtime constraints (timeout, output caps, process group kill), result vocabulary and crash core retrieval, and the downstream symbolisation step. Nothing an agent needs in order to call it correctly or interpret a failure is missing.

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 the schema already documents all nine parameters. The description still adds meaning the schema does not: args are one element per argv entry and are never shell-interpreted, and binary vs remote_binary are mutually exclusive modes with restrictions on what remote_binary may point at. That is genuine added semantics above baseline 3.

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?

Opens with a specific verb+resource+scope: snapshot a host-built QNX executable, copy it to the target, and execute it once. It explicitly separates itself from the long-running sibling (run_start) and names the follow-up tool (get_crash), so an agent can pick it without opening any schema.

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

Usage Guidelines5/5

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

States when to use it (one-shot program), when not to ('For long-running programs use run_start'), the alternate mode (pass remote_binary and no binary for an already-installed program), and the follow-up prerequisite ('get_crash then needs binary=<host path of its unstripped build>'). Conditions select the right sibling and the right invocation mode unambiguously.

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