Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Open portfolio file

rillsoft_portfolio_file_open

DestructiveIdempotent

Open one .rpp portfolio file to replace current project with multiple project files. Returns project list, skipped entries, and notes; use project file open for a single .rpj.

Instructions

Opens exactly one file portfolio (.rpp), which is a list of project files, and replaces the current project. A single project file (.rpj) is refused; rillsoft_project_file_open covers that. The answer carries portfolio:true and projects[] (uuid, name, path, readOnly); lines of the .rpp that point nowhere end up in skipped[], anything else the loader has to say in note. Inside a portfolio the tools work as in a single project, with the limits of the user interface: nothing is created directly below the portfolio, no task or subproject changes its project, no dependency crosses the project boundary in a file portfolio, no baseline, no 'save as'; rillsoft_portfolio_project_files_save writes the changed projects back. No undo step.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes	absolute path of an .rpp portfolio file
`discardChanges`	No	true = discard unsaved changes of the current project

Output Schema

TableJSON Schema

Name	Required	Description
`wbs`	Yes	WBS code
`name`	Yes	name
`note`	No	hints about opening; missing when there were none
`path`	Yes	path of the file that was opened
`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
`skipped`	No	parts that were not loaded; missing when nothing was skipped
`projects`	No	the projects it contains; only for a portfolio
`portfolio`	Yes	true = a portfolio was opened

Schema Changelog

Changes observed during successful MCP inspections.

First observedv10.0.626Oct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint/readOnlyHint, but the description adds substantive behavior: the current project is replaced wholesale, the .rpp is refused if it is a single project, there is no undo, and inside a portfolio no creation below the portfolio, no cross-boundary dependencies, no baseline and no 'save as' are permitted. This is well beyond what annotations convey.

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?

The core action and the sibling split are front-loaded in the first two sentences, and the remaining sentences each carry a distinct constraint. It is dense and long, but little of it is filler.

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 destructive, state-replacing open operation, the description covers refusal behavior, the no-undo consequence, portfolio-specific limits, and the follow-up save tool. Return fields (portfolio:true, projects[], skipped[], note) are restated even though an output schema exists, but the coverage is otherwise complete.

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 coverage is 100%, so both parameters are already documented in the schema; the description only implies that path must point at an .rpp rather than an .rpj. Baseline 3 applies when the schema carries the parameter documentation.

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 ('Opens exactly one file portfolio (.rpp)') plus the scope caveat that it 'replaces the current project'. It explicitly distinguishes itself from rillsoft_project_file_open by noting that a .rpj is refused and that the sibling covers it.

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?

Gives an explicit when-not rule (.rpj is refused, use rillsoft_project_file_open) and names the companion write path (rillsoft_portfolio_project_files_save). It also warns 'No undo step', which directly shapes call decisions.

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

Deploy Server