Skip to main content
Glama

Get run

get_run
Read-onlyIdempotent

Status of a run: phase, whether it is finished, credits so far, the customer-visible activity, the error with a hint when it failed, and signed URLs for the video and other artifacts (GET only, valid ~15 minutes; call again for fresh ones).

Input Schema

NameRequiredDescriptionDefault
run_idYesThe run to describe (from start_run or list_runs).

Output Schema

NameRequiredDescriptionDefault
modeYesrecord produces a video; check only verifies the guide.
errorNoPresent only when the run failed.
guideNoDisplay name of the guide that was recorded.
phaseYesCustomer-facing phase label (Queued, Preparing, Recording, Finishing, Completed, Failed, Paused).
stateYesMachine-readable state; done means the video is ready.
outputNoDevice settings the run recorded with (device, frame, backdrop).
run_idYes
attemptYesAttempt number; the recorder retries some failures itself.
activityYesCustomer-visible activity lines, oldest first, each prefixed with its time.
warningsYesThings that stayed on top of the page, or parts of it that could not load, during the walkthrough; fix the guide and run again.
artifactsYes
video_urlNoSigned download link for the video, valid about 15 minutes; null until the video is ready.
phase_noteYesOne line explaining the phase.
project_idYes
started_atNoISO 8601
is_terminalYestrue when nothing more will happen; stop polling.
completed_atNoISO 8601
output_labelYesHuman label of the output, e.g. Desktop or iPhone, Vertical 9:16.
video_secondsNoLength of the finished video.
credits_so_farYesCredits owed so far; 0 until the video completes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedOutput schema / properties / warnings / description
      Previous value: -"Things that stayed on top of the page during the walkthrough; fix the guide and run again."New value: +"Things that stayed on top of the page, or parts of it that could not load, during the walkthrough; fix the guide and run again."
    • changedOutput schema / properties / warnings / items / properties / code / description
      Previous value: -"page_furniture"New value: +"page_furniture, step_substituted or unreachable_host"
    • changedOutput schema / properties / warnings / items / properties / kind / enum
      Previous value: -[
      -  "cookie_banner",
      -  "chat_widget",
      -  "dialog"
      -]New value: +[
      +  "cookie_banner",
      +  "chat_widget",
      +  "dialog",
      +  "substitution",
      +  "unreachable_host"
      +]
    • changedOutput schema / properties / warnings / items / properties / when / enum
      Previous value: -[
      -  "start",
      -  "end"
      -]New value: +[
      +  "start",
      +  "during",
      +  "end"
      +]
  2. Changed1 schema field changed
    • removedOutput schema / properties / estimated_credits
      Removed value: -{
      -  "description": "Estimate made when the run started.",
      -  "type": [
      -    "number",
      -    "null"
      -  ]
      -}
  3. Changed1 schema field changed
    • changedOutput schema / properties / error / properties / code / description
      Previous value: -"Stable error code, e.g. login_gate_failed."New value: +"Stable error code, e.g. login_failed, step_failed."
  4. Changed2 schema fields changed
    • addedOutput schema / properties / warnings
      Added value: +{
      +  "description": "Things that stayed on top of the page during the walkthrough; fix the guide and run again.",
      +  "items": {
      +    "properties": {
      +      "code": {
      +        "description": "page_furniture",
      +        "type": "string"
      +      },
      +      "kind": {
      +        "enum": [
      +          "cookie_banner",
      +          "chat_widget",
      +          "dialog"
      +        ],
      +        "type": "string"
      +      },
      +      "message": {
      +        "type": "string"
      +      },
      +      "suggestion": {
      +        "description": "The guide line to add, e.g. If visible, click \"Accept all\".",
      +        "type": [
      +          "string",
      +          "null"
      +        ]
      +      },
      +      "when": {
      +        "description": "Seen from the first frame, or still there at the end.",
      +        "enum": [
      +          "start",
      +          "end"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "code",
      +      "kind",
      +      "when",
      +      "message"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "run_id",
      -  "project_id",
      -  "state",
      -  "mode",
      -  "phase",
      -  "phase_note",
      -  "is_terminal",
      -  "attempt",
      -  "credits_so_far",
      -  "output_label",
      -  "activity",
      -  "artifacts"
      -]New value: +[
      +  "run_id",
      +  "project_id",
      +  "state",
      +  "mode",
      +  "phase",
      +  "phase_note",
      +  "is_terminal",
      +  "attempt",
      +  "credits_so_far",
      +  "output_label",
      +  "activity",
      +  "warnings",
      +  "artifacts"
      +]
  5. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, closed-world, so the description's job is incremental and it delivers: signed URLs expire in ~15 minutes and must be re-fetched, and failures come back with an error plus hint. This expiry/caching trait is real context an agent cannot infer from annotations or schema.

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?

One sentence, front-loaded with the returned state fields before the artifact URL caveat. The enumeration is long but each item is information-dense rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, so return shape is largely covered, and annotations cover the safety profile; the description is still complete enough on the one behavior (URL expiry) that neither structured field captures. Missing only guidance about polling or behavior on nonexistent run_ids.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

A single parameter at 100% schema description coverage, and the schema already states provenance ('from start_run or list_runs'). The description adds no further semantics about run_id, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States the resource (a run) and enumerates exactly what is returned — phase, finished flag, credits consumed, customer-visible activity, failure error with hint, and signed artifact URLs. An agent knows precisely what this call yields, though it never explicitly contrasts itself with list_runs or start_run.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: the '(GET only, valid ~15 minutes; call again for fresh ones)' clause gives clear guidance for URL refreshes, but there is no when-to-use/when-not versus list_runs (bulk) or a polling cadence for in-progress runs.

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.