Skip to main content
Glama
tasklite-net

TaskLite MCP

by tasklite-net
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

update_column

Idempotent

Modify a column: rename it, change type (converts values), replace dropdown options, or set required/hidden. Incompatible values are cleared and reported.

Instructions

Change a column after the fact: rename it, change its type (e.g. number -> currency), replace settings (dropdown options), or set isRequired / isHidden. A type change converts existing values (number↔currency, text→number/date/checkbox, anything→text) and clears the ones that cannot convert; the response carries conversion: { converted, cleared }. settings.validation rules apply here too.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoHuman-readable name
typeNoNew column type (same list as create_column)
forceNoSkip the name/type sanity check
boardIdYesBoard id (from list_boards / create_board)
columnIdYesColumn id (from get_board_schema)
isHiddenNoHide the column in the TaskLite UI
settingsNoReplaces the column settings, e.g. { options: [...] } for dropdown/status
projectIdYesProject id (from list_projects / create_project)
isRequiredNoRequire a non-blank value on every App API create
descriptionNoFree-text description

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.13.0
    • addedInput schema / properties / boardId / description
      Added value: +"Board id (from list_boards / create_board)"
    • addedInput schema / properties / columnId / description
      Added value: +"Column id (from get_board_schema)"
    • addedInput schema / properties / description / description
      Added value: +"Free-text description"
    • addedInput schema / properties / isHidden / description
      Added value: +"Hide the column in the TaskLite UI"
    • addedInput schema / properties / isRequired / description
      Added value: +"Require a non-blank value on every App API create"
    • addedInput schema / properties / name / description
      Added value: +"Human-readable name"
    • addedInput schema / properties / projectId / description
      Added value: +"Project id (from list_projects / create_project)"
  2. First observedv0.7.0

TDQS

A4.6/5.0
Behavior5/5

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

The description goes well beyond the annotations by explaining the type-conversion behavior: existing values are converted where possible, unconvertible values are cleared, and the response contains conversion: { converted, cleared }. This is critical behavioral information, especially the data-clearing side effect, and the annotations alone would not convey it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is compact yet information-dense: it identifies the operation, gives concrete examples, explains conversion side effects, and mentions response content. There is no filler or redundant restatement of the tool name or schema.

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 there is no output schema, the description appropriately discloses the key return detail (the conversion result). It also covers the main mutation semantics. It does not fully explain the 'force' sanity check or the exact behavior of the settings object, but the schema provides partial context and the description covers the highest-risk behavior.

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?

The schema already covers all 10 parameters, so the baseline is 3. The description adds meaningful semantics by explaining how 'type' changes affect existing values and that 'settings' validation rules continue to apply, going beyond the simple property descriptions in the schema.

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?

The description clearly identifies the operation: changing an existing column after creation, and enumerates the concrete actions (rename, type change, settings replacement, isRequired/isHidden). This makes it easy to distinguish from siblings like create_column or update_board without needing to inspect schemas.

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?

The phrase 'after the fact' and the list of modifiable attributes make it clear this tool is for updating an existing column rather than creating one. It does not explicitly name alternatives or state when not to use it, but the context is strong enough for an agent to route correctly.

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

Deploy Server

Other Tools