hudu-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Start a Process from a Procedure

hudu_kickoff_procedure

Start a new process from a procedure to create a live checklist for a company. Attach to an asset when work concerns a specific employee or device.

Instructions

Start a new process from an existing procedure. Hudu copies the procedure's task list into a new process record with its own id, slug and URL, and returns that new record. Afterwards the company has a live checklist that its users can work through and tick off; the procedure it came from is unchanged and can be kicked off again.

Attach the new process to an asset with asset_id when the work concerns one specific device or person — that is how an onboarding checklist ends up on the employee record it belongs to. Give it a name when several runs of the same procedure would otherwise be indistinguishable, e.g. "Onboarding — J. Okafor".

Find the procedure id with hudu_list_procedures. Both optional inputs are sent as query parameters because that is what Hudu documents for this endpoint; it accepts no request body. Success answers 200 rather than the 201 you might expect from a create, and 404 covers both a missing procedure and an unrouted path.

Operation class: Create. Impact: Creates a live process in Hudu, visible to the users of the company that owns the procedure and appearing in their process list as outstanding work.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>"
    },
    "name": "hudu_kickoff_procedure"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Numeric Hudu id of the procedure to start a process from.
`name`	No	Name for the new process. Omit to inherit the procedure's own name, which makes repeated runs hard to tell apart.
`asset_id`	No	Numeric id of an asset to attach the new process to, such as the employee or server the work is about. Omit to leave the process unattached.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server