Skip to main content
Glama
depper-IA

Kommo Kiro MCP

by depper-IA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

update_stage

Idempotent

Change a Kommo pipeline stage's name, sort order, or color by providing the pipeline and stage IDs plus at least one new field; returns the updated stage.

Instructions

Change a stage's name, sort order, or color. Only the provided fields are sent; supply at least one of name, sort, or color. Returns the updated stage. Safe to repeat. Clears the stage and pipeline caches. Get IDs from list_stages.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoNew stage name.
sortNoNew sort position; lower values appear first (e.g. 10, 20).
colorNoNew hex color, e.g. #4CAF50, sent to Kommo as-is.
stage_idYesStage ID within that pipeline. Obtain it from list_stages.
pipeline_idYesKommo pipeline ID (integer). Obtain it from list_pipelines.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / color / description
      Added value: +"New hex color, e.g. #4CAF50, sent to Kommo as-is."
    • addedInput schema / properties / name / description
      Added value: +"New stage name."
    • addedInput schema / properties / pipeline_id / description
      Added value: +"Kommo pipeline ID (integer). Obtain it from list_pipelines."
    • addedInput schema / properties / sort / description
      Added value: +"New sort position; lower values appear first (e.g. 10, 20)."
    • addedInput schema / properties / stage_id / description
      Added value: +"Stage ID within that pipeline. Obtain it from list_stages."
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations cover safety (readOnly=false, idempotent=true, destructive=false), but description adds non-annotation context: partial updates only send provided fields, returns the updated stage, and clears stage/pipeline caches. That cache-invalidation and partial-update behavior is genuinely additive beyond structured fields.

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?

Front-loads the purpose and mutation fields, then the requirement, return value, idempotency, cache effect, and ID source in tight, waste-free sentences.

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?

Covers purpose, partial-update requirement, return value, idempotency, cache side effect, and ID acquisition despite no output schema. Minor gap: no error case if an invalid stage_id is passed, but the definition is otherwise complete for a small mutation tool.

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 coverage is 100% and already documents each parameter's meaning. The description adds only the partial-update constraint (at least one of name/sort/color), which is useful but the schema already carries the per-parameter detail; baseline 3 matches schema doing the heavy lifting.

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 (Change) and resource (a stage) plus the exact mutable fields (name, sort order, color). Distinguishes from sibling update_pipeline/update_lead by naming the stage entity and its unique attributes.

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?

Explicitly says at least one of name/sort/color must be supplied and routes ID retrieval to list_stages. Does not name which sibling to use instead, but the 'Get IDs from list_stages' dependency is clear context.

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