执行工作流

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true; the description adds useful behavioral detail beyond that: workflows run sequentially, stop on failure by default, and return completed steps and compensation prompts. It does not contradict the annotations.

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?

The entire description is one sentence with no wasted words: it front-loads the core execution purpose and then the failure behavior. Every piece contributes information.

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 4-parameter tool with a nested steps array, an execution output, and no output schema or parameter descriptions, one sentence is far from complete. The agent is left without knowing step item fields, the role of workflowId, details of continueOnError, or the shape of the returned completed steps and compensation prompts.

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?

With 0% schema description coverage, the description must explain the parameters, but it only vaguely hints at 'steps' via 'planned capabilities' and at continueOnError via 'by default stops on failure'. It gives no guidance on projectId, workflowId, the steps array structure, or the individual step fields.

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 action, 'execute planned capabilities in sequence', and defines the default stop-on-failure behavior, so the tool's purpose is clear. It implicitly distinguishes itself from planning (cocos_workflow_plan) and single-capability execution (cocos_capability_execute), but does not name those siblings explicitly.

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?

It implies this tool should be used when planned capabilities exist and need to be executed sequentially, providing default failure semantics. However, there are no explicit exclusions or named alternatives, leaving the choice vs cocos_capability_execute or cocos_workflow_plan to the agent to infer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.