Skip to main content
Glama
Sign In
tianshu-mcp

tianshu-mcp

by lanlan0811
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

manage_task

manage_task
Destructive

Cancel running tasks, resume tasks waiting for user input, or requeue failed tasks for rework. Manage the full lifecycle of async AI-agent CLI development tasks by task ID and action.

Instructions

任务生命周期管理（合并原 cancel_task / continue_task / rework_task），用 action 区分：action=cancel 取消运行中任务（CLI 终止进程树；GUI 点击界面停止按钮并等待空闲，未确认停止时结果中明示。排队中任务直接移除。对已终态的 GUI 任务兼任人工确认入口：核实窗口无残留运行后调用可清除 guiStopUnconfirmed 标记）——可选 reason 为取消原因；action=continue 恢复 needs_user 状态的任务（message 必填）：zcode 在 agent_question 时把 message 发往原会话，关闭旧实例/登录/系统权限场景中 message 仅作已处理确认；codex 的 user_confirmation 重新接入观察（不发送消息）、login_required 复检环境后重发任务书；kimicode/minimax 的 agent_question 把 message 发往原会话。审批或环境处理后仅恢复观察，提交不明时禁止重发；action=rework 手动返修终态任务（failed/needs_attention）重新入队续跑，同一 agent/项目与轮次记账：feedback 为追加指示（建议带上一次验收失败摘要），repairHint 为可选的结构化修复提示（自由字符串，上限 4000 字符）——写「文件:行 / 问题 / 做什么」，会以【结构化修复提示】块置于 feedback 之前，不传则行为不变。注意：本工具含破坏性 action（cancel / rework）。

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": {
      "taskId": "<taskId>",
      "action": "<action>"
    },
    "name": "manage_task"
  }
}

Input Schema

NameRequiredDescriptionDefault
actionYes
reasonNo
taskIdYes
messageNo
feedbackNo
repairHintNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.0-beta.3

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true and non-idempotent, and the description goes well beyond that: it explains that cancel kills the process tree under CLI versus clicking stop and waiting for idle under GUI, that an unconfirmed stop is surfaced in the result, that queued tasks are removed outright, and how continue re-attaches per platform (zcode/codex/kimicode/minimax) including that codex user_confirmation resumes observation without sending a message. It also restates the destructive nature of cancel/rework, consistent with the annotations.

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?

It is front-loaded with the merge and the action discriminator, which is the right ordering, but the body is one dense block of nested parentheses and em-dashes with no per-action line breaks or bullets. Nearly every clause carries real information, yet the packaging makes it hard to scan, and a per-action structure would cost nothing in length.

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?

For a destructive, multi-action, six-parameter tool with no output schema, the definition covers what each action does, what is required per action, and what is forbidden. It only lightly touches return behavior (unconfirmed GUI stop is surfaced in the result) and says nothing about failure handling or how a taskId is obtained.

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 description coverage is 0%, so the description must carry parameter meaning, and it largely does: `reason` is the optional cancel reason, `message` is required for continue, `feedback` is an appended instruction (with advice to include the last acceptance-failure summary), and `repairHint` is an optional free string capped at 4000 chars with a recommended 'file:line / problem / action' format. `taskId` is never characterized (format, where obtained), which is the only real 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?

The opening line states the resource (task lifecycle management) and the mechanism (an `action` discriminator) and explicitly records that it consolidates the former cancel_task / continue_task / rework_task. Each action value is then given its own concrete semantics (cancel = terminate/remove, continue = resume needs_user, rework = re-enqueue terminal task), so an agent can tell which behavior it is invoking without opening the schema.

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?

Guidance is given per action with conditions and exclusions: cancel applies to running tasks (queued ones removed directly) and doubles as the manual-confirmation entry for terminal GUI tasks; continue applies only to needs_user; rework applies only to failed/needs_attention. It also states a prohibition — after approval/environment handling only observation resumes, and re-sending is forbidden when submission state is unclear.

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

Deploy Server

Other Tools