Skip to main content
Glama
Sign In
A1 Yandex KIT MCP

A1 Yandex KIT MCP

by ztemerbekov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Create webhook

create_webhook

Creates an HTTPS webhook for Yandex KIT order, payment, delivery, customer, or cart events; returns a one-time signing secret to verify callback authenticity.

Instructions

Create a new webhook. The url must use HTTPS (HTTP is rejected). Allowed events: ORDER_STATUS_CHANGED, ORDER_PAYMENT_STATUS_CHANGED, ORDER_DELIVERY_STATUS_CHANGED, CUSTOMER_CHANGED, CART_UPDATED. CUSTOMER_CHANGED fires when a customer appears or their name/phone/email changes; its data carries only {customer_id}, so a CRM sync must follow up with get_customer to read the new values (no before/after diff is delivered). CART_UPDATED fires when a customer changes their cart (clearing included); data is only {customer_id}, a series of changes to one cart collapses into one event, sent at most once per 15 minutes and up to 15 minutes late — read the current contents with get_customer_cart when handling it. NOTE: ORDER_STATUS_CHANGED will stop firing for the receipt-technical statuses CREATING_INITIAL_RECEIPT and CREATING_FINAL_RECEIPTS — key new integrations on ORDER_PLACED and COMPLETED instead (the statuses themselves stay readable via get_order). IMPORTANT: the response contains the signing secret — it is shown ONLY ONCE, store it securely. Call get_operation_schema("CreateWebhook") for the exact request shape.

Input Schema

NameRequiredDescriptionDefault
webhookYesWebhook record matching the CreateWebhookRequest schema (see get_operation_schema("CreateWebhook")). Required: url (HTTPS only), events.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses HTTPS-only validation, event semantics, CART_UPDATED aggregation, ORDER_STATUS_CHANGED deprecation for receipt statuses, and the one-time signing secret. It stops short of permissions, idempotency, and failure modes.

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?

Information-dense and front-loaded with purpose and constraints, but the single paragraph packs many semicolon-separated clauses. All content is relevant; slightly better structure would earn a 5.

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 create mutation with a nested object and no output schema, it provides critical return info (secret shown once), event behavior, and a pointer to get_operation_schema. Missing optional webhook fields and failure modes keep it from 5.

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 coverage is 100%, so baseline is 3, but the description adds HTTPS requirement and enumerated event names plus event data semantics beyond the generic 'webhook' object schema. It does not document optional fields like name or active, instead pointing to get_operation_schema.

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 new webhook') plus key constraints, so the agent knows exactly what operation is performed. The create vs update distinction is implicit but unambiguous from the title and description.

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?

Implies usage when creating a webhook with the listed events and HTTPS, but never mentions validate_webhook or update_webhook as alternatives or when to prefer them. The get_operation_schema pointer is a step, not selection guidance.

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