Rillsoft Project MCP server

Official

Overview Schema Source Related Servers Discussions Admin

Create RIS folder

rillsoft_folder_ris_create

Creates a subfolder in the project folder tree on the Rillsoft Integration Server using a name and an existing parent folder ID; the change applies immediately and has no undo.

Instructions

Creates a subfolder in the project folder tree of the logged-in client on the Rillsoft Integration Server - the 'New folder' button of the folder dialog. Takes effect on the server at once: no undo step; rillsoft_folder_ris_delete removes it. An unknown parent is refused before anything is sent. Runs with the login of the desktop session.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	name of the new folder
`parentFolderId`	Yes	id of the folder the new one goes into, from rillsoft_folder_ris_list; root folders cannot be created

Output Schema

TableJSON Schema

Name	Required	Description
`left`	Yes	left index of the nested-set tree
`name`	Yes	name of the folder
`path`	Yes	names from the root, joined by ' / '
`uuid`	Yes	UUID of the folder
`depth`	Yes	0 at a root folder, 1 below it, and so on
`right`	Yes	right index of the nested-set tree
`folderId`	Yes	id of the folder on the server; what the other folder tools and rillsoft_project_ris_save_as take
`description`	Yes	description; empty when none is set
`folderCount`	Yes	subfolders directly below this folder
`projectCount`	Yes	projects lying directly in this folder (subfolders not counted)
`parentFolderId`	No	id of the parent folder; missing at a root folder

Schema Changelog

Changes observed during successful MCP inspections.

First observedv10.0.626Oct 17, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the change is immediate with no undo step, names the inverse tool, states the pre-flight validation behavior for an unknown parent, and pins the auth context to the logged-in desktop session. Annotations (destructiveHint=false, idempotentHint=false) are consistent with a create that destroys nothing itself and is reversed by delete.

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?

Purpose is front-loaded in the first clause, followed by effect, reversal, validation, and auth context — four compact sentences with no filler. Slightly dense but every sentence carries distinct information.

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, the description covers what it does, its side effects, reversal path, validation failure mode, and execution identity. Nothing an agent needs in order 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.

Parameters3/5

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

Schema description coverage is 100% and both parameters (name, parentFolderId) are documented in the schema, including the 'root folders cannot be created' constraint. The description adds no format, syntax, or naming-rule detail beyond that, so the baseline 3 applies.

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 ('Creates a subfolder in the project folder tree') plus the exact UI affordance it mirrors, so an agent can identify it against rillsoft_folder_ris_list/update/move. It explicitly names rillsoft_folder_ris_delete as the reversal path, sharpening the distinction from siblings.

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?

Gives clear operating context: immediate server effect, reversal only through rillsoft_folder_ris_delete, and that an unknown parent is rejected pre-send. It stops short of explicit 'use X when Y' routing for the other folder siblings (list, update, move).

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

Deploy Server