kronos_bind_lead

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

Annotations already carry readOnlyHint=false, idempotentHint=true, and destructiveHint=false, lowering the bar. The description adds meaningful behavioral context beyond those hints: the exact HTTP endpoint, the fact that this is the sole integration path between the two systems, and the critical sequencing dependency (it consumes IDs produced by a prior kronos_create_event call). It doesn't cover error/failure modes or auth, but with annotations present, this is solid added value with no contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is compact and front-loaded: purpose in sentence one, usage context in sentence two, then conventional Args/Returns blocks. No filler or redundancy — the workflow sentence earns its place by capturing the sequencing constraint, and the Args block compensates for the schema coverage gap.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 3-parameter binding operation with a rich output schema, the description covers all essentials: purpose, endpoint, workflow prerequisite, parameter list, and return format ('JSON-ответ Кронос как есть'). Minor gaps are failure behavior and auth requirements, and the Russian-language description vs. English annotations is a small friction point, but nothing an agent needs to call the tool correctly is missing.

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

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

Schema description coverage is 0% at the top level, so the description must compensate — and it does by enumerating all three parameters (filial_id, lead_id, event_id), mapping lead_id to the amoCRM deal and event_id to the Kronos record, and stating all are required. The underlying schema properties do carry their own descriptions, so the description plus schema jointly define semantics well, though the description itself stays at label-level without adding constraints like the filial_id nuance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource statement: 'Привязать сделку amoCRM к записи Кронос' (bind an amoCRM deal to a Kronos record), plus the exact endpoint POST /api/v1/event/bind-lead. It further distinguishes the tool by declaring it 'единственный официальный мост' (the only official bridge) between amoCRM and Kronos — none of the sibling tools mention amoCRM binding, so an agent can disambiguate instantly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives explicit, prescriptive usage guidance: 'вызывайте его сразу после kronos_create_event' (call it immediately after kronos_create_event), naming the exact sibling and the required sequencing. It also states the exclusivity ('единственный официальный мост'), telling the agent not to seek alternatives. This is clear when-to-use guidance with a named prerequisite.

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