native-agent-router
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NAR_HOME | No | Home directory for NAR; defaults to ~/.native-agent-router. Used to locate agents.json. | |
| ZCODE_BIN | No | Path to the ZCode binary (zcode.cjs), used for ZCode adapter discovery. | |
| NAR_CONFIG | No | Path to the NAR configuration file. Used when the --config flag is not provided. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| agentsA | List configured worker agents and their capabilities (adapter type, transport, native session resume support, usage accounting quality) plus per-agent SCORE STATS (avg_score, success_rate, repair_rate, out_of_scope_rate, blocked_rate, avg_tokens, median_duration_sec, last_tasks). Use the stats to route work: high-score agents for hard units, cheaper/lower-score agents for well-specified mechanical units. Use this before run() to pick a valid agent_id. |
| runA | Submit a complete work unit to a worker agent and return its task_id. Requirements:
Returns a snapshot dict with ok/status/code. A run() success only means SUBMITTED, not done — follow with wait()/inspect(). |
| waitA | Bounded blocking wait for a task to reach a terminal or blocked state. Does not busy-poll. Returns the snapshot dict; if it still runs when the timeout expires, wait_timed_out=true — call again later. 'submitted'/'running' is NOT completion; only status succeeded/failed/blocked/cancelled/interrupted is. |
| inspectA | Read task details on demand (logs/diffs stay on disk; read slices here). what: status | summary | diff | verify | log | raw | usage | diagnose.
|
| cancelA | Request cancellation and report whether the stop was CONFIRMED by the native runtime (confirmed=true only on an observed terminal/exit). A cancel request alone is not a stop. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 5 tools
Each tool covers a distinct lifecycle stage: agents discovers workers, run submits a unit of work, wait blocks for completion, inspect reads task details, and cancel aborts. There is no meaningful overlap or ambiguity between them.
The verb-style names run, wait, inspect, and cancel are clear and consistently formatted. 'agents' is a minor deviation since it is a noun command rather than a verb_noun action like list_agents, but the pattern is still easy to predict.
Five tools is well-scoped for the server's purpose: agent discovery, task submission, waiting, inspection, and cancellation. Each tool has a clear role and none feel redundant.
The core agent-routing and task lifecycle is well covered: discover agents, submit tasks, wait, inspect, and cancel. A minor gap is the lack of a task-listing or search tool if a task_id is lost, but this does not prevent normal workflows.