Kommo Kiro MCP

Overview Schema Source Related Servers Discussions Admin

update_contact

Idempotent

Modify fields on an existing Kommo contact by ID, overwriting only the values you send while leaving all other contact fields unchanged.

Instructions

Update fields on an existing contact by sending fields as the body of a Kommo API v4 PATCH /contacts/{id}. Returns the updated contact. Provided values overwrite existing ones; omitted fields are untouched.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`fields`	Yes	Raw Kommo v4 contact fields to change, passed through unchanged. Common keys: name, first_name, last_name, responsible_user_id, custom_fields_values (array of {field_id, values: [{value, enum_code}]}; field IDs from list_custom_fields). Example: {"name": "Jane Roe"}.
`contact_id`	Yes	Kommo contact ID (integer). Obtain it from list_contacts or from the create_contact result.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	No	Contact ID.
`name`	No	Full name.
`_links`	No	HAL links as returned by Kommo (self, next, ...).
`group_id`	No	ID of the responsible user's group.
`_embedded`	No	Embedded tags and companies.
`last_name`	No	Last name.
`account_id`	No	Kommo account ID.
`created_at`	No	Creation time, Unix seconds.
`created_by`	No	ID of the user who created it.
`first_name`	No	First name.
`updated_at`	No	Last update time, Unix seconds.
`updated_by`	No	ID of the user who last updated it.
`closest_task_at`	No	Next task deadline, Unix seconds, or null.
`responsible_user_id`	No	ID of the responsible Kommo user.
`custom_fields_values`	No	Custom field values in Kommo format: objects with field_id, field_code and values.

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 updated contact as returned by Kommo.",
+  "properties": {
+    "_embedded": {
+      "additionalProperties": true,
+      "description": "Embedded tags and companies.",
+      "properties": {
+        "tags": {
+          "description": "Embedded tags.",
+          "items": {
+            "additionalProperties": true,
+            "description": "A Kommo tag.",
+            "properties": {
+              "color": {
+                "description": "Tag color, or null.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "id": {
+                "description": "Tag ID.",
+                "type": "integer"
+              },
+              "name": {
+                "description": "Tag name.",
+                "type": [
+                  "string",
+                  "null"
+                ]
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        }
+      },
+      "type": "object"
+    },
+    "_links": {
+      "additionalProperties": true,
+      "description": "HAL links as returned by Kommo (self, next, ...).",
+      "properties": {},
+      "type": "object"
+    },
+    "account_id": {
+      "description": "Kommo account ID.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "closest_task_at": {
+      "description": "Next task deadline, Unix seconds, or null.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "created_at": {
+      "description": "Creation time, Unix seconds.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "created_by": {
+      "description": "ID of the user who created it.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "custom_fields_values": {
+      "description": "Custom field values in Kommo format: objects with field_id, field_code and values.",
+      "items": {
+        "additionalProperties": true,
+        "description": "One custom field with its values.",
+        "properties": {},
+        "type": "object"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "first_name": {
+      "description": "First name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "group_id": {
+      "description": "ID of the responsible user's group.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "id": {
+      "description": "Contact ID.",
+      "type": "integer"
+    },
+    "last_name": {
+      "description": "Last name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "name": {
+      "description": "Full name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "responsible_user_id": {
+      "description": "ID of the responsible Kommo user.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "updated_at": {
+      "description": "Last update time, Unix seconds.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "updated_by": {
+      "description": "ID of the user who last updated it.",
+      "type": [
+        "integer",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed2 schema fields changedOct 3, 2026

addedInput schema / properties / contact_id / description

Added value: +"Kommo contact ID (integer). Obtain it from list_contacts or from the create_contact result."

changedInput schema / properties / fields / description

Previous value: -"Fields to update"New value: +"Raw Kommo v4 contact fields to change, passed through unchanged. Common keys: name, first_name, last_name, responsible_user_id, custom_fields_values (array of {field_id, values: [{value, enum_code}]}; field IDs from list_custom_fields). Example: {\"name\": \"Jane Roe\"}."

First observedv1.0.0Oct 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, and openWorld=true. The description adds meaningful context beyond them: it is a merge-style PATCH where provided values overwrite and omitted fields are untouched, which tells the agent it will not clobber unspecified fields. It does not cover auth requirements or error behavior, keeping it short of 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences, front-loaded with the action and endpoint, followed by return value and mutation semantics. Every sentence carries information with no 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?

An output schema exists so return values need not be detailed, and the description still notes the updated contact is returned. With full schema coverage, annotations covering the safety profile, and overwrite/merge semantics stated, nothing needed to invoke it correctly is missing.

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 both parameters are already well documented in the schema, including the fields object shape and example. The description adds only that `fields` is sent as the PATCH body unchanged, which is marginal beyond the schema. Baseline 3 is appropriate.

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 states a specific verb and resource ("Update fields on an existing contact") and pins the exact API surface (PATCH /contacts/{id}), so the agent knows precisely what it does. It does not explicitly contrast itself with create_contact or get_contact, so it falls 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 Guidelines3/5

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

Usage is implied by "existing contact" (not a create) and the overwrite/omit semantics, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as create_contact for new records. Adequate but with clear gaps.

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