Kommo Kiro MCP

Overview Schema Source Related Servers Discussions Admin

create_custom_field

Add a custom field to Kommo CRM leads, contacts, or companies by specifying entity type, field type, and name. For select fields, provide enum_values; check existing fields first to avoid duplicates.

Instructions

Create a custom field on leads, contacts, or companies. Not idempotent: each call creates another field, so check list_custom_fields first. Returns the created field. Clears the custom-field cache for that entity. Provide enum_values for select-type fields.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Field display name.
`field_type`	Yes	Kommo field type sent as-is, e.g. text, numeric, select, multiselect, date, url, checkbox.
`entity_type`	Yes	Entity to add the field to: leads, contacts, or companies.
`enum_values`	No	Option labels for select or multiselect fields, in display order, e.g. ["Low", "High"]. Ignored by other types.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Field ID.
`code`	No	System field code, or null.
`name`	No	Field name.
`sort`	No	Sort order.
`type`	No	Field type, e.g. text, select.
`enums`	No	Options for select-like fields.
`_links`	No	HAL links as returned by Kommo (self, next, ...).
`account_id`	No	Kommo account ID.
`entity_type`	No	Entity the field belongs to.
`is_api_only`	No	Whether the field is API only.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.0.3Oct 3, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "The created custom field.",
+  "properties": {
+    "_links": {
+      "additionalProperties": true,
+      "description": "HAL links as returned by Kommo (self, next, ...).",
+      "properties": {},
+      "type": "object"
+    },
+    "account_id": {
+      "description": "Kommo account ID.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "code": {
+      "description": "System field code, or null.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "entity_type": {
+      "description": "Entity the field belongs to.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "enums": {
+      "description": "Options for select-like fields.",
+      "items": {
+        "additionalProperties": true,
+        "description": "One option.",
+        "properties": {},
+        "type": "object"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "id": {
+      "description": "Field ID.",
+      "type": "integer"
+    },
+    "is_api_only": {
+      "description": "Whether the field is API only.",
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "name": {
+      "description": "Field name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "sort": {
+      "description": "Sort order.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "type": {
+      "description": "Field type, e.g. text, select.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedOct 3, 2026

changedInput schema / properties / entity_type / description

Previous value: -"leads, contacts, or companies"New value: +"Entity to add the field to: leads, contacts, or companies."

changedInput schema / properties / enum_values / description

Previous value: -"Values for select/multiselect fields"New value: +"Option labels for select or multiselect fields, in display order, e.g. [\"Low\", \"High\"]. Ignored by other types."

changedInput schema / properties / field_type / description

Previous value: -"text, numeric, select, multiselect, date, url, checkbox"New value: +"Kommo field type sent as-is, e.g. text, numeric, select, multiselect, date, url, checkbox."

changedInput schema / properties / name / description

Previous value: -"Field name"New value: +"Field display name."

First observedv1.0.0Oct 3, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral facts beyond them: the tool returns the created field and clears the custom-field cache for that entity, which is a side effect an agent cannot infer from the annotations.

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?

Four short sentences, each carrying a distinct fact (action, non-idempotency plus remedy, return value, cache side effect, parameter hint), with the core action front-loaded. No filler or restatement of the title.

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 a mutation tool with an output schema present, the description covers the essentials an agent needs: the write nature, the non-idempotency, the duplicate-check prerequisite, the cache invalidation, and the enum_values hint. Nothing critical is missing, though it does not mention auth or rate-limit considerations.

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 the schema already explains name, field_type, entity_type and enum_values in detail, including that enum_values is ignored by non-select types. The description's only added parameter guidance ('Provide enum_values for select-type fields') largely restates the schema, so the baseline of 3 applies.

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 (create a custom field) and scopes it to the three supported entities (leads, contacts, companies). It is immediately distinguishable from read-only siblings like get_lead or list_custom_fields because it declares itself a creator and names list_custom_fields as the inspection counterpart.

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 an explicit precondition: check list_custom_fields first because each call creates another field. That is real when-to-use guidance tied to an alternative. It stops short of a full when-not case (e.g. how to modify an existing field), but the routing intent is clear.

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