Starts a bounded, revision-bound core task plan from workspace tasks and a frozen base snapshot, keeping human decisions separate from automated planning.
Start a bounded, revision-bound core task plan; human decisions remain separate.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | ||
| run_id | No | ||
| workspace | Yes | Current workspace root holding sdd-workspace.yml. | |
| base_change | No | Checked initial candidate; its exact snapshot is frozen into the plan. |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is a non-idempotent mutation (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the safety profile is covered. The description adds that the plan is 'bounded' and 'revision-bound' and that human decisions are separate, but it never explains what freezing a candidate or starting a run actually does to state. With annotations present, this partial context is adequate for a 3.
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?
It is a single front-loaded sentence with no wasted clauses, and the verb leads. However, the terseness leaves key concepts unexplained, so it is efficient but arguably under-specified rather than optimally structured.
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?
For a non-idempotent mutation with four parameters, a required arbitrary-object tasks array, and no output schema, the description says almost nothing about side effects, return behavior, or what constitutes a valid task plan. It is materially incomplete for an agent to invoke this correctly.
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 coverage is only 50%: workspace and base_change are documented in the schema, but run_id has no description and tasks is an array of unconstrained objects whose shape is critical and entirely undefined. The description does not compensate for these gaps or explain what a task object must contain.
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?
The verb 'Start' and object 'core task plan' are present, but 'bounded, revision-bound' is unexplained jargon and the description does not distinguish this from sibling architect_runtime_start, which likely also starts planning. An agent sees an intent but cannot confidently pick this over the runtime sibling from the text alone.
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?
There is no explicit guidance on when to use this tool versus architect_runtime_start or architect_runs_control, nor any prerequisites beyond the vague 'human decisions remain separate'. The agent is left to infer selection criteria from the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.