Skip to main content
Glama
Sign In
Kanbini

Kanbini

by Jigglyy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Make many changes at once

kanbini_batch

Apply many board changes in one atomic call: all steps succeed or none apply, and a single undo reverts them. Use to fill boards, tidy lists, or move and relabel many cards at once.

Instructions

Apply many changes in ONE call, as one change: all of them land or none do, and one Ctrl+Z in the app takes them all back. Use it whenever you would otherwise call write tools several times (filling a board, tidying a list, moving or relabelling many cards). steps (up to 200) run in order; each is { op, ...arguments } where op is a write tool name without kanbini_ (create_card, update_card, move_card, set_card_labels, archive_card, create_list, create_label, post_comment, create_checklist, ...) and the arguments are exactly that tool's. boardId (id or name) is the default board for every step, so steps can name cards by number (#142) and lists / labels by name without repeating it; a step may still pass its own. A step that creates something can take ref: "name", and later steps use "$name" wherever an id goes, e.g. [{ op: "create_list", name: "Sprint 4", ref: "s4" }, { op: "create_card", listId: "$s4", title: "Plan" }]. Lists and labels a step creates can also be named by their name later on. Attachments are not available here. Returns { changes, steps: [{ step, op, id, ref? }] } with the id of what each step changed or made. A failing step is reported by number and nothing is changed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "steps": "<steps>"
    },
    "name": "kanbini_batch"
  }
}

Input Schema

NameRequiredDescriptionDefault
stepsYes
boardIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.17.0

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full burden and does so: atomicity (all land or none), single-undo semantics in the app, ordered execution, a 200-step cap, failure reporting by step number, the return shape, and the attachment exclusion. These are exactly the traits an agent needs before committing a multi-step mutation.

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?

Atomicity and the use-when rule are front-loaded, and there is no filler — every clause carries new information. The sentences are long and heavily nested with parentheticals and inline examples, which makes it denser than necessary, though the example of the ref mechanism genuinely earns its space.

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?

There is no output schema, but the description states the return payload shape explicitly ({ changes, steps: [{ step, op, id, ref? }] }). Combined with the atomicity, ordering, ref-resolution and error semantics, an agent has everything needed to construct and interpret a call on a high-complexity batch tool.

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 coverage is 0% and the nested step objects accept additionalProperties, so the schema alone would leave the per-step arguments completely opaque. The description compensates by defining `op` as a write tool name stripped of the `kanbini_` prefix, stating that remaining arguments are exactly that tool's, explaining `ref`/`$name` cross-references with a worked example, and clarifying that `boardId` is a per-step default accepting ids or names.

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 — apply many changes in one call as a single atomic change — and immediately distinguishes itself from calling the individual write tools multiple times. The sibling tools in the list (kanbini_create_card, kanbini_move_card, etc.) are exactly the ones this wraps, and the description makes that relationship explicit.

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 an explicit when-to-use rule ('whenever you would otherwise call write tools several times') with concrete scenarios (filling a board, tidying a list, moving or relabelling many cards). It also names an exclusion — attachments are not available here — which routes the agent to kanbini_add_attachment for that case.

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