Start a Process from a Procedure

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

The description goes well beyond annotations by explaining that the procedure's task list is copied into a new process with its own id/slug/URL, the original procedure is unchanged and reusable, and the resulting process appears as outstanding work in the company's process list. It also describes HTTP status behavior (200 vs 201, 404 meaning both missing procedure and unrouted path) and that no request body is accepted, which are valuable execution details.

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 description is structured into clear paragraphs: one for core behavior, one for parameter guidance, and one for endpoint details. Every sentence serves a purpose, no filler. While longer than minimal, the density of useful information justifies its length, and the most important action is front-loaded.

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 create operation with no output schema, the description covers the essential context: what is created (live process with its own record), how it affects the company, how to attach assets, the status code nuances, and the operation's impact. This is complete for an agent to select and invoke the tool correctly without needing additional documentation.

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?

The schema already covers all three parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful usage examples for asset_id ('onboarding checklist ends up on the employee record') and name ('Onboarding — J. Okafor'), which helps agents decide when to provide these optional parameters. It doesn't add much for the required id beyond redirecting to hudu_list_procedures, but overall it enhances schema semantics.

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 opens with a specific verb and resource: 'Start a new process from an existing procedure.' It clearly explains the copy behavior and that the procedure remains unchanged, which distinguishes it from other Hudu tools like listing or getting procedures. The title also aligns, and the scope is unambiguous.

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 provides explicit usage context: when to attach an asset ('when the work concerns one specific device or person'), when to set a name ('when several runs of the same procedure would otherwise be indistinguishable'), and how to find the procedure id (via hudu_list_procedures). It does not explicitly contrast with alternative tools for creating processes, but no sibling serves this exact role, so the guidance is sufficient.

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