Skip to main content
Glama

Get scan status

get_scan_status
Read-only

Poll a scan and discover its artifacts. Use for "is my scan done?", "where is my scan?", or "what can I fetch?".

The reply includes the scan's state and every artifact's availability and
dashboard link. Use reason for workflow decisions:

* not_complete: keep polling.
* awaiting_approval: fetch get_artifact(security_requirements), present
  the requirements, then record the user's decision with approve_scan_phase.
* ok: the scan completed. Read get_security_posture and fetch reports or
  diagrams with get_artifact.
* scan_terminated, scan_failed, no_analysis, or action_required: stop
  polling. The scan was cancelled or skipped, failed, has yet to start,
  or awaits user action, respectively. Follow next_steps for action_required.

A scan takes up to 1 hour. Poll about every 10 minutes while reason is
not_complete.

Relay progress_summary, which the server composes from the progress
fields. When paraphrasing, describe the running stage and sub-step.
scan_phase='2/3' means the second of three stages. Do not turn it into a
percentage: stages have different lengths. job_phase counts sub-steps
within one stage, restarts at each stage, and is shorter in an incremental
scan; scan_phase counts stages across the scan.

Report what is running. Do not invent an ETA: stage durations are
unrecorded, and a paused scan depends on a person's decision.

During an approval pause, scan_phase, scan_stage, job_phase, and job_step
are absent. The message identifies what needs approval. The scan is
paused, so report that state. Do not fill in a position from an earlier poll.

An earlier pinned scan_id returns that scan's lifecycle and artifacts,
with position fields absent. Trent composes a position for the current scan.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_scan_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
scan_idNoPin a scan generation. Omit for the latest scan when polling. An earlier scan returns its own lifecycle and artifacts, with position fields absent. Trent composes a live position for the current scan. A scan_id from another project returns an error.
project_idNoProject ID (provide either project_id or project_name)
project_nameNoProject name (provide either project_id or project_name)

Output Schema

NameRequiredDescriptionDefault
errorNoTrue when the call itself failed. False for successful calls, including a scan still running, an already approved plan, or a repository classified as non-agentic. The reason field describes these workflow states.
reasonNoA stable snake_case code from the allowed set. Present on every error and on successful calls that carry a workflow state.
statusNoCurrent scan status: NO_ANALYSIS, CREATED, PENDING, WAITING, BACKPRESSURED, DRAFT, GENERATING_GOALS, GOALS_READY, RUNNING, AWAITING_APPROVAL, COMPLETED, FAILED, CANCELLED, or SKIPPED. An unrecognized value becomes UNKNOWN so polling can continue. Use reason for workflow decisions.
messageNoExactly one sentence written for the user. Never raw exception text or a backend error string, which may expose private details.
scan_idNoThe scan generation this status reflects.
job_stepNoWhat that sub-step is, in display words ('Mapping Architecture').
metadataNoCaller metadata, such as 'expiration_warning'. Substantive results have their own fields. Never includes exception or backend error text, which may expose private details.
artifactsNoEvery artifact the scan produces, each with artifact_id, kind (document, graph or structured), status, is_available, version, owner_phase, read_path, and dashboard ui_url. Fetch an available artifact with get_artifact(artifact_id=...). 'available' means readable now. reason and awaiting_approval describe an approval pause.
job_phaseNoSub-step within the current stage as an ordinal, such as '3/6'. Each stage restarts its count, and an incremental scan's stages have fewer sub-steps than a full scan's. Absent until a stage reports a sub-step, during an approval pause, and when the stage is not running.
last_scanNoTimestamp of the latest project update or scan.
next_stepsNoRecommended next actions based on current status.
project_idNoResolved Trent project identifier.
scan_phaseNoRunning stage as an ordinal, such as '1/3'. The denominator is the scan's fixed stage count. Use it to describe progress and reason for workflow decisions. Do not convert it to a percentage: stages have different lengths, so '2/3' does not mean two thirds done. Absent during an approval pause, on older single-stage projects, or for a pinned scan_id earlier than the project's latest scan.
scan_stageNoRunning stage name: understand, plan, or secure. Use it to describe progress and reason for workflow decisions. Absent during an approval pause, on older single-stage projects, or for a pinned scan_id earlier than the project's latest scan.
project_nameNoDisplay name of the Trent project.
schema_versionNoSchema version of the artifact manifest.
skipped_sourcesNoSources the latest scan skipped after a read failure, such as a findings file over the size limit. Its results exclude those sources. Present for the project's latest scan; absent for an earlier pinned scan_id. For the latest scan, absence means the scan reported no skipped source.
progress_summaryNoA sentence describing the scan's progress. Relay it to the user. It combines scan_phase, scan_stage, job_phase, and job_step, and describes uneven stage lengths and readable artifacts.
awaiting_approvalNoPresent while the scan pauses for the user's approve or reject decision. Contains stage_id, review_endpoint, and review_url, the app page where the user can also review. Fetch get_artifact(security_requirements), present the requirements, and call approve_scan_phase after the user decides.
latest_commit_shaNoCommit of the last completed scan, which Trent's current findings describe; never a running scan's. On a pinned scan_id, the commit that scan read, when it read one repository.
scan_repositoriesNoEach repository the described scan read, with repo_slug and commit_sha: the pinned scan on a scan_id read, otherwise the running scan. Absent until that scan has recorded its cloned commits.
running_commit_shaNoWhile a scan runs, the commit it reads, when it reads one repository. Absent until the running scan has recorded the commit it cloned.
retry_after_secondsNoWith reason rate_limited, how many seconds Trent asks the caller to wait.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedOutput schema / properties / artifacts / description
      Previous value: -"Every artifact the scan produces, each with artifact_id, status, is_available, version, owner_phase, read_path, and dashboard ui_url. Fetch an available artifact with get_artifact(artifact_id=...). 'available' means readable now. reason and awaiting_approval describe an approval pause."New value: +"Every artifact the scan produces, each with artifact_id, kind (document, graph or structured), status, is_available, version, owner_phase, read_path, and dashboard ui_url. Fetch an available artifact with get_artifact(artifact_id=...). 'available' means readable now. reason and awaiting_approval describe an approval pause."
    • addedOutput schema / properties / retry_after_seconds
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "With reason rate_limited, how many seconds Trent asks the caller to wait.",
      +  "title": "Retry After Seconds"
      +}
  2. Changed6 schema fields changed
    • addedOutput schema / $defs / ScanRepositoryCommit
      Added value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "commit_sha": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "The commit the scan read there.",
      +      "title": "Commit Sha"
      +    },
      +    "repo_slug": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ],
      +      "default": null,
      +      "description": "The repository, as owner/name.",
      +      "title": "Repo Slug"
      +    }
      +  },
      +  "title": "ScanRepositoryCommit",
      +  "type": "object"
      +}
    • changedOutput schema / properties / job_phase / description
      Previous value: -"Sub-step within the current stage as an ordinal, such as '3/6'. Each stage restarts its count. Absent until a stage reports a sub-step and during an approval pause."New value: +"Sub-step within the current stage as an ordinal, such as '3/6'. Each stage restarts its count, and an incremental scan's stages have fewer sub-steps than a full scan's. Absent until a stage reports a sub-step, during an approval pause, and when the stage is not running."
    • changedOutput schema / properties / latest_commit_sha / description
      Previous value: -"Commit SHA of the latest analysis. Trent's findings describe this commit."New value: +"Commit of the last completed scan, which Trent's current findings describe; never a running scan's. On a pinned scan_id, the commit that scan read, when it read one repository."
    • addedOutput schema / properties / running_commit_sha
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "While a scan runs, the commit it reads, when it reads one repository. Absent until the running scan has recorded the commit it cloned.",
      +  "title": "Running Commit Sha"
      +}
    • changedOutput schema / properties / scan_phase / description
      Previous value: -"Running stage as an ordinal, such as '1/3'. The denominator is the scan's fixed stage count. Use it to describe progress and reason for workflow decisions. Do not convert it to a percentage: secure declares seven sub-steps to plan's two, so '2/3' does not mean two thirds done. Absent during an approval pause, on older single-stage projects, or for a pinned scan_id earlier than the project's latest scan."New value: +"Running stage as an ordinal, such as '1/3'. The denominator is the scan's fixed stage count. Use it to describe progress and reason for workflow decisions. Do not convert it to a percentage: stages have different lengths, so '2/3' does not mean two thirds done. Absent during an approval pause, on older single-stage projects, or for a pinned scan_id earlier than the project's latest scan."
    • addedOutput schema / properties / scan_repositories
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "$ref": "#/$defs/ScanRepositoryCommit"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "Each repository the described scan read, with repo_slug and commit_sha: the pinned scan on a scan_id read, otherwise the running scan. Absent until that scan has recorded its cloned commits.",
      +  "title": "Scan Repositories"
      +}
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint=false, but the description adds the operational envelope: a scan takes up to 1 hour, poll about every 10 minutes, and progress/position fields go absent during an approval pause. It also warns against inventing an ETA and against carrying forward a stale position from an earlier poll, which is real behavioral context an agent could not derive from structure.

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 is front-loaded and the bulleted state table is scannable, with each block covering a genuinely distinct case. It runs long, though, and the closing paragraph on pinned scan_id largely repeats the schema, plus the internal 'Trent' reference is noise for an external caller.

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?

Despite an output schema existing, the description explains the reply's decision-relevant fields (reason, progress_summary, scan_phase vs job_phase) and how to relay them without inventing a percentage or ETA. Combined with the polling cadence and approval-pause caveat, an agent has everything needed to call and interpret this correctly.

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?

Schema coverage is 100% and the scan_id description already explains pinning, cross-project errors, and absent position fields, so the description's restatement of the pinned scan_id case adds little. The baseline 3 applies: the schema does the heavy lifting and the description does not extend parameter semantics beyond it.

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 first sentence states a specific verb and resource ('Poll a scan and discover its artifacts') and immediately frames the three user questions it answers. It is clearly distinguishable from siblings like get_artifact and get_security_posture, which it routes to rather than duplicates.

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 gives explicit when-to-use phrasings, then a complete decision table over every `reason` value: keep polling for not_complete, fetch security_requirements then call approve_scan_phase for awaiting_approval, read get_security_posture on ok, and stop on the four terminal/skip states. Alternatives and exclusions are named directly, leaving nothing to inference.

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.