Skip to main content
Glama
depper-IA

Kommo Kiro MCP

by depper-IA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

bulk_update_leads

Idempotent

Update multiple Kommo leads in one PATCH request, merging each lead ID with its fields and returning the batch response.

Instructions

Update many leads in a single PATCH /leads request. Each item merges its fields with the lead id and uses the same field keys as update_lead. Returns the Kommo response for the batch. Use update_lead for a single lead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leads_updatesYesUpdates to apply, one per lead. Example: [{"id": 123, "fields": {"status_id": 456}}].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / leads_updates / description
      Previous value: -"Array of {id, fields} objects"New value: +"Updates to apply, one per lead. Example: [{\"id\": 123, \"fields\": {\"status_id\": 456}}]."
    • addedInput schema / properties / leads_updates / items / properties / fields / description
      Added value: +"Raw Kommo v4 lead fields to change for this lead (see update_lead)."
    • addedInput schema / properties / leads_updates / items / properties / id / description
      Added value: +"Kommo lead ID (integer). Obtain it from list_leads or from the create_lead result."
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the request is a single PATCH /leads, each element is merged from id + fields, and the batch Kommo response is returned. It stops short of describing partial-failure or invalid-ID behavior.

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 distinct information: transport, item composition, return value, and the sibling alternative. Nothing is redundant and the key facts are front-loaded.

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?

No output schema exists, but the description states what the tool returns (the Kommo batch response), and the single nested parameter is well documented in both schema and prose. Only batch limits and error semantics are left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description goes further by explaining how each array item is composed (fields merged with id) and cross-references update_lead for valid field keys, which the schema only alludes to.

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 ("Update many leads") plus the exact transport (PATCH /leads), making the batch nature explicit. It explicitly distinguishes itself from update_lead, so an agent can choose between them without opening either schema.

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?

The closing sentence "Use update_lead for a single lead" gives an explicit routing rule to the nearest sibling. It does not cover any when-not conditions such as maximum batch size, partial-failure tolerance, or rate limits, but the core selection guidance is clear.

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