qnx-mcp

Overview Schema Source Related Servers Discussions Admin

Analyse a QNX crash

get_crash

Read-onlyIdempotent

Fetch and verify a crashed run's core file against the deployed binary, then open it with gdb MI to return structured backtraces, faulting/user frames, thread stacks, and signal details.

Instructions

Fetch the core file of a crashed run (size and SHA-256 verified), check that it belongs to the exact binary that was deployed (GNU build ID or the content-addressed path in the core's notes; error core_mismatch otherwise), open it with the SDP's gdb in MI mode and return a structured backtrace: faulting_frame (where the signal happened) and user_frame (innermost frame in your sources), frames with function, file, line, address, library, locals and source lines, every thread's stack, signal, si_code, fault address (0x0 = NULL dereference), the faulting instruction and a one-line summary. Default: the newest crashed run on the target; or pass run_id, or core_path plus binary for any other core. For a run of a program that was already on the target (remote_binary), pass run_id plus binary, the host path of its unstripped build (accepted when its build ID matches the core's, or when it is the same file).

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

Input Schema

Name	Required	Description
`binary`	No	Host path of the unstripped executable matching core_path, or the build of a remote_binary run's program
`run_id`	No	run_id returned by deploy_and_run or run_start
`target`	Yes	Target name such as 'tb' (lowercase letters, digits, '-', '_'); must be inside the server allowlist
`core_path`	No	Core file on the target, for a core not produced through qnx-mcp
`max_frames`	No
`max_core_mb`	No	Refuse larger cores (also applies after decompression)
`locals_frames`	No	Collect local variables for this many innermost frames

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 already cover read-only, idempotent, non-destructive behavior, but the description adds substantial operational context beyond them: size and SHA-256 verification, build-ID/content-addressed-path validation, the core_mismatch error, refusal of oversized cores, and decompression accounting. It also discloses the gdb MI mechanism and that binary is only accepted when its build ID matches the core.

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 and verification, then invocation modes, then the remote_binary caveat — logically ordered, zero filler sentences. The long enumeration of returned backtrace fields is somewhat redundant given an output schema exists, which slightly inflates length.

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 seven-parameter tool with an output schema, the description covers what an agent must know before calling: default resolution, all three argument combinations, the mismatch failure mode, and size limits. Return-value detail is carried by the output schema, so nothing essential 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 high (86%), so baseline is 3, but the description adds real relational meaning: which parameters pair together (core_path with binary; run_id with binary for remote_binary runs) and the acceptance rule for binary. It says nothing about max_frames or locals_frames beyond the schema, so it does not fully cover the parameter set.

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?

States a specific verb chain and resource: fetch the core of a crashed run, verify it against the deployed binary, open it under SDP gdb in MI mode, and return a structured backtrace. It names the exact artifacts returned (faulting_frame, user_frame, per-thread stacks, signal, si_code, fault address), which distinguishes it clearly from siblings like logs or run_poll.

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 explicit invocation modes: default is the newest crashed run on the target, or pass run_id, or core_path plus binary for a foreign core, and run_id plus binary for a remote_binary run. It does not name alternate sibling tools (e.g. logs, processes) for competing needs, so the routing is complete for argument selection but not for tool selection.

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