Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Move RIS folder

rillsoft_folder_ris_move

Idempotent

Move a project folder and its subfolders/projects under or beside another folder on the Rillsoft Integration Server, choosing child or sibling position. Applies immediately; no undo.

Instructions

Moves a project folder of the logged-in client on the Rillsoft Integration Server under another folder or next to it, with its subfolders and projects - dragging in the folder dialog, plus the sibling positions the server offers. A folder cannot go under itself or one of its subfolders (ris_folder_cycle). Renaming is rillsoft_folder_ris_update; a project changes its folder through rillsoft_project_ris_save_as. Takes effect at once: no undo step. Runs with the login of the desktop session.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`folderId`	Yes	id of the folder to move, from rillsoft_folder_ris_list
`position`	No	where it lands relative to targetFolderId; last_child (the default) is what dragging in the dialog does	last_child
`targetFolderId`	Yes	the folder it is placed under (first_child, last_child) or next to (prev_sibling, next_sibling)

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

Behavior4/5

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

Annotations already declare write/idempotent/non-destructive, and the description adds real behavioral context: 'Takes effect at once: no undo step', the cycle restriction, and that it runs under the desktop session login. It stops short of describing server-side error behavior or side effects on contained projects beyond the move itself.

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, and each clause carries information (scope, alternative tools, constraint, immediacy, session). The 'dragging in the folder dialog, plus the sibling positions the server offers' fragment is slightly loose, but overall it is efficient rather than padded.

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?

With an output schema present, 100% param coverage, and rich annotations, the description only needs to add routing and behavioral caveats — which it does, including the no-undo warning and the clone/cycle rule. An agent has everything needed to call 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 folderId, targetFolderId, and the position enum are already fully documented. The description gestures at the semantics ('under another folder or next to it', 'the sibling positions the server offers') but adds little beyond the schema's own worst-case detail.

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?

Starts with a specific verb+resource ('Moves a project folder ... on the Rillsoft Integration Server') and clarifies the scope (with subfolders and projects, under or next to a target). It actively distinguishes itself from siblings by naming rillsoft_folder_ris_update for renaming and rillsoft_project_ris_save_as for changing a project's folder.

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 agent: renaming belongs to rillsoft_folder_ris_update, and moving a project to another folder belongs to rillsoft_project_ris_save_as. It also states the condition that selects this tool (reparenting/reordering a folder) and the constraint case (ris_folder_cycle).

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

Deploy Server