Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

List RIS documents

rillsoft_document_ris_list

Read-onlyIdempotent

Lists documents held in the Rillsoft Integration Server DMS for the open project, including the client folder tree. Filter by task, subproject, or project UUID to see only the documents attached to that element.

Instructions

Lists the documents the document management (DMS) of the Rillsoft Integration Server holds for the open project - files hanging on a task, a subproject or the project itself - together with the DMS folder tree of the client. In an open RIS portfolio it lists the documents of every loaded project (each names its projectId; the answer carries portfolioId), and downloading, updating and deleting work there too - only creating is refused, as in the documents dialog. Each document names the element it hangs on (uuid), its folder (folderId, folderPath) and the documentId the other document tools take. Requires a project opened from the server (rillsoft_project_ris_open) or stored there (rillsoft_project_ris_save_as); a new or file-based project has no documents. Reads the server every time; runs with the login of the desktop session. Read-only, no undo step. Not to be confused with the project files rillsoft_project_file_open handles.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uuid`	No	UUID of a task, subproject or the project itself: only the documents hanging on that element; missing = every document of the project

Output Schema

TableJSON Schema

Name	Required	Description
`server`	Yes	URL of the Rillsoft Integration Server the desktop session is logged in to
`folders`	Yes	the DMS folder tree of the client, root first
`clientId`	Yes	id of the logged-in client; -1 while none is selected
`userName`	Yes	user name of the desktop session
`documents`	Yes	the documents of the open project, or of the one element given by uuid; at most 10000, more than that is an error
`projectId`	Yes	id of the open project on the server; -1 while a portfolio is open, each document then names its own
`portfolioId`	No	id of the open portfolio on the server; only while a RIS portfolio is open

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 read-only, idempotent, non-destructive, open-world. The description adds real value beyond them: it reads the server every call, runs with the desktop session login, and has no undo step. It also explains the portfolio-vs-project output difference (portfolioId returned, projectId per project). It does not discuss auth failure modes or result size/pagination, keeping it from 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Information-dense but long-winded, with heavy em-dash clauses and interleaved portfolio, download, prerequisite and output details. The core 'what it lists' is front-loaded, but the middle sentences ramble and could be tightened without losing content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists, the description needn't enumerate return fields, yet it usefully names the identifying fields (uuid, folderId, folderPath, documentId). With a single optional param, annotations, and output schema, the description covers the prerequisites and portfolio edge cases an agent needs; only failure/auth specifics are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

Schema coverage is 100%, so the schema documents the uuid parameter fully. The description reinforces the semantics by explaining that omitting uuid returns every document, and that each returned document carries uuid/folderId/folderPath/documentId – meaningfully linking the parameter to the output.

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 ('Lists the documents the DMS... holds') and scopes it to the open project, including which elements documents hang on. Explicitly distinguishes itself from the sibling rillsoft_project_file_open and from the document create tool, so an agent can route correctly.

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 explicit prerequisites (project must be opened via rillsoft_project_ris_open or saved via rillsoft_project_ris_save_as; new/file-based projects have none) and states what is and isn't supported in a portfolio (read/update/delete work, create is refused). Names the sibling not to be confused with.

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

Deploy Server