QNX Host MCP

qnx_operation_status

Reads an operation's bounded output and current state by operation ID, enabling safe status checks without using PIDs or file paths.

Instructions

Read the bounded output and current state of an operation created by this server. Accepts an operation ID, never a PID or path.

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": {
      "operationId": "<operationId>"
    },
    "name": "qnx_operation_status"
  }
}

Input Schema

Name	Required	Description	Default
`operationId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden and only partly does: 'bounded output' hints that returned output is capped, and 'never a PID or path' heads off a common misuse. It omits that this is a non-mutating read, what happens for an unknown/expired/forgotten operation ID, and whether the call blocks or polls.

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

Conciseness5/5

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

Two short sentences, front-loaded with what is returned, followed by the argument constraint. No filler and nothing repeated from the schema.

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

Completeness4/5

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

This is a single-parameter read tool with no output schema, so the description only needs to characterize the return and the argument, which it does in one clause each. The remaining gap is error/lifecycle behavior for stale operation IDs, a minor omission for a tool this simple.

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 0%, so the description must compensate, and it does: it names the parameter concept (operation ID) and rules out the two most likely wrong values, a PID or a filesystem path. It still doesn't say where the ID comes from or that it's the 32-hex string the pattern requires, but the semantic guidance is well beyond the bare schema.

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 specific verb and resource (read output + current state) and scopes it to operations 'created by this server', which separates it from qnx_operation_cancel and the image/compile tools. It never names a sibling explicitly, so differentiation is implicit rather than stated.

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

Usage Guidelines3/5

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

Usage is only implied: an agent can infer this is for polling an operation after qnx_compile_c or qnx_image_start kicks one off. There is no explicit statement about when to poll, whether calling repeatedly is expected, or when to use qnx_operation_cancel instead.

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

Deploy Server