qnx-mcp

Overview Schema Source Related Servers Discussions Admin

Build for QNX

build

Destructive

Compile QNX SDP 8.0 projects on the host with automatic CMake, Make, or qcc selection, returning diagnostics and deployable artifacts.

Instructions

Compile on the build host with the QNX SDP 8.0 toolchain. system=auto picks cmake (CMakeLists.txt), make (Makefile) or qcc (plain sources). make and cmake run the project's own build files, which can execute any command: only build trees you trust. qcc mode builds the given sources (default: every .c/.cpp in path) with -g -O0 -Wall unless cflags is set. Returns diagnostics[] with file, line, column, severity, message (gcc JSON diagnostics in qcc mode, parsed text for make/cmake), linker errors, and artifacts[] with path, arch, build_id and debug_info for deploy_and_run. ok=false with error.code build_failed when compilation fails.

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": {
      "path": "<path>"
    },
    "name": "build"
  }
}

Input Schema

Name	Required	Description	Default
`arch`	No	Target architecture; must match the target you deploy to	x86_64
`path`	Yes	Host path: project directory or a single source file
`cflags`	No	Compiler flags; qcc default is ['-g','-O0','-Wall']
`output`	No	qcc mode: output executable path (default: first source's stem inside path)
`system`	No	Build driver	auto
`ldflags`	No	qcc mode: linker flags/libraries, e.g. ['-lsocket']
`sources`	No	qcc mode: source files (relative to path or absolute)
`make_args`	No	Extra make or cmake --build arguments
`timeout_s`	No

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

Behavior5/5

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

Annotations flag destructiveHint=true, but the description supplies the reason: make and cmake run project build files that 'can execute any command,' a concrete disclosure of arbitrary code execution risk. It also documents qcc's default flags and source globbing, the ok=false/build_failed error code, and the diagnostic and artifact payloads, which is substantial behavior beyond what the annotations convey.

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?

Purpose and the trust warning are front-loaded, and every sentence carries real information. The middle sentences are densely packed with multiple facts each, which makes the block harder to scan than it needs to be, but no sentence is 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 nine-parameter, destructive build tool, the description covers driver selection, source and flag defaults, failure signaling, and the artifact handoff to deploy_and_run. Even though an output schema exists, the return summary is accurate and leaves no obvious question about how to invoke the tool correctly.

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 89%, so the schema carries most parameter meaning, but the description adds value the schema does not: default source discovery in qcc mode ('every *.c/*.cpp in path') and the -g -O0 -Wall default when cflags is unset. Minor gaps remain, such as the timeout_s parameter being entirely unaddressed in the description.

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?

The description opens with a specific verb and resource ('Compile on the build host with the QNX SDP 8.0 toolchain') and immediately breaks the tool into its three drivers (cmake, make, qcc) with their selection rules. That scope, plus the pointer that artifacts feed deploy_and_run, clearly separates it from siblings like run_start and target_start.

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?

It explains how system=auto chooses a driver and warns that make/cmake execute the project's own build files, so only trusted trees should be used. It implies the build-before-deploy workflow by naming deploy_and_run as the consumer of artifacts, but it never states explicit when-not-to-use conditions or names an alternative build path.

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