Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
TIANSHU_MCP_HOMENoPath to the .tianshu-mcp directory (e.g. <repository_absolute_path>/.tianshu-mcp). Used to locate acceptance configuration, skills, and other server data.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
prepare_visual_baselineA

准备视觉基准候选,返回摘要与预览;不采用正式基准。需要用户授权。

approve_visual_baselineA

仅在用户明确审阅并授权后批准视觉基准。必须核对候选摘要与批准说明;自动返修禁止调用。宿主必须实施实际审批控制。

continue_taskA

恢复处于 needs_user 的任务。zcode:agent_question 时 message 发往原会话,关闭旧实例/登录/系统权限场景中 message 仅作已处理确认。codex:user_confirmation 时重新接入观察 GUI 内运行(不发送消息);login_required 时复检环境后重发任务书。qoder:Agent 提问通过专用答题控件回复;多题 message 使用完整问题文字到答案的 JSON 对象。审批或环境处理后仅恢复观察,提交不明时禁止重发。

run_taskA

派活:启动外部 AI-Agent 开发任务并可自动验收返修,异步返回 taskId。ZCode 要求 model=供应商/模型,不支持 mode;TraeWork 的 model 可选并支持 Work/Code/Design mode。task/context 内的 ZCode 项目路径引用会在发送前校验。Qoder CN 要求已有 projectPath 和可读 planDoc;modelSource 可选 default/custom,省略模型或等级则沿用当前设置。思考等级通过模型管理保存为全局偏好,权限模式不变;macOS research 禁止派发。可选 idempotencyKey(1..128 字符):同一 key 在 TTL(默认 24h)内重复提交恒返回原 taskId 与当前状态、不新建任务,参数变更则报冲突——重试请复用同一 key。 可选 dryRun=true 进入干跑模式(先审后做):agent 只分析规划、输出将要修改的文件清单与方案、不动源码;验收引擎只做静态分析(引用文件是否存在、拟改位置是否存在、明显逻辑冲突),跳过 typecheck/test/build。dryRun 需提供 projectPath、忽略 autoVerify、不进入自动返修;产物为独立报告(meta.dryRunReportFiles,不消耗验收轮次)与方案文档(meta.dryRunPlanDoc,可直接作为后续正式任务的 planDoc)。默认关闭。

query_taskA

查询任务状态 / 进度 / 最近日志尾部(默认 agent.log 末 40 行)/ 最近细粒度事件。返回任务 meta 与日志片段。meta.recentEvents 为最近 N 条 agent 事件(eventLimit 缺省 10、上限 50),取值 task_dispatched / confirmation_dialog_detected / awaiting_user_authorization / file_modification_started / rework_triggered —— 长任务下可据此区分「正常执行」与「卡在弹窗等人」。未实现事件上报的适配器该数组为空,其余字段不变。

list_tasksA

列出历史任务(可按项目路径 / 状态过滤,limit 默认 50)。

get_task_reportA

取某轮验收报告全文(report.md)。round 缺省取最新一轮。

cancel_taskA

取消运行中任务:CLI agent 终止进程树;GUI agent(codex 等)尽力点击界面停止按钮并等待 GUI 空闲(有界超时),未确认停止时结果中明示。排队中任务直接移除。对已处于终态的 GUI 任务,本调用兼任人工确认入口:人工核实窗口中已无残留运行后调用,可清除 meta 的 guiStopUnconfirmed 待确认标记(不改终态)。

verify_taskA

对已完成任务或项目路径执行一次验收(不改源码):自动命令检查 + 代码分析(相对 git 基线)。可用 extraChecks 临时加验。需任务/项目二选一。可选 idempotencyKey:同一 key 重试不重跑验收——执行中的同键请求返回进行中提示,已完成的直接返回既有报告与轮次,参数变更则报冲突。

wait_taskA

等待任务到达停点(阻塞只读原语):轮询至终态(succeeded/failed/needs_attention/cancelled/interrupted)或 needs_user,或超时(timeoutMs 缺省 50000ms、上限 600000ms)后返回当前状态快照。适合回合驱动的调用方:run_task 后在本回合内等待结果。超时返回时请再次调用本工具继续等待——本调用不影响任务本体,超时/中断均无害。

wait_anyB

等待一组任务中首个到达停点(终态或 needs_user)的任务;返回该任务快照与全部任务当前状态。taskIds 1..20 个,开始前校验全部存在,缺一即报错。

rework_taskA

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

get_profilesA

查看当前 agent 适配与可执行探测结果(含未安装/调研占位提示)。

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 13 tools

Disambiguation4/5

Each tool maps to a distinct lifecycle action: dispatch (run_task), wait (wait_task/wait_any), inspect (query_task/get_task_report/list_tasks), resume (continue_task), rework (rework_task), cancel, verify, and baseline approval. The only mild overlap is among read-only status tools (query_task vs wait_task vs wait_any), but their blocking, snapshot, and group semantics are clearly described.

Naming Consistency4/5

All names use lower_snake_case with a verb-first pattern (get_task_report, list_tasks, run_task, verify_task, rework_task, etc.). wait_any is the only verb-only name that slightly breaks the verb_noun convention, but the set remains highly predictable.

Tool Count5/5

13 tools is well within the ideal 3-15 range and each tool corresponds to a real orchestration need: dispatch, polling/waiting, inspection, cancellation, recovery, verification, baseline approval, and adapter inspection. No tool feels redundant or out of scope.

Completeness4/5

The surface covers the full task lifecycle from run_task through wait/query/cancel/continue/rework/verify/report and includes visual-baseline prepare/approve plus profile inspection. Minor gaps exist, such as no reject/discard operation for a prepared visual baseline and no direct standalone plan-doc retrieval tool, but these are workable via existing meta outputs.

Maintenance

ActivityMaintained
ResponsivenessResponsive