Skip to main content
Glama
Sign In
qnx-mcp

qnx-mcp

by NikhilGogu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Poll a background run

run_poll
Read-onlyIdempotent

Poll a server-started run's new stdout/stderr from byte offsets, optionally wait up to wait_s, and report running, finished with outcome/result, or lost after reboot.

Instructions

Read new output of a run_start run from byte offsets (pass back stdout_next and stderr_next) and its state: running, finished (with outcome and the final result) or lost (target rebooted). wait_s waits up to that long for new output or the end. Only runs started by this server are accessible.

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>",
      "run_id": "<run_id>"
    },
    "name": "run_poll"
  }
}

Input Schema

NameRequiredDescriptionDefault
max_kbNoMaximum KiB returned per stream
run_idYesrun_id returned by run_start (r- and 12 hex digits)
targetYesTarget name such as 'tb' (lowercase letters, digits, '-', '_'); must be inside the server allowlist
wait_sNo
stderr_offsetNo
stdout_offsetNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds genuine behavioral value on top: the running/finished/lost state machine, the meaning of 'finished' (outcome plus final result), long-poll semantics for wait_s, and the access restriction to server-owned runs. It does not mention that per-stream output is capped by max_kb, which is the one behavioral gap.

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-loads the core action, then the state enumeration, then the wait behavior, in three dense sentences with no filler. The middle state list is slightly run-on but every clause carries information an agent needs.

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?

With an output schema present, return-shape details needn't be covered, and the description handles the non-obvious parts: state meanings, offset round-tripping, blocking behavior, and access scope. Missing only the max_kb truncation/backpressure note for a tool with a 1024 KiB cap.

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 50% (run_id and target documented; stdout_offset, stderr_offset, wait_s, max_kb not), so the description has to compensate and largely does: it explains that offsets are byte positions and that wait_s blocks up to that long for output or termination. max_kb is left unexplained, and the 'stdout_next/stderr_next' wording differs from the input field names, which could momentarily confuse an agent about what to pass back.

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 and resource ('Read new output of a run_start run from byte offsets') and enumerates the three states it reports (running, finished with outcome/result, lost due to reboot). That vocabulary is clearly distinct from siblings like run_start, run_stop, logs, and target_status.

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?

Implies the incremental-polling workflow by telling the caller to pass back stdout_next and stderr_next, and adds a real precondition ('Only runs started by this server are accessible'). It stops short of explicitly naming when to prefer logs or target_status instead, so it is clear context without full alternative routing.

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

Deploy Server

Other Tools