Skip to main content
Glama

Get run status and result

get_run
Read-onlyIdempotent

Read an existing run in the authenticated workspace: status, result, artifacts and cost, optionally waiting for completion. Requires only its run_id; no idempotency key. Read-only and free: never starts or retries execution, changes approvals or creates a charge. Returns the same run_id in every state, including success, failure and awaiting approval.

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": "get_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
run_idYesThe run_id returned by run_tool.
wait_secondsNoSeconds to wait for a terminal result. Defaults to 50; 0 returns the current state immediately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, yet the description still adds substantive behavior: no idempotency key needed, no charge incurred, no approval changes, optional blocking wait, and a stable run_id across success, failure and awaiting-approval states. The last point is valuable because it tells the agent polling will not lose the run handle on failure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with what is read and what comes back, then constraints, then the guarantee about run_id. Every clause carries information; nothing is padding or a restatement of the title.

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 no output schema, the description carries the return-value burden and does so by naming the payload fields (status, result, artifacts, cost) and their behavior across states. For a two-parameter read tool with full annotation coverage, nothing needed to invoke or interpret it is missing.

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 baseline is 3, but the description adds meaning: run_id alone is sufficient and no idempotency key is required, and waiting is framed as optional rather than mandatory. It does not restate the 0-120 second range, which the schema already covers.

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?

Opens with a specific verb+resource ('Read an existing run') and immediately enumerates what is returned (status, result, artifacts, cost), plus the optional wait behavior. It is clearly separable from the sibling run_tool because it states it 'never starts or retries execution'.

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?

The description gives clear context for use: pass a run_id from run_tool, optionally block until terminal, and it explicitly excludes mutation/retry/approval actions. It stops short of naming a sibling alternative for starting work, but the negative routing ('never starts or retries') effectively points an agent to run_tool.

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.