Rillsoft Project MCP server

Official

Overview Schema Source Related Servers Discussions Admin

Group elements into subproject

rillsoft_element_subproject_group

Creates a new subproject and moves existing tasks or subprojects into it, grouping them under one parent with a single undo step.

Instructions

Creates a subproject and pulls the named elements into it - an element being a task or a subproject. This groups elements that already exist; creating an empty subproject goes through rillsoft_subproject_create. In a portfolio the elements must lie inside a project - at portfolio level a new subproject would be a project, which the user interface does not offer either. One undo step, which takes the new subproject away again as well. The answer names the new subproject (uuid, wbs) and the elements that were moved.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	name of the new subproject; left empty it takes the name of the element where there is exactly one, and stays empty otherwise
`uuid`	No	shorthand for a single element
`uuids`	No	UUIDs of the elements that move into the new subproject; all of them below the same project or subproject

Output Schema

TableJSON Schema

Name	Required	Description
`wbs`	Yes	WBS code
`name`	Yes	name
`uuid`	Yes	UUID of the element
`start`	Yes	start, DD.MM.YYYY hh:mm
`finish`	Yes	finish, DD.MM.YYYY hh:mm
`number`	Yes	number of the element; unique even for split tasks
`elements`	Yes	the elements grouped into the new subproject
`parentUuid`	Yes	UUID of the parent project or subproject

Schema Changelog

Changes observed during successful MCP inspections.

First observedv10.0.626Oct 17, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly=false, destructive=false, and idempotent=false, so the safety profile is covered. The description adds genuinely new context: single-undo semantics that also remove the new subproject, and the portfolio-level restriction. It does not discuss permissions/auth, keeping it short of a 5.

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?

Front-loads the core action, then the alternative, then constraints, undo, and return content. Every sentence carries information, though the prose is dense and slightly run-on, costing some readability.

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 alternative path, the portfolio precondition, undo behavior, and the shape of the response. An agent has everything needed to invoke it correctly.

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 uuid/uuids/name semantics are already documented in the schema. The description only restates that elements are named and adds that an element is a task or subproject, adding 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?

States a specific compound action (creates a subproject and pulls named elements into it) and defines 'element' as a task or subproject. It also names the sibling it is NOT (rillsoft_subproject_create for empty subprojects), so an agent can distinguish it immediately.

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 routes the empty-subproject case to rillsoft_subproject_create and states the portfolio-level precondition (elements must lie inside a project, since a portfolio-level subproject would be a project). Both when-to-use and when-not-to-use are covered.

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

Deploy Server