Kaiku

Set project field

set_project_field

Destructive

Add a column to a project, or edit the one that already has this name. Keyed by name rather than by id: 'make sure there is a Segment field with these options' is the request, and a name is what you just read. A field's KIND cannot be changed once it exists. Project lead or admin only.

Input Schema

Name	Required	Description
`icon`	No	The glyph that mark wears, from the palette list_project_fields returns. Not for a country field: that one marks a card with the flag of the country the issue holds, so passing an icon is refused rather than ignored.
`kind`	No	What it holds: 'text', 'number', 'date' (a day), 'datetime' (a day and a time, written like 2026-10-01T19:30+03:00), 'user', 'select' (a list), 'country' (a country, written as its name or its two-letter code and shown with a flag) or 'link' (issues and wiki pages, one or several — what a row is confirmed by). Required when creating; ignored when the field already exists, since a kind cannot change.
`name`	Yes	Field name, e.g. 'Segment'. An existing field with this name is edited rather than duplicated.
`newName`	No	Rename the field to this. Leave out to keep the name.
`options`	No	For a list: its options, as 'AI:green, Skins:orange, GameCards' or a JSON array of {name, color}. A colour is optional and must be one of: orange, amber, red, pink, purple, blue, teal, green. Options left out are REMOVED — send the whole set.
`showIcon`	No	Mark a board card when this field has a value: true to switch the mark on, false off. Leave out to keep it as it is.
`issueType`	No	Keep the field for issues of one type only, by name — e.g. 'Показ' — or '' for every type. Leave out to keep it as it is.
`projectKey`	Yes	Project key, e.g. 'CRM'.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / kind / description

Previous value: -"What it holds: 'text', 'number', 'date' (a day), 'datetime' (a day and a time, written like 2026-10-01T19:30+03:00), 'user', 'select' (a list) or 'country' (a country, written as its name or its two-letter code and shown with a flag). Required when creating; ignored when the field already exists, since a kind cannot change."New value: +"What it holds: 'text', 'number', 'date' (a day), 'datetime' (a day and a time, written like 2026-10-01T19:30+03:00), 'user', 'select' (a list), 'country' (a country, written as its name or its two-letter code and shown with a flag) or 'link' (issues and wiki pages, one or several — what a row is confirmed by). Required when creating; ignored when the field already exists, since a kind cannot change."

Changed2 schema fields changedSep 23, 2026

addedInput schema / properties / issueType

Added value: +{
+  "default": null,
+  "description": "Keep the field for issues of one type only, by name — e.g. 'Показ' — or '' for every type. Leave out to keep it as it is.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedInput schema / properties / kind / description

Previous value: -"What it holds: 'text', 'number', 'date', 'user', 'select' (a list) or 'country' (a country, written as its name or its two-letter code and shown with a flag). Required when creating; ignored when the field already exists, since a kind cannot change."New value: +"What it holds: 'text', 'number', 'date' (a day), 'datetime' (a day and a time, written like 2026-10-01T19:30+03:00), 'user', 'select' (a list) or 'country' (a country, written as its name or its two-letter code and shown with a flag). Required when creating; ignored when the field already exists, since a kind cannot change."

First observedSep 22, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, so the description's job is to add context, and it does: the auth requirement (project lead/admin) and the fact that a field's KIND is frozen after creation. Those are exactly the non-obvious behavioral facts an agent needs before calling. It doesn't spell out the destructive consequence of omitting options (that sits only in the schema), which keeps it from a 5.

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 core action before the addressing rationale and the constraints. The quoted example earns its place by illustrating upsert intent. Slightly conversational phrasing ("a name is what you just read") is the only minor cost.

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?

For an 8-parameter destructive upsert with no output schema, the description supplies the critical missing pieces: auth gating, kind immutability, and the create-or-edit rule. Return behavior is left implicit, but with no output schema that is a minor gap rather than a blocking one.

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 100%, so every parameter including icon, kind, options, showIcon and issueType is already documented in detail. The description only reinforces the name-keying and kind immutability; it adds no new semantics about the eight parameters. Baseline 3 applies when the schema carries the load.

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?

States a concrete verb pair and resource: "Add a column to a project, or edit the one that already has this name" — the upsert semantics are unambiguous. It also explains the name-keyed addressing rationale, which separates it from any id-based update path. It never names a sibling tool (e.g. delete_project_field or list_project_fields) as the alternative, so it falls short of a 5.

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?

Gives a real invoking scenario ("make sure there is a Segment field with these options") and makes the create-vs-edit decision automatic via the name key. It also states the permission prerequisite ("Project lead or admin only") and the immutability constraint on kind. It does not route the agent to a sibling for cases this tool cannot handle.

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

All Kaiku tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?