Skip to main content
Glama
rillsoft

Rillsoft Project MCP server

Official

Assign a resource to several tasks

rillsoft_resource_usage_set
Idempotent

Set one resource's usage across multiple tasks in one undoable call, with per-task values; use quantity 0 to remove assignments.

Instructions

Puts one resource on several tasks at once, or takes it off them, with the single values per task - the page 'Using tasks' of the capacity planning, written through the contract. One call is exactly one undo step for all of them, labelled like the page. quantity 0 removes, as with the five single-task tools. Each entry carries only the fields the page offers for that kind (rillsoft_resource_usage_list documents them); a field that belongs to another kind, or one the page merely displays such as free, is refused by name. Every check runs before the change: a single unknown UUID leaves the project untouched and creates no undo step. team is not part of this contract - assigning a team to a task belongs to the Standard edition alone; read it through rillsoft_resource_usage_list and set the preferred team of a project through rillsoft_project_team_preference_set. Beware of the neighbour: rillsoft_task_resource_assignment_fill is the wizard, filling tasks automatically out of their roles and without single values; this one fills exactly the tasks named, with them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesresource type; team is missing on purpose - see the description
resourceIdYesid of the resource from rillsoft_resource_pool_catalog_list
assignmentsYesone entry per task; each UUID at most once

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoname of the resource
typeYesresource type
tasksYesthe tasks after the change, in the order of assignments[]
skippedYesskipped tasks with the cause
resourceIdYesid of the resource in the resource pool

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.626

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, not destructive, idempotent); the description adds unusually valuable behavior: 'One call is exactly one undo step', validation is atomic ('a single unknown UUID leaves the project untouched and creates no undo step'), and out-of-kind fields are 'refused by name'. That is meaningful disclosure beyond structured fields.

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

Conciseness3/5

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

Content is front-loaded with the core action, but the prose is a single dense block with run-on clauses ('with the single values per task - the page "Using tasks" of the capacity planning, written through the contract') that are hard to parse. Little is padding, but the structure impedes fast comprehension.

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 mutation tool with an output schema present, the description covers the remaining gaps: atomic validation, undo granularity, per-type field validity, and routing to alternatives for team and for bulk wizard-style filling. Nothing an agent needs to call it correctly is missing.

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?

Schema coverage is 100% and each field is already documented, so the baseline is 3. The description still adds cross-cutting semantics the schema cannot express: which fields are valid per resource type, that read-only fields such as 'free' are rejected rather than ignored, and that team-based fields are excluded by contract.

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 and resource with scope: 'Puts one resource on several tasks at once, or takes it off them.' It further distinguishes itself from the five single-task siblings and from the wizard tool by name, so an agent can differentiate without opening schemas.

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?

Explicitly covers when-not and alternatives: 'quantity 0 removes', 'team is not part of this contract ... read it through rillsoft_resource_usage_list and set the preferred team ... through rillsoft_project_team_preference_set', and contrasts with 'rillsoft_task_resource_assignment_fill is the wizard'. Nothing about selection 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