Skip to main content
Glama
rillsoft

Rillsoft Project MCP server

Official

Assign machine

rillsoft_task_machine_assignment_set
Idempotent

Assign a specific existing machine to a task or remove that assignment by setting quantity to 0; it edits one task's machine link without changing master data or machine sharing.

Instructions

Assigns one specific existing machine to a task, or removes that assignment with quantity 0. The twin of rillsoft_task_employee_assignment_set; machines carry neither an employment period nor an efficiency. It touches one task - letting several tasks share one machine goes through rillsoft_machine_sharing_create. The master data stays untouched; an overload over time is a legitimate planning state and shows up in the report. One undo step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
quantityYes1 assigns, 0 removes the assignment
taskUuidYesUUID of the task
machineIdYesid of the machine from rillsoft_resource_pool_catalog_list
utilizationNoutilization greater than 0 up to 1 (defaults to 1)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
wbsYesWBS code
nameYesname
uuidYesUUID of the element
startYesstart, DD.MM.YYYY hh:mm
finishYesfinish, DD.MM.YYYY hh:mm
numberYesnumber of the element; unique even for split tasks
machineAssignmentsYesthe assignments of the task after the change

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.626

TDQS

A4.5/5.0
Behavior4/5

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

Adds real context beyond annotations: master data untouched, overload over time is a legitimate state surfaced in the report, and exactly one undo step. Annotations already cover idempotency, non-destructiveness and non-readOnly. Doesn't state required permissions, but the note about master data staying intact covers the main risk.

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?

Four tight sentences: action, sibling differentiation, scoping constraint, side effects. The undo-step note is front-loaded at the end as a close, with no filler. Front-loaded with the core action.

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?

Complete for a mutation tool with an output schema: schema covers all params, annotations cover safety, and the description adds the one behavioral risk (overload is allowed, not an error) plus the undo semantics. An agent can call it correctly from this.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description's only added semantic is the quantity 0 removal case, which the schema already documents; utilization and machineId sourcing are left to the schema.

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?

States a specific verb (assigns) and resource (a specific existing machine to a task), and explicitly covers the removal case via quantity 0. It distinguishes itself from the twin rillsoft_task_employee_assignment_set and from rillsoft_machine_sharing_create by naming both.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routes clearly: single-machine single-task use here, multi-task sharing through rillsoft_machine_sharing_create, and the employee variant for people. The quantity-0 removal path is spelled out, so an agent knows when to call it for unassignment.

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

Deploy Server

Other Tools