create_process_with_parallel

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the creation intent ('Crea un proceso') and reveals nothing about side effects, output location, whether the result is validated, or how merge_tasks affects the generated model. For a generation tool that presumably writes BPMN files, this is a significant gap.

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 single sentence is efficient and front-loaded with the action verb, containing zero fluff. However, it reads as under-specification rather than appropriate conciseness: for a 2-parameter tool with no annotations and no output schema, more content (parameter hints, output behavior) was needed to be genuinely useful.

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?

At 2 parameters, no output schema, and no annotations, the definition is thin relative to the tool's complexity. Critical context is missing: what the parallel gateway structure looks like, whether a merge gateway is included, and what format the description input should take. An agent would have to guess these details or probe the parameters.

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% and the description mentions neither parameter. 'description' is self-explanatory from context, but 'merge_tasks' is genuinely ambiguous — it could mean merging parallel branches back into one flow, or merging tasks — and nothing disambiguates it. The description needed to compensate for the schema gap and did not.

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 states a specific verb and resource: 'Crea un proceso BPMN con ramas paralelas (parallel gateway)' — creating a BPMN process with parallel branches. This naturally distinguishes it from obvious siblings like create_simple_linear_process and create_process_with_decision by the parallel-gateway feature. However, it doesn't explicitly name those siblings or the exact distinguishing condition.

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?

Usage context is implied: choose this tool when the process requires parallel branches. But no exclusions or alternative tools are named, despite a large sibling set (create_simple_linear_process, create_process_with_decision, create_process_with_loops_and_multiinstance) that overlaps on process creation. An agent gets no guidance on when not to use it or how parallel flows differ from decision/loop flows.

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