Skip to main content
Glama

get_result

Fetches the verdict and evidence for a Netdryrun dry run started with start_run; if status is running, wait poll_after_s seconds and call again.

Instructions

The result of a run started with start_run. While status is running there is no verdict: wait poll_after_s seconds and call again (a dry run takes about 60-120 s). Once it has finished, the result is exactly dry_run's, with its run_id: act on status and the verdict as for dry_run. An unknown run_id is status error. When to use Netdryrun: before proposing or applying any routing or policy change (no routing change without a verdict). Ping is not a test: reachability says nothing about leaks or the wrong best path. A dry run takes about 60–120 s. Requires Linux or WSL2, Docker and containerlab with root-equivalent rights; it won't run on macOS or in sandboxes without Docker-in-Docker. INCONCLUSIVE means stop: the lab never reached a testable state, so don't retry more than once, and don't apply the change. Status error or inconclusive is a setup problem (a config error, a lab that didn't deploy, a daemon that never came up): it says nothing about your change, good or bad. Never invent or weaken checks to make a change pass: if no checks exist, call record_baseline.

Input Schema

NameRequiredDescriptionDefault
run_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.3

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it explains polling behavior, typical dry-run duration, unknown run_id error handling, setup-problem statuses, and environment requirements including Linux/WSL2, Docker, and containerlab privileges. It also warns against inventing or weakening checks.

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?

The description is front-loaded with the core purpose and polling behavior, and most sentences add useful operational guidance. However, it repeats the 60–120 s dry-run duration and includes broader Netdryrun, ping, and record_baseline guidance that is only partly specific to get_result.

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?

Because an output schema exists, the description need not explain return fields in detail. It still covers the essential context for an async result tool: polling cadence, terminal statuses, error and inconclusive meanings, environment constraints, and when to act on the verdict.

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 description coverage is 0%, so the description must add meaning for the single required run_id parameter. It does this by tying run_id to a run started with start_run and by stating that an unknown run_id yields status error, though it does not describe the run_id format.

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 opening sentence identifies the resource (the result of a run) and its origin (start_run), and the body distinguishes polling from a finished verdict and from dry_run's result. An agent can route among start_run, dry_run, and get_result without needing to inspect other schemas.

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?

It explicitly says to wait poll_after_s seconds and call again while status is running, and it states when Netdryrun should be used before routing or policy changes. It also gives clear when-not guidance: ping is not a test, and INCONCLUSIVE means stop rather than retry repeatedly or apply the change.

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