qnx-mcp

Overview Schema Source Related Servers Discussions Admin

Start a long-running program on a QNX target

run_start

Destructive

Starts a program in the background on a QNX target, returns immediately, and redirects stdout/stderr to capped files so long-running tasks can be polled and stopped.

Instructions

Like deploy_and_run, but the program runs in the background (its own session on the target) so the call returns at once. Output goes to files on the target (capped per stream); read it with run_poll using offsets, end it with run_stop. timeout_s is a hard limit on its lifetime. processes and logs keep working while it runs. Crashes leave a core for get_crash(run_id). remote_binary (a target path, with no binary) starts a program that is installed on the target, for example to restart a service (same rules as deploy_and_run: below /tmp or /data, never a shell or a system program).

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": "run_start"
  }
}

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
`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 the stdout and stderr files
`remote_binary`	No	Instead of binary: absolute path of an executable already on the target

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 (destructiveHint=true, idempotentHint=false): it discloses that the program gets its own session, that output lands in per-stream capped files rather than returning inline, that timeout_s is a hard lifetime kill, and that crashes leave a core. The remote_binary safety rules (below /tmp or /data, never a shell or system program) are genuinely non-obvious behavioral constraints. Only the process-level consequences of the destructive timeout kill are left implicit.

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 deploy_and_run contrast so the reader learns the distinguishing trait first, and every clause carries information. It is a single dense paragraph with stacked parentheticals, which costs some scannability but introduces no filler.

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 9-parameter launch tool with an output schema and full schema coverage, the description supplies everything the schema cannot: the background execution model, where output goes and how to retrieve it, how to stop it, timeout semantics, and crash recovery. An agent can invoke this and drive the follow-up lifecycle without consulting other tools' docs.

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: timeout_s is characterized as a hard limit on lifetime rather than a soft wait, remote_binary is framed as the alternative to binary for programs already installed on the target, and its path restrictions are stated where the schema only says 'absolute path of an executable already on the target.'

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 direct sibling-relative definition: 'Like deploy_and_run, but the program runs in the background (its own session on the target) so the call returns at once.' That gives a specific verb (start a program), the resource (a QNX target process), and the exact axis on which it differs from the nearest sibling.

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?

Explicitly routes the agent through the whole lifecycle: read output with run_poll using offsets, terminate with run_stop, fetch a core with get_crash(run_id). The deploy_and_run contrast states the condition that selects this tool (non-blocking background execution). No exclusions are missing that matter.

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