Kaiten MCP

Overview Schema Source Related Servers Discussions Admin

kaiten_create_card

Create a new card on a Kaiten board by providing a title and board ID, with optional lane, column, owner, due date, Markdown description, and custom property values.

Instructions

Create a card on a board. Description uses Markdown. Optional properties use Kaiten id_ keys.

Input Schema

Name	Required	Description	Default
`asap`	No
`title`	Yes
`lane_id`	No
`type_id`	No
`board_id`	Yes
`due_date`	No
`owner_id`	No
`column_id`	No
`size_text`	No
`properties`	No
`description`	No
`due_date_time_present`	No

Output Schema

Name	Required	Description	Default
`item`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedv1.2.0Nov 3, 2026

removedInput schema / properties / board_id / maximum
```
Removed value: -9007199254740991
```
removedInput schema / properties / column_id / maximum
```
Removed value: -9007199254740991
```

changedInput schema / properties / due_date / anyOf

Previous value: -[
-  {
-    "anyOf": [
-      {
-        "format": "date",
-        "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
-        "type": "string"
-      },
-      {
-        "format": "date-time",
-        "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
-        "type": "string"
-      }
-    ]
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "anyOf": [
+      {
+        "format": "date",
+        "type": "string"
+      },
+      {
+        "format": "date-time",
+        "type": "string"
+      }
+    ]
+  },
+  {
+    "type": "null"
+  }
+]

removedInput schema / properties / lane_id / maximum
```
Removed value: -9007199254740991
```
removedInput schema / properties / owner_id / maximum
```
Removed value: -9007199254740991
```
removedInput schema / properties / type_id / maximum
```
Removed value: -9007199254740991
```

addedOutput schema / properties / item / properties / children

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "archived": {
+        "type": "boolean"
+      },
+      "board_id": {
+        "type": "number"
+      },
+      "column_id": {
+        "type": "number"
+      },
+      "condition": {
+        "type": "number"
+      },
+      "due_date": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "id": {
+        "type": "number"
+      },
+      "lane_id": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "owner_id": {
+        "type": "number"
+      },
+      "state": {
+        "type": "number"
+      },
+      "title": {
+        "type": "string"
+      },
+      "updated": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "title",
+      "board_id",
+      "column_id"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / item / properties / external_links

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "card_id": {
+        "type": "number"
+      },
+      "created": {
+        "type": "string"
+      },
+      "description": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "external_link_id": {
+        "type": "number"
+      },
+      "id": {
+        "type": "number"
+      },
+      "updated": {
+        "type": "string"
+      },
+      "url": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "url"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / item / properties / parents

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "archived": {
+        "type": "boolean"
+      },
+      "board_id": {
+        "type": "number"
+      },
+      "column_id": {
+        "type": "number"
+      },
+      "condition": {
+        "type": "number"
+      },
+      "due_date": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "id": {
+        "type": "number"
+      },
+      "lane_id": {
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "owner_id": {
+        "type": "number"
+      },
+      "state": {
+        "type": "number"
+      },
+      "title": {
+        "type": "string"
+      },
+      "updated": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "title",
+      "board_id",
+      "column_id"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedv1.0.2Oct 7, 2026

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the write/non-idempotent profile is covered. The description adds nothing beyond that: it does not mention that unrecognized fields are rejected (additionalProperties: false), that properties keys must match the id_<propertyId> pattern or the call will fail validation, what permissions are needed, or that a duplicate title on the same board will create a second card.

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?

Three short sentences, front-loaded with the action, with no filler or redundancy. It is efficient, though its brevity is partly the cause of the documentation gaps rather than a virtue.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter creation tool with a nested free-form properties object, zero schema descriptions, and validation constraints (positive integers, id_ key pattern, additionalProperties: false), the description leaves too much undocumented. The presence of an output schema means return values need no explanation, but the input side is substantially underspecified.

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 0% across 12 parameters, so the description must carry the semantics, and it only explains two things: description accepts Markdown and properties uses id_<propertyId> keys. That is genuinely useful non-obvious information (the pattern constraint and Markdown support), but the other ten parameters — lane_id, column_id, type_id, owner_id, due_date, due_date_time_present, asap, size_text — get no explanation, and the interplay between due_date and due_date_time_present is unexplained.

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?

The description names a specific verb and resource ("Create a card on a board"), which is unambiguous and easily distinguished from siblings like kaiten_update_card, kaiten_move_card, or kaiten_delete_card. It stops short of stating scope or when the create path is preferred over other sibling flows, but the core purpose is clear.

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

Usage Guidelines2/5

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

There is no when-to-use guidance: nothing about when to create versus update, no mention that board_id is required and typically obtained from kaiten_list_boards, and no note about needing a valid lane/column/type id resolved via kaiten_list_lanes, kaiten_list_columns, or kaiten_list_card_types. The agent must infer all of this from the schema and sibling list.

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

Deploy Server