Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Apply outline state of one row

rillsoft_outline_row_apply

Read-onlyIdempotent

Expands or collapses one group row in the resource or capacity view while leaving all other rows unchanged; useful for step-by-step outline navigation.

Instructions

Opens or closes one single group row of the visible resource or capacity view - the same effect as clicking the plus or minus in front of it. Every other row keeps its state, which is what sets this apart from rillsoft_outline_apply. Rows that become visible this way can be opened the same way, level by level. A row already in the wanted state is left alone and reported back, so the call can be repeated. A row whose parent is still closed is not addressable; open the parent first. In any other view the call fails and points at rillsoft_view_state_apply. Like a click it moves the selection to that row and the property sheet of the info window follows. 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 outline state is stored with the project, and going through the user interface marks the document as changed, so a later save writes the new state along. It answers like rillsoft_outline_get.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`row`	Yes	coordinates of the group row to open or close, as rillsoft_outline_get reports them under openRows
`action`	Yes	expand opens the row, collapse closes it

Output Schema

TableJSON Schema

Name	Required	Description
`levels`	Yes	the grouping levels of the view, outermost first
`outline`	Yes	the absolute state where the view is in one, otherwise mixed
`openRows`	Yes	every group row that is open, in display order. Pass the array back to rillsoft_outline_apply to restore exactly this state
`canExpand`	Yes	true = something is still left to expand
`canCollapse`	Yes	true = something is still left to collapse

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?

Goes well beyond the annotations: it explains why readOnlyHint=true is not contradictory (no task/assignment/date changes, no undo step) while still disclosing the side effect that outline state is persisted with the project and marks the document as changed, so a later save writes it. It also confirms idempotency behavior and notes the selection and property sheet follow, like a click.

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 core action and the sibling differentiation, and nearly every sentence carries information. It is on the long side, with some restatement around the read-only rationale ('no task, no assignment, no date moves'), which costs 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 two-parameter, nested-object tool with an output schema and full annotation coverage, the description covers behavior, prerequisites, side effects, failure routing and return shape reference ('answers like rillsoft_outline_get'). Nothing an agent needs to invoke it correctly 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% and the nested row object documents every coordinate field, so the baseline is 3. The description adds contextual meaning about addressability (parent must be open) but no new syntax or format detail for the parameters themselves.

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 or closes one single group row of the visible resource or capacity view, equivalent to clicking the plus/minus. It explicitly contrasts itself with rillsoft_outline_apply, so the agent can separate the two without opening either 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?

Gives explicit when-to-use (single row vs rillsoft_outline_apply's whole-outline effect), prerequisites (a row whose parent is closed is not addressable; open the parent first), and a failure route (other views fail and point at rillsoft_view_state_apply). Nothing is 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