Decompose a high-level coding goal into tasks, delegate implementation and verification to background subagents, and return completed work.
Submit a high-level goal to be decomposed, implemented, and verified.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | Yes | ||
| model | No | ||
| execute | No | ||
| commands | No | ||
| workspace_path | No |
Changes observed during successful MCP inspections.
v1.1.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it only discloses that the goal goes through a decompose-implement-verify pipeline. It says nothing about whether submission is synchronous, what happens when execute=false versus true, what approvals or permissions are involved, or what gets created.
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?
One front-loaded sentence with no filler, which is structurally sound. However, the brevity reads as under-specification rather than disciplined concision given the five-parameter surface it is describing.
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?
A five-parameter entry point with no annotations, no output schema, and zero schema description coverage needs substantially more prose to be safely callable. As written, an agent cannot tell what execute, commands, or workspace_path do or what the tool returns.
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% across five parameters, and the description only loosely gestures at 'goal' by calling it 'high-level'. Model, execute, commands, and workspace_path receive no semantic explanation anywhere, leaving the most consequential flags undocumented.
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 description names a specific verb ('Submit') and resource ('goal'), and adds that the goal will be decomposed, implemented, and verified, which implicitly separates it from execution-oriented siblings like execute_run and execute_task. It stops short of naming any sibling explicitly, so it lands at clear-but-undifferentiated.
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 guidance on when to choose submit_goal over execute_task or execute_run, nor any mention of the execute flag that appears to control whether the goal is actually run. The agent must infer the entire routing decision from one sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.