Skip to main content
Glama

Runs: get

runs_get
Read-only

Reads one neonloops run: its status and phase (queued, claiming, running, awaiting-approval, stopped, failed or done), timing, price, and each step's status, input and output so far, up to 500 steps. A step in a loop appears once per iteration, told apart by loopPath. Inputs come as a byte size and a 200-character preview unless include_inputs is true, and each output is cut at 8 KB (outputTruncated says so). The run's priceUsd is its stored price, null while pricePending. A value a Start marks sensitive reads "Hidden from viewers" unless the token may read documents. Use it after runs_test_draft, or to open a run that runs_list or approvals_list shows. Cancelling a run cannot be undone, so it is deliberately left to a person, in the app or on the full connection (/api/mcp/full).

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

Input Schema

NameRequiredDescriptionDefault
run_idYesThe run to read; runs_list gives the ids, and runs_test_draft returns the id of a test run.
include_inputsNoDefault false: the run's inputs and each step's input come back as a byte size and a preview. True returns them in full, which for an app-triggered run can be tens of KB.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / include_inputs / description
      Previous value: -"Default false: `inputs` (run-level) and `input` (per node) come back as `{bytes, preview}`, never the full value. Pass true to get them in full — the trigger payload of an app-triggered run can be tens of KB."New value: +"Default false: the run's inputs and each step's input come back as a byte size and a preview. True returns them in full, which for an app-triggered run can be tens of KB."
    • addedInput schema / properties / run_id / description
      Added value: +"The run to read; runs_list gives the ids, and runs_test_draft returns the id of a test run."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and non-destructive, but the description adds substantial context the annotations cannot: a 500-step cap, per-iteration step duplication keyed by loopPath, input previews capped at 200 characters with a byte size, outputs truncated at 8 KB with an outputTruncated flag, priceUsd being null while pricePending, and sensitive Start values being hidden unless the token may read documents. These are exactly the caveats an agent needs to interpret the payload correctly.

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?

Purpose and returned fields are front-loaded, then caveats, then usage routing — a sensible order. It is dense and long for a two-parameter read tool, and the sensitive-value sentence is a bit compressed, but no sentence is filler.

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?

There is no output schema, so the description must carry return-shape burden, and it does: field inventory, phase enum, truncation markers, null-price semantics, and visibility rules. Combined with a fully documented two-parameter schema and read-only annotations, an agent has everything needed to call and interpret it.

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 100%, so the baseline is 3, but the description still adds meaning: include_inputs is explained in terms of concrete consequences (full inputs can be tens of KB for an app-triggered run) and the default preview size of 200 characters. It does not restate run_id's UUID format, which the schema already handles.

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 ("Reads one neonloops run") and then enumerates exactly what comes back: status and phase with the full enum of phase values, timing, price, and per-step status/input/output. The loopPath note and the step cap make it unmistakable which tool returns run detail versus runs_list.

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 entry points: "Use it after runs_test_draft, or to open a run that runs_list or approvals_list shows," naming the three sibling tools that produce a run_id. It also names an exclusion — cancelling a run is deliberately not offered here and lives in the app or on the full connection — so an agent knows what this tool will not do.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources