Skip to main content
Glama

Update card fields

kanbini_update_card

Update one or more fields on a Kanbini card, including title, description, due date, priority, completion, cover, repeat rule, or collapsed display; omit fields to leave them unchanged.

Instructions

Patch one or more card fields. title and description are strings; description accepts Markdown - use real line breaks for paragraphs and lists (a literal backslash-n renders as text, not a break). dueAt is epoch ms or null to clear. completed toggles the checkbox. coverAttachmentId is the attachment id to use as the cover banner, or null to clear. priority is one of 'low' | 'medium' | 'high' | 'urgent', or null to clear. collapsed only changes how the card is DRAWN in its list: true shows it compact (title, labels, one badge row), false keeps it full even in a compact list, null follows the list's cardDensity. It hides nothing from you - every read still returns the full card - so change it only when the user asks for a tidier board. repeat makes the card repeat: { unit: 'day' | 'week' | 'month' | 'year', every: 1-99 } (e.g. { unit: 'week', every: 2 } for every two weeks), or null to stop. When a repeating card is completed, the app adds the next one to the list it was worked in, due one repeat after the old due date (always in the future), with the same title, description, labels, priority, and unticked checklists; the rule moves to the new card. Omit fields you do not want to change.

Input Schema

NameRequiredDescriptionDefault
idYes
patchYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.13.0

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it documents that setting `repeat` causes the app to spawn a whole new card on completion, specifying the due-date rule (one repeat after the old due date, always future), which fields carry over, and that the rule moves to the new card. It also spells out null-as-clear semantics per field and the Markdown line-break pitfall, which are non-obvious mutation side effects no schema could 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?

Front-loaded with the core patch contract before field-by-field detail, and nearly every sentence adds an actionable fact. The repeat explanation runs long and the collapsed explanation is slightly over-explained, but neither is filler.

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 mutation tool with no annotations and no output schema, the description supplies everything an agent needs: patch semantics, per-field format rules, null-clearing behavior, and the cross-card side effect of repeating cards. Nothing material is missing to invoke it correctly.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry all meaning, and it does: every field in the nested patch object (title, description, dueAt, completed, coverAttachmentId, priority, collapsed, repeat) is explained with format or value semantics beyond the raw types — epoch ms for dueAt, the literal-backslash-n warning for description, the repeat object shape with a concrete example, and null-clearing for the nullable fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource: "Patch one or more card fields," which immediately distinguishes it from kanbini_create_card, kanbini_move_card and kanbini_archive_card. It doesn't explicitly say it is the generic partial updater vs. specialized setters like kanbini_set_card_labels, so it stops short of full sibling differentiation.

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?

"Omit fields you do not want to change" states the patch contract clearly, and the collapsed field gets explicit when-to-use guidance ("change it only when the user asks for a tidier board") plus a reassurance that it affects nothing else. It never points to sibling tools for moves, labels, or archiving, which would have made this a 5.

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