Symbioza

Collect a finished job's results

getArtifact

Read-onlyIdempotent

Results of a finished job: your workload's exitCode, the artifact manifest (path/sha256/status, with time-boxed download links when offsite storage is configured), deliveryComplete + deliveryDetail, priceUsd (the charge, the same number getStatus returns) with priceStatus ("provisional" while the provider's bill is unconfirmed, "final" once reconciled or when nothing was charged; never above budgetUsd), checkpoint. Each download link is for the user's browser, where a video, image, PDF or text file opens directly and anything else downloads. Your own environment may not be able to fetch it: to inspect a file's contents, give the user the link and ask them to attach the downloaded file to the conversation. A link you cannot reach is not a missing file: deliveryComplete and the manifest say what arrived. The charge shown after completion may change while billing is reconciled. Your total charge for the job, including retries, will not exceed your approved budget. Status and artifact reads return text only and draw no card: a job's card is the one on its submitJob result (and the price card on estimateExecution), and that card keeps itself current while the job runs.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`authKey`	No	Usually omit this. The customer door — the OAuth-signed-in HTTPS connector at https://symbioza.dev/mcp — authenticates the session itself, so no key is passed per call. Only a self-hosted or test transport passes a key here.
`executionId`	Yes

Output Schema

TableJSON Schema

Name	Required	Description
`reason`	No
`storage`	No
`exitCode`	No
`priceUsd`	No
`artifacts`	No	The delivery manifest: files under /workspace/artifacts/
`available`	Yes
`checkpoint`	No
`executionId`	Yes
`priceStatus`	No
`transferOut`	No
`workloadLog`	No	The tail of your workload's own stdout/stderr
`deliveryDetail`	No
`executedAttempt`	No	The attempt that ran your command (0-based); null when no attempt ran it
`deliveryComplete`	No
`priceStatusReason`	No	reconciled \| awaiting provider confirmation \| nothing was charged
`recoveryAssessment`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 7, 2026

addedOutput schema / properties / executedAttempt

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "properties": {
+        "exitCode": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "exitedAtMs": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "index": {
+          "type": "number"
+        },
+        "startedAtMs": {
+          "anyOf": [
+            {
+              "type": "number"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        }
+      },
+      "required": [
+        "index",
+        "exitCode",
+        "startedAtMs",
+        "exitedAtMs"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The attempt that ran your command (0-based); null when no attempt ran it"
+}

addedOutput schema / properties / recoveryAssessment

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": {},
+      "properties": {
+        "automatic": {
+          "type": "boolean"
+        },
+        "blocker": {
+          "anyOf": [
+            {
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "dependency_access | constraint | budget | capacity | checkpoint | cleanup_unconfirmed | unknown; null unless blocked"
+        },
+        "mode": {
+          "description": "none | resume | restart | blocked | user_stopped",
+          "type": "string"
+        },
+        "needsNewApproval": {
+          "type": "boolean"
+        },
+        "nextAction": {
+          "type": "string"
+        },
+        "preserved": {
+          "additionalProperties": {},
+          "properties": {
+            "checkpoint": {
+              "type": "boolean"
+            },
+            "files": {
+              "type": "number"
+            },
+            "verifiedFiles": {
+              "type": "number"
+            }
+          },
+          "required": [
+            "files",
+            "verifiedFiles",
+            "checkpoint"
+          ],
+          "type": "object"
+        },
+        "reason": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "mode",
+        "blocker",
+        "reason",
+        "nextAction",
+        "preserved",
+        "needsNewApproval",
+        "automatic"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedSep 29, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Goes well beyond the annotations: time-boxed download links, links intended for the user's browser, the caveat that the agent's own environment may not be able to fetch them, that a fetch failure is not a missing file (deliveryComplete/manifest are authoritative), that the charge may change during reconciliation, that retries cannot push the total above budgetUsd, and that no card is drawn on this read.

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

Conciseness3/5

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

Front-loaded correctly with the payload contents, and most sentences carry operational weight, but it is one dense paragraph that runs long and repeats the budget ceiling twice ('never above budgetUsd' then 'will not exceed your approved budget') plus restates the card behavior in two sentences.

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?

An output schema exists, so explaining return fields is technically redundant, yet the description's real value — how to handle browser-only download links and why the charge can move — is not derivable from the schema or annotations. Given moderate complexity and full annotation coverage, the definition is complete enough to call correctly, with only the executionId provenance left thin.

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

Parameters2/5

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

Schema coverage is 50%: authKey is documented in the schema but executionId has no description anywhere. The description never explains the identifier's meaning, format, or where to obtain it (only indirectly referencing the submitJob result), so for a tool keyed on a single required ID it fails to compensate for the coverage gap.

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 resource and verb-equivalent ('Results of a finished job') and enumerates the payload: exitCode, artifact manifest with path/sha256/status, deliveryComplete, priceUsd, checkpoint. It also distinguishes itself from the sibling getStatus by noting priceUsd is 'the same number getStatus returns', so an agent can route between the two.

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 by 'a finished job' (call after completion, not mid-run) and it gives concrete operational guidance for download links. However, it never explicitly states when to choose this over getStatus or inspectRun, nor what prerequisite state the job must be in, leaving the sibling choice to inference.

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

All Symbioza tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.