Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Apply row selection

rillsoft_row_selection_apply

Read-onlyIdempotent

Selects a row in the visible resource or capacity view, scrolls it into view, and syncs the property sheet. For a task under that row, pass taskUuid.

Instructions

Selects one row of the visible resource or capacity view - the same effect as clicking it. The row is scrolled into view and the property sheet of the info window follows, exactly as it does on a click. A row whose parent is collapsed is not addressable; open it first through rillsoft_outline_apply. In any other view the call fails and points at rillsoft_view_state_apply. No undo step and no change to the plan itself - no task, no assignment, no date moves; that is why this tool counts as read-only. What it does change is the way the project is displayed: the selected row is stored with the project, and going through the user interface marks the document as changed, so a later save writes it along. Pass taskUuid inside row to select a task listed under that row instead of the row itself - the detail rows have no coordinate of their own, they hang below their group row; that is what makes the gantt secondary view show the task with its links. It answers like rillsoft_row_selection_get.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`row`	Yes	coordinates of the row to select, as rillsoft_outline_get reports them under openRows; add taskUuid to select a task listed under that row instead

Output Schema

TableJSON Schema

Name	Required	Description
`row`	No	coordinates of the selected row; missing when none is selected
`level`	No	zero-based grouping level of the selected row; missing when none is selected
`selected`	Yes	false = no row is selected; then row is missing

Schema Changelog

Changes observed during successful MCP inspections.

First observedv10.0.626Oct 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the scroll-into-view side effect, that a collapsed parent row is not addressable, that there is no undo step, and that despite being read-only it persists the selection into the project so a later save writes it along. It even reconciles that nuance with the readOnlyHint annotation, which is exactly the kind of context annotations cannot 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 behavior is front-loaded and every sentence carries substance, but the passage is long and the closing 'It answers like rillsoft_row_selection_get' is somewhat redundant given an output schema exists. Dense rather than bloated, but not maximally tight.

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 nested-object selection tool it covers prerequisites, failure conditions, side effects, and persistence behavior, and an output schema already carries return shape. An agent has everything needed to call it correctly in one pass.

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 already 100%, so the baseline is 3, but the description adds real meaning: it explains *why* taskUuid selects a detail row ('the detail rows have no coordinate of their own, they hang below their group row') and the downstream effect on the gantt secondary view. It largely reinforces schema text rather than introducing new format details.

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 ('Selects one row of the visible resource or capacity view') and anchors it to a familiar user action ('the same effect as clicking it'). It explicitly differentiates itself from siblings by naming rillsoft_row_selection_get, rillsoft_outline_apply, and rillsoft_view_state_apply.

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 when-to-use context, names the failure case ('in any other view the call fails and points at rillsoft_view_state_apply'), and names the prerequisite path for collapsed parents ('open it first through rillsoft_outline_apply'). Alternatives are surfaced rather than left to inference.

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

Deploy Server