Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Save RIS project as

rillsoft_project_ris_save_as

DestructiveIdempotent

Create a new server project from the open project by saving it into a chosen folder; stores version 1 with optional notes or template flag.

Instructions

Stores the open single project - new, a local file or a project of the server - as a new project in a folder of the logged-in client on the Rillsoft Integration Server. Creates one new project with version 1 per call, even when called twice. The document becomes that server project afterwards: rillsoft_project_ris_save writes further versions, a former file path no longer applies; the command history is kept. The new project is held in the optimistic lock mode; reopen it with rillsoft_project_ris_open lock:pessimistic to lock it. A portfolio is refused; a local copy is written through rillsoft_project_file_save_as. Runs with the login of the desktop session and never asks for credentials. No undo step.

Input Schema

TableJSON Schema

Name	Required	Description
`notes`	No	version notes stored with the first version; at most 2000 characters
`folderId`	Yes	id of the folder on the server the new project goes into, from rillsoft_project_ris_list
`template`	No	true = store it as a template project (gets a new UUID); templates cannot be opened through MCP afterwards

Output Schema

TableJSON Schema

Name	Required	Description
`wbs`	Yes	WBS code
`lock`	Yes	lock mode of the open document
`name`	Yes	name
`note`	No	hints of the loader, such as a lock that was not granted; missing when there were none
`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
`clientId`	Yes	id of the client the project belongs to
`folderId`	Yes	id of the folder the project was stored in
`readOnly`	Yes	true = the document is read-only; rillsoft_project_ris_save refuses it
`projectId`	Yes	id of the project on the server
`versionId`	Yes	id of the version the document holds

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 destructive=true, readOnly=false and openWorld=true, yet the description adds genuinely non-redundant behavior: no undo step, history/command history retained, credentials are never requested (session login), the new project is created under optimistic locking, and the former file path is invalidated. The only soft spot is 'one new project with version 1 per call, even when called twice,' which sits uneasily with idempotentHint=true, though it plausibly means versions are not incremented rather than that repeat calls are rejected.

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-loaded with the action and destination, then layers on routing, lock state and side effects. It is long (seven sentences) but nearly every sentence carries distinct operational value; only the 'called twice' clause is fuzzy enough to cost a point.

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 three-parameter mutation tool with full schema descriptions, an output schema and rich annotations, the description supplies everything else an agent needs: safety profile context (no undo), auth behavior, post-save lock mode, and the sibling to use for the rejected cases. Nothing required for correct invocation 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%: folderId, notes and template are each documented in the schema itself (including the note that templates cannot be reopened through MCP). The description adds no parameter-level semantics beyond the schema, 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 ('Stores the open single project ... as a new project in a folder ... on the Rillsoft Integration Server') and distinguishes itself from near-identical siblings by name (rillsoft_project_ris_save for further versions, rillsoft_project_file_save_as for a local copy). An agent can pick this tool over rillsoft_project_ris_save or rillsoft_project_file_save_as without opening any schema.

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?

Explicit routing rules are given: portfolios are refused here, local copies go through rillsoft_project_file_save_as, and the created project is afterward managed with rillsoft_project_ris_save. It also tells the agent how to take ownership afterward (reopen with rillsoft_project_ris_open lock:pessimistic), which is exactly the when/where guidance an agent needs.

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

Deploy Server