Orchestrates a DeepSeek Harness design workflow that turns an idea into clarifying questions, technology options, design breakdowns, reverse reasoning, and risk assessments.
创建一个 DeepSeek Harness 顶层设计工作流。
默认编排：
capture_idea
list_design_options
analyze_upper_design
reverse_reasoning
assess_risks
finalize_plan
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| idea | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden but discloses little beyond the step list: nothing about whether the workflow is persisted, whether creation is idempotent, side effects, or what the created workflow's state is. Listing the orchestration steps is useful context but does not explain the mutation's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose sentence, then a compact numbered list of the default steps. No filler; every line addresses the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations, no output schema, and 0% parameter coverage mean the description must do more work than it does. It explains the default pipeline but omits parameter meaning, return behavior, and how the created workflow relates to advance_harness_workflow/list_harness_workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for two parameters ('goal' optional, 'idea' required), and the description never mentions either parameter, their formats, or how 'idea' drives the workflow. For a tool with undocumented params, the description should compensate but provides nothing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('创建' / create) and resource ('DeepSeek Harness 顶层设计工作流'), and the sibling set (list_harness_workflows, advance_harness_workflow) makes the create-vs-list-vs-advance distinction inferable. The named default orchestration sequence also clarifies the scope of what gets created.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by presenting a '默认编排' (default orchestration) pipeline, suggesting this tool kicks off a standard design flow. However, it never states when to choose this over advance_harness_workflow or how a custom (non-default) workflow is triggered, leaving the selection criteria implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.