Skip to main content
Glama
lanlan0811

tianshu-mcp

by lanlan0811
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

rework_task

rework_task
Destructive

Requeue terminal failed or needs-attention tasks for resumed execution, keeping agent/project context, with optional feedback or structured repair hints to guide correction.

Instructions

手动返修：把终态任务（failed/needs_attention）重新入队续跑，同一 agent/项目与轮次记账。feedback 为追加指示（建议带上一次验收失败摘要）。repairHint 为可选的结构化修复提示（自由字符串，上限 4000 字符）——写「文件:行 / 问题 / 做什么」，会以【结构化修复提示】块置于 feedback 之前，便于 agent 先精确定位再读整段说明；不传则行为不变。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
taskIdYes
feedbackNo
repairHintNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.4
    • addedInput schema / properties / repairHint
      Added value: +{
+  "maxLength": 4000,
+  "type": "string"
+}
  2. Changed1 schema field changedv0.1.9
    • removedInput schema / properties / round
      Removed value: -{
-  "exclusiveMinimum": 0,
-  "type": "integer"
-}
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the destructiveHint annotation, the description discloses the re-queue/continue behavior, preservation of agent/project/round accounting, feedback append semantics, and repairHint placement before feedback. It even clarifies that omitting repairHint leaves behavior unchanged, which is valuable side-effect transparency.

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 dense and front-loaded with the core action before parameter details. It slightly repeats schema facts such as maxLength=4000 and the free-string type, but there is no wasted or misleading content.

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 mutating tool with no output schema, the description covers the target state, parameters, and behavioral consequences well. It does not describe return values or what happens if the task is not in a terminal state, but the essential invocation information is present.

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

Parameters5/5

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

With 0% schema coverage, the description compensates well: feedback is defined as an appended instruction, and repairHint is explained as an optional structured hint with format, limit, and placement. taskId's role is clear from context and required status, so no parameter is left ambiguous.

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 gives a specific verb and resource: manually rework terminal tasks (failed/needs_attention) by re-queueing them to continue running, including same agent/project and round accounting. It clearly defines scope, but does not explicitly name or contrast sibling tools such as continue_task or run_task, so differentiation is implied rather than stated.

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 clearly states when to use the tool: for terminal-state tasks that need manual rework. It does not provide exclusions or name alternatives, so an agent gets a clear trigger but no explicit guidance about when a sibling would be preferable.

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