Skip to main content
Glama
rillsoft

Rillsoft Project MCP server

Official

Assign role

rillsoft_task_role_assignment_set
Idempotent

Assign a required role (qualification) to a task or remove it by setting quantity to 0. Use this to define staffing needs without naming a person.

Instructions

Assigns a role (a professional qualification) from the existing pool to a task, or removes it again with quantity 0. A role is the requirement, not the person: filling it with someone concrete goes through rillsoft_task_employee_assignment_set, and rillsoft_task_role_assignment_derive works the other way round and rebuilds roles out of the people already assigned. Machine kinds are the mirror case (rillsoft_task_machine_role_assignment_set). One undo step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleIdYesid of the qualification from rillsoft_resource_pool_catalog_list with types:["role"]
quantityYeshow many people of this role; 0 removes the assignment
taskUuidYesUUID of the task
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
assignmentsYesthe assignments of the task after the change

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.626

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare non-readOnly, idempotent, non-destructive. The description adds genuinely useful behavioral context beyond them: setting quantity 0 removes the assignment, and the operation consumes exactly 'one undo step', which matters for an agent planning revertible actions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core action and its inverse come first, then the disambiguation of siblings. Every sentence carries routing or behavioral information, though the sibling enumeration is tight enough to avoid bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description supplies the role-vs-person conceptual model, the inverse operation, and the undo-step cost, leaving little an agent needs that is missing.

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 coverage is 100%, so the schema already documents roleId, quantity, taskUuid and utilization. The description reinforces that quantity 0 removes the assignment (already in the schema) and clarifies the roleId source is a professional qualification from the existing pool, adding only marginal value over the structured fields.

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 states a specific verb and resource (assign a role to a task) plus the inverse operation (remove with quantity 0), and explicitly distinguishes this tool from three named siblings: employee_assignment_set (filling with a person), role_assignment_derive (rebuilds roles from people), and machine_role_assignment_set.

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?

It describes exactly when to use this tool versus the alternatives, explaining the conceptual difference between a role (the requirement) and a person or machine, and pointing to the sibling for each case. Nothing is left to inference.

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