Skip to main content
Glama

Check remote task status

get_task_status
Read-onlyIdempotent

Returns a lightweight plain-text timeline for a previously submitted computer task by command_id. Use it after a device tool returns QUEUED, DELIVERED, ACKED, or RUNNING. Show only newly reached lifecycle steps or meaningful new recent output to the user as concise text, preserving the returned target-computer local time and timezone. Never create a card/table, expose unchanged polls, invent percentages, or resubmit the original operation.

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": {
      "command_id": "<command_id>"
    },
    "name": "get_task_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
command_idYesThe command_id returned by a previous device tool call.

Output Schema

NameRequiredDescriptionDefault
okYes
unitYes
errorYes
stageYes
totalYes
methodYes
statusYes
currentYes
messageYes
acked_atYes
advisoryNo
sequenceYes
terminalYes
timelineNo
device_idYes
exit_codeYes
issued_atYes
retryableYes
command_idYes
elapsed_msYes
error_codeYes
running_atYes
started_atYes
device_nameYes
finished_atYes
next_actionYes
workflow_idYes
brand_noticeNo
delivered_atYes
failure_kindYes
ai_session_idYes
timezone_nameNo
failure_domainYes
fatal_incidentNo
handoff_noticeNo
last_update_atYes
partial_outputYes
retry_after_msYes
timezone_labelNo
auto_diagnosticsNo
display_headlineNo
display_severityNo
progress_percentYes
result_availableYes
started_local_timeYes
diagnostic_requiredNo
timezone_offset_minutesNo
auto_diagnostic_triggeredNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the read-only and idempotent annotations, the description discloses output format as lightweight plain text, timezone preservation for target-computer local time, and polling behavior around unchanged results. It also gives concrete presentation constraints that prevent common agent behaviors like inventing percentages or resubmitting the original operation.

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?

The description is front-loaded with the return format and call trigger, then moves into display constraints. It is dense but every sentence serves a purpose, though the presentation instructions make it slightly longer than a minimal status definition.

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 the description need not explain return structure, and the annotations already cover safety. It covers the call trigger, output form, and user-facing rendering behavior, with only the missing explicit alternative for completed results as a minor gap.

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 description coverage is 100%, and the schema already defines command_id as the identifier returned by a previous device tool call. The description reinforces that usage but adds no additional syntax, format, or lookup semantics beyond the schema.

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 description states a specific verb and resource: returns a lightweight plain-text timeline for a previously submitted computer task by command_id. It distinguishes the status/timeline role from result-oriented siblings such as get_task_result without needing to name them.

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?

It gives clear triggering guidance: use after a device tool returns QUEUED, DELIVERED, ACKED, or RUNNING. It does not explicitly name an alternative for completed tasks or state when not to use this versus get_task_result, so it falls short of full when/when-not guidance.

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