Rillsoft Project MCP server

Official

by rillsoft

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Apply columns of the view

rillsoft_view_columns_apply

Read-onlyIdempotent

Adjust column visibility, width, and order in the project view. Show, hide, or resize columns to customize the display without altering project data.

Instructions

Shows, hides, sizes and arranges columns of the list on the left of the visible view - the same effect as the context menu of the column header, dragging its edge and the column arrangement dialog. Give order, columns or both; a call with neither is rejected. Under columns only the columns named are touched, and a column that already stands as asked is left alone, so the call can be repeated. Rejected in plain words: an unknown column name, hiding a column the context menu greys out, a width on a column that stays hidden ({ visible: true, width: X } in one entry shows it and sizes it in one go), and an order that leaves a column out or names one twice. The list at the bottom of a view with a second chart is not addressable. 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 column state is stored with the project, and going through the user interface marks the document as changed, so a later save writes it along. It answers like rillsoft_view_columns_get.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`order`	No	display order of the columns from left to right: the contract names of ALL columns of the view, each exactly once - the same array rillsoft_view_columns_get reports under order. This arranges the column headers; it does not sort the rows, and it does not show or hide anything - a hidden column keeps its place in the list and takes it up once it is shown. A list that leaves a column out or names one twice is rejected, never completed
`columns`	No	the columns to change - every column left out stays as it is. Each entry needs name and at least one of visible and width

Output Schema

TableJSON Schema

Name	Required	Description
`view`	Yes	name of the visible view the columns belong to
`order`	Yes	contract names of all columns from left to right - the arrangement of the column headers, not a sorting of the rows. Same sequence as columns[]; pass it back to rillsoft_view_columns_apply to restore the arrangement
`columns`	Yes	every column of the list in display order, hidden ones included

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 is true (no task, assignment or date moves, no undo step) while disclosing the non-obvious side effect that column state is persisted with the project and marks the document changed so a later save writes it. It also notes the second-chart bottom list is not addressable, and that the call is idempotent/repeatable.

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?

Dense but front-loaded: the effect is stated first, then the calling contract, then rejections, then behavioural notes. Some rejection detail overlaps the schema, but nearly every sentence carries information an agent needs to avoid an invalid call.

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?

An output schema exists so return values need not be described, and the description still notes the answer shape matches rillsoft_view_columns_get. Between the description, annotations and full schema coverage, an agent has everything needed to invoke this correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds cross-cutting semantics: order does not sort rows or change visibility, hidden columns keep their place, and showing plus sizing in one entry is allowed while hiding plus width is contradictory. This meaningfully clarifies how the two parameters interact.

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 precise verb set and resource: shows, hides, sizes and arranges columns of the visible view's left-hand list, and equates the effect to the column header context menu and drag behaviour. It is clearly distinct from rillsoft_view_columns_get, which it explicitly references as the reporting counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It spells out the calling contract (give order, columns, or both; neither is rejected) and enumerates rejected inputs in plain words. It also implies the read-first workflow by pointing at rillsoft_view_columns_get, but never states when to prefer this tool over sibling view tools such as rillsoft_view_state_apply or rillsoft_window_layout_apply.

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

Deploy Server