tianshu-mcp
Related Servers
Alternatives to tianshu-mcp
No user-submitted related servers found.
Related Servers
- AlicenseAqualityAmaintenanceEnables orchestrating external AI agents to execute development tasks with asynchronous management, automated acceptance verification, failure rework loops, and optional visual baseline validation.1114 npmApache 2.0
- AlicenseAqualityBmaintenanceEnables AI agents to delegate complex coding tasks, refactorings, and automated code reviews to OpenAI Codex and Google Antigravity CLIs, running them autonomously in YOLO mode with process supervision.6MIT
- AlicenseCqualityAmaintenanceEnables multiple CLI-based AI agents to collaborate as a coordinated team through shared task queues, shared memory, and a message bus, with DAG orchestration, rate-limit avoidance, parallel dispatching, and long-task management.633MIT
- AlicenseNot gradedqualityAmaintenanceEnables Codex or Claude Code to orchestrate persistent Antigravity CLI workers as independent implementers and testers within restricted workspace roots. It supports asynchronous task dispatch, progress polling, result inspection, follow-up messages, and cancellation with bounded, audited local event logging.249 npm4MIT
- AlicenseNot gradedqualityCmaintenanceCoordinates parallel AI coding agents by providing task ownership, scoped file locks, handoffs, and verification workflows.MIT
- AlicenseBqualityBmaintenanceEnables Codex to delegate frontend development, general implementation, and writing tasks to Gemini agents through task orchestration and dedicated writing tools, with opt-in file write and native tool permissions. Tasks are supervised across MCP disconnections, allowing progress polling, follow-ups, and explicit interruption.14MIT
TDQS
Scored across 13 tools
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.
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.
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.
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.