Skip to main content
Glama

查询 DSH 任务状态

dsh_status
Read-only

Query task status and incremental events for a delegated DSH task. Use long polling with wait_s to wait longer per call and avoid frequent leader round trips.

Instructions

查询任务状态与增量事件。status 为 succeeded/failed/cancelled 表示结束。用 wait_s 长轮询(建议 60–120s)一次等更久,减少 leader 往返;不要用 5–25s 高频轮询。

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": {
      "task_id": "<task_id>"
    },
    "name": "dsh_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNo上次返回的 next_cursor,用于只取增量事件
wait_sNo长轮询等待秒数(默认 0);实际上限由 worker 配置 DSH_MCP_STATUS_WAIT_MAX_S 决定(当前 120s)
task_idYesdsh_run 返回的任务 id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.2

TDQS

A3.9/5.0
Behavior4/5

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: which status values mean the task has ended, and that long polling reduces round trips to the leader. It does not describe the shape of the returned events.

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 short sentences, front-loaded with the purpose, then the terminal-state semantics, then the polling advice. No filler, and every sentence carries actionable information.

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?

There is no output schema, so the description must carry the return-value burden. It covers terminal statuses and the next_cursor contract well enough to call the tool correctly, though it does not describe the event payload structure.

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 the baseline is 3. The description still adds value by recommending a concrete wait_s range of 60–120s and by tying cursor to incremental event retrieval, which goes beyond the schema's terse field notes.

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?

The description states a specific verb and resource: querying task status plus incremental events, and it explains what the terminal status values mean. It does not name sibling tools such as dsh_result or dsh_batch_status, so an agent must infer the boundary from the names alone.

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?

It gives explicit polling guidance: use wait_s for long polling at 60–120s, and avoid high-frequency polling at 5–25s. However, it never says when to use this tool instead of dsh_result, dsh_batch_status, or dsh_tasks, so the choice among siblings is only implied.

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