aziel-runtime

List QNM rollup nodes

mesh_nodes

Read-onlyIdempotent

List the QNM node roster with presence classes and 5-minute TTL after mesh_status. Returns current node IDs, not suite totals or scores.

Instructions

List the QNM node roster (node_id + presence + 5-minute TTL) — not suite totals. Use this when you need the current node list after mesh_status. Do not use it for suite counts without the roster, or mutating presence; use mesh_status, mesh_join, or mesh_leave instead. No scores. No leaderboard. Views/MCP/downloads do not enter QNM-S. Returns node roster with presence classes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`code`	No	FragGate or fabric code when present: FG-OK, FG-HALLUC-TOOL, FG-STUB, FG-LOCAL-ONLY, FG-UNKNOWN-OP, FG-GATE-REFUSE, FG-LAMB-REFUSE, or a module refuse such as MESH-* / AKM-*.
`door`	No	Door name. The public door is fraggate.
`ran_in`	No	Execution locale (for example aziel-runtime) when present.
`result`	No	FragGate body: ok, code, door, slug, op, engine_digest, ran_in, provenance, refusal, limitations, receipt, plus the engine result. Unknown names refuse FG-HALLUC-TOOL; stubs refuse FG-STUB.
`status`	No	HTTP-like status when present on wrappers (200 ok; 400+ error / refuse).
`display`	No	Human-facing envelope. Show title and summary, then take the next input.
`receipt`	No	Optional receipt, ledger tip, or TemporalLock/ForgeReceipts exit when the door stamped one.
`refusal`	No	Explicit refuse object, code, or message when the door or engine refused.
`engine_op`	No	Resolved engine op when present (often inside result).
`ledger_tip`	No	Ask/refuse ledger tip when the door stamped one.
`provenance`	No	Provenance / input packet when the pipeline attached one.
`session_id`	No	Raw session id when session plumbing was used. Hidden unless the user asked for the chain.
`engine_slug`	No	Resolved engine slug when present (often inside result).
`limitations`	No	Capability limitations or Remain-OFF notes when present.
`engine_digest`	No	64-hex engine_digest when a true in-process engine ran (often inside result).

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.6.2Sep 12, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare the safe read-only, idempotent profile, so the bar is lower. The description still adds real behavioral context: a 5-minute TTL and presence classes on nodes, plus scope exclusions. Minor deduction because some clauses ("Views/MCP/downloads do not enter QNM-S") are cryptic rather than clarifying.

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 purpose and the "not suite totals" qualifier before usage and exclusions. Mostly second sentence earns its place, but the terse fragments "No scores. No leaderboard." are slightly redundant noise that dilute the signal.

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?

With an output schema present, return values need no explanation, and annotations carry the safety profile. The description supplies the purpose, usage routing, and scope constraints an agent needs to invoke this zero-argument 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?

Zero parameters, which is the baseline-4 case. The schema itself explains "No arguments. Send {}." and the description correctly adds nothing about parameters, so there is no gap to compensate for.

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 ("List the QNM node roster") and enumerates the returned fields (node_id + presence + TTL) while explicitly excluding suite totals. It names the siblings it is not (mesh_status, mesh_join, mesh_leave), so an agent can distinguish it without opening any schema.

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?

Gives explicit when-to-use ("after mesh_status", when you need the current node list) and when-not-to-use with named alternatives ("use mesh_status, mesh_join, or mesh_leave instead"). This is the full when/when-not/alternatives pattern.

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