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.

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description discloses critical runtime behavior: the max_count field has no lower-bound validation and callers must enforce minimum group size, the success response is an undocumented JSON string with an expected id, and error handling details exact HTTP failure patterns. This goes well beyond what annotations convey.

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?

Although long, every section earns its place: purpose, numbered scenarios, required args, return format, and error handling. It is front-loaded with the main purpose and uses clear structure (Args, Returns, Error Handling) plus a prominent ВАЖНО warning, making it easy for an agent to scan.

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?

The description is complete for a complex creation tool: it covers three concrete scenarios, required versus optional fields, the undocumented response shape, and the two main error modes. It effectively closes the gaps left by annotations and the input schema, giving an agent everything needed to invoke the tool correctly.

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?

The input schema already documents each field in detail, so the description does not need to repeat them. It adds meaningful scenario-to-parameter mappings (which fields belong to which booking type) and reiterates the max_count caveat. This is above the baseline because it explains how to combine parameters, not just what each parameter means.

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 concrete verb and resource: 'Создать запись (бронь) в Кронос, POST /api/v1/event.' It clearly states the tool creates a Kronos booking and differentiates the three supported creation scenarios, which separates it from sibling tools that list, get, update, or delete events.

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 scenario-based usage: individual booking, group event, and child booking, with required and forbidden field combinations for each (e.g., is_group=True without order/contact). It also warns that is_group=True with contact yields HTTP 400. It does not explicitly name alternative sibling tools, so it falls just short of full exclusion guidance.

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

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

Annotations already set destructiveHint=true and idempotentHint=true, so the description's statement 'Безвозвратно' (irreversibly) adds the permanence nuance beyond the annotation. It also clarifies the hard-delete vs. soft-cancel distinction, which is valuable behavioral context not captured by the annotations alone.

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 concise: two clear functional sentences plus compact Args/Returns sections. The purpose is front-loaded, and the alternative is mentioned early. The Args/Returns repetition is minor and does not bloat the text, so it remains effectively structured.

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?

Given the presence of an output schema (the return is just a raw JSON string) and the explicit usage guidance, the description covers the essential operational context. It explains when to use this vs. the alternative and notes the destructive nature, leaving no critical gap for safe invocation.

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?

The description merely lists the parameter names (filial_id, event_id) and marks them required, which duplicates the schema's required list. However, the schema already provides richer descriptions for each field (e.g., event_id explains hard vs. soft delete and filial_id explains scope), so the description adds little beyond the schema. Baseline 3 is appropriate for high effective schema coverage.

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 clearly states the action ('Безвозвратно удалить запись', permanent deletion) and the resource (event via DELETE /api/v1/event/{id}). It distinguishes itself from the sibling kronos_update_event by explicitly contrasting the hard delete with the soft-cancel alternative, so an agent can tell them apart at a glance.

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 provides an explicit when-to-use rule: prefer kronos_update_event with status_id=0 for ordinary cancellations to preserve history, and use this only when the record must disappear entirely (e.g., erroneous creation). This clear guidance leaves no ambiguity about selecting among siblings.

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

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

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds worthwhile behavioral context: it returns only free slots filtered by the API, and it returns the vendor JSON raw with an undocumented response format. That goes beyond the structured hints without contradicting them.

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 well structured: purpose and differentiation first, followed by a compact Args block, a Returns caveat, and concrete Usage examples. Every section earns its place and no filler is present.

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 read-only availability lookup, the description covers the endpoint, main use case, sibling distinction, parameter summary, raw return behavior, and example requests. With annotations already covering safety and idempotency, nothing essential 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?

Although the signal reports 0% schema description coverage, the nested schema actually documents each parameter, and the description enumerates all five parameters with requiredness, defaults, and ranges. It also adds the context that resource_id is the list used for showing client availability, which helps the agent select values.

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 pair ('Получить только СВОБОДНЫЕ слоты времени') and the API endpoint. It explicitly contrasts with sibling kronos_get_time_slots by noting occupied slots are already filtered out, so the tool's purpose is unambiguous and well-differentiated.

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 contains explicit 'Use when' / 'Don't use when' guidance with a concrete example and names the exact alternative tool (kronos_get_time_slots) for the opposite need. This leaves no doubt about when to select this tool versus its siblings.

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

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

The annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the endpoint and purpose but doesn't add significant behavioral context beyond that, such as pagination or response format details. Given the annotations carry most of the burden, a 3 is appropriate for the additional context about usage dependency.

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 concise and front-loaded with the purpose and endpoint, then immediately gives usage guidance. The Args and Returns sections are minimal but clear. It avoids unnecessary verbosity, though the Args section could be redundant with the schema, but it's still compact.

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?

The tool is a simple read operation with only two parameters, and the description covers its purpose, endpoint, and usage dependency. The output schema exists (though not shown in detail), so return value explanation isn't needed. The description omits potential edge cases like error handling or authentication, but for a straightforward read tool with clear annotations, it's sufficiently complete.

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%, so the description must compensate. The description mentions 'filial_id, account_id (обязательны)' but provides no further explanation beyond what the schema already has, which itself has detailed property descriptions. The description doesn't add additional meaning or context beyond listing the parameters, so it's baseline adequate but not rich.

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 clearly states the tool 'Получить список пользовательских полей записи' (get list of custom fields) with a specific resource and endpoint (GET /api/v1/custom-fields/{accountId}). It also differentiates from siblings by explicitly mentioning it's needed to learn real ids and types before passing custom_fields to kronos_create_event/kronos_update_event, which sets it apart from other read tools.

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 explicitly says when to use this tool: 'Нужно, чтобы узнать реальные id и типы кастомных полей перед тем как передавать custom_fields в kronos_create_event / kronos_update_event' (Need to know real ids and types before passing custom_fields to create/update event). It also names the specific sibling tools that depend on this information, providing clear context for when this tool is appropriate.

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

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

Annotations already declare read-only and idempotent behavior. The description adds valuable context: the exact HTTP method (GET), the endpoint pattern, that the raw JSON response is returned as-is, and the specific 404 error when the record is not found in the given branch. This goes beyond the annotation defaults.

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 well-structured with clear sections (purpose, args, returns, error handling) and is free of fluff. It conveys all necessary operational details in a compact format, though it could be slightly more informative without becoming bloated.

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 get-by-id operation, the description covers the purpose, required parameters, return type, and error handling. The annotation covers safety (read-only, idempotent). The only minor omission is an explicit note that the event is scoped to the specified filial, but that is already captured in the schema's filial_id description and the 404 error message.

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?

The input schema already provides thorough descriptions for both parameters (event_id and filial_id), including clarification that filial_id refers to a specific branch, not a city or network. The tool description only repeats the parameter names and lists them as required, adding no new meaning beyond what the schema already gives.

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 clearly states the verb (Получить = get), the resource (one record/booking by id), and the HTTP endpoint. It is immediately distinguishable from siblings like kronos_list_events or kronos_get_time_slots, which deal with collections or different resource types.

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 no guidance on when to use this tool versus the alternates. While the purpose implies 'get a single event by id', there is no explicit mention of use cases, alternatives, or conditions where another tool would be more appropriate. This leaves the agent to infer intent without any routing hints.

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

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

The description adds meaningful behavior beyond the readOnly/idempotent/destructive annotations: it states the response is a raw JSON string as returned by the vendor, warns that the response format is not documented, and documents concrete error cases including missing filial_id and HTTP 401/403 rejection. This gives the agent practical expectations about failure modes and output reliability.

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 front-loaded with purpose and sibling distinction, then uses clear labeled sections for Args, Returns, and Error Handling. Each section provides necessary invocation detail without fluff or redundant filler.

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?

Given the annotations already establish read-only/idempotent/non-destructive behavior, the description covers the remaining needed context: when to use it, what parameters matter, what the return looks like, and what errors to expect. The mention that response format is vendor-undocumented is especially important for agents relying on the output.

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?

The description enumerates all parameters and their constraints: resource_id as required list, date as optional YYYY-MM-DD, day_count 1-30 default 1, interval 5-720 default 60. It further adds the KRONOS_DEFAULT_FILIAL_ID fallback behavior, which is not explicit in schema. It slightly restates schema details but compensates for the 0% reported top-level schema coverage.

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: 'Получить все слоты времени по ресурсам (включая занятые)' and names the exact endpoint GET /api/v1/time-slots. It explicitly contrasts this tool with kronos_get_available_slots, making the distinction between full schedule visibility and free-only slots unambiguous.

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 clear when-to-use guidance: use kronos_get_available_slots when only free slots need to be shown to a client, and use this tool for administrative/diagnostic schedule viewing. It directly names the alternative and the condition that selects it, leaving no ambiguity.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the HTTP method GET and states the response is returned 'as is', which is mild extra context. It does not deepen behavioral disclosure significantly beyond the annotations.

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: a lead sentence, a usage rationale, and a structured Args/Returns section. No redundant filler beyond some overlap between the verb phrase and endpoint, but overall it is well-organized and easy to scan.

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 read-only tool with a single nested-parameter object, the description covers the primary purpose, usage context, and required parameters. With annotations and an output schema present, it does not need to explain return structures. It omits default values for optional params, but those are already in the nested schema, so completeness is adequate.

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?

The description lists the parameter names and notes that resource_type_id is required and contrasts it with resource_id. However, the nested schema already provides detailed descriptions for filial_id, date, day_count, and interval. The description adds little beyond that, though it does clarify the key distinction for resource_type_id.

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 clearly states the tool retrieves time slots by resource type, explicitly contrasting with 'not by specific id', and names the endpoint. It also gives a concrete booking scenario ('any available hall of this type for 14:50'), which makes the tool's purpose unambiguous and distinguishes it from resource-specific siblings.

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 provides an explicit when-to-use statement: when a booking is indifferent to a specific hall/animator, with a practical example. It implies exclusion of resource-specific cases ('not by specific id') but does not explicitly name the alternative tool or spell out when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only safety profile is established. The description adds valuable behavioral context beyond this: it returns Kronos JSON verbatim, and it honestly warns that the pagination shape is not documented by the vendor and should be verified against a real account.

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 organized into purpose, args, and returns, with the endpoint and the pagination caveat earning their place. The Args section partly repeats schema information, but it is compact and helps an agent quickly see the full set of filters without inspecting nested schema definitions.

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?

The description covers what is needed to invoke the tool: required branch/filial id, optional filters, pagination support, and the raw return format with a vendor caveat. Because an output schema exists and the annotations cover the safety profile, the missing details such as exact response fields are acceptable. The only real gap is explicit sibling-tool differentiation.

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?

The description consolidates the parameter contract by marking filial_id as required, listing all optional filters, and giving the specific parent_id use case of retrieving 'доборных детей' child records for a group slot. While the schema already provides per-property descriptions, the description adds useful semantic framing and makes the required/optional split explicit in one place.

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 states a specific verb and resource: 'Получить список записей (броней) с фильтрами' and identifies the endpoint GET /api/v1/events. This clearly signals a list operation and distinguishes it from sibling singular/state-changing tools like kronos_get_event, kronos_create_event, and kronos_delete_event.

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 implies when to use the tool: when a filtered, paginated list of bookings/events is needed. However, it never explicitly says when not to use it or names alternatives such as kronos_get_event for a single event or kronos_get_available_slots for availability. The filtering context is clear but the alternative routing is left to inference.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context by identifying the HTTP method and stating that the response is the raw Kronos JSON as-is, which sets return-format expectations beyond the annotations.

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 well-structured: purpose, endpoint, usage guidance, parameters, and return type are all covered with no filler. The most important operational instruction—fetch real IDs before dependent calls—is front-loaded and prominent.

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 read-only list tool with rich annotations and a structured input schema, the description provides the essential workflow context and raw-return expectation. It does not cover pagination or error behavior, but those are not critical given the tool's simplicity and the openWorldHint annotation.

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?

The Args section restates filial_id as required and resource_type_id as an optional filter, which is helpful but largely mirrors the nested schema's own descriptions. It does not add extra meaning such as accepted value formats, examples, or how the filter list interacts with the API, so parameter semantics remain adequate rather than enhanced.

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 action and object: 'Получить список ресурсов филиала (залы, аниматоры и т.п.)' and gives the endpoint GET /api/v1/resources. This clearly conveys that the tool lists branch resources and is distinct enough from sibling list tools like kronos_list_services.

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 explicitly instructs the agent to use this tool to discover real resource IDs before calling kronos_get_time_slots, kronos_get_available_slots, or kronos_create_event, and notes these IDs are not documented in advance. It does not mention when not to use it or name an alternative listing tool, so it stops short of a full 5.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds the GET endpoint and notes that the response is raw Kronos JSON ('JSON-ответ Кронос как есть'), which is useful behavioral context beyond the annotations.

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 well-organized: purpose, endpoint, use case, args, and return value. Every sentence earns its place, and the most important information is front-loaded.

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 read-only tool with one required parameter and an output schema, the description covers the essential context: what it returns, why it is needed, and how it fits into the create_event flow. It does not discuss pagination or filtering, but these are not critical for this tool.

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?

The description only repeats that filial_id is required, which the schema already states. The schema itself provides a meaningful description of filial_id, so the description adds little semantic value beyond what is already structured.

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 and resource: 'Получить список услуг/товаров филиала' (get the list of branch services/products) and even names the HTTP endpoint. It clearly distinguishes this from sibling tools like kronos_list_resources and kronos_list_events by focusing on services/products.

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?

It explicitly states when to use the tool: before calling kronos_create_event, to discover real service ids including group_service_id. It does not spell out when not to use it or name alternatives, but the main use case is clearly communicated.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds important behavioral context: the vendor does not document idempotency, repeated calls may create duplicate subscriptions, and the tool returns the raw JSON response. This goes beyond the annotations and helps the agent understand side effects and risks.

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 with the core purpose and endpoint. It includes a warning and parameter summary without excessive verbosity. Slightly dense with Russian text, but every sentence earns its place.

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?

Given the tool has an output schema and annotations, the description covers the key behavioral and parameter context. It explains the push mechanism, idempotency risk, and parameter semantics. Minor gap: it doesn't describe the exact shape of the webhook payloads, but that's not necessary for invoking the tool correctly.

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%, so the description must compensate. It does: it explains filial_id is required per call, actions must be a list of create_event/update_event/delete_event, and filial_ids is optional and defaults to all account branches. This adds meaning beyond the raw schema, though the schema itself already has decent property descriptions.

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 states a specific verb ('Подписаться на пуш-вебхуки'), the resource (events in Kronos), and the exact endpoint (POST /api/v1/webhooks/subscribe). It also explicitly distinguishes this from the rest of the API by noting it is the only push mechanism, which differentiates it from sibling tools that are pull/polling.

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 explicitly says this is the only push mechanism and the rest of the API is pull/polling, which tells an agent when to use this tool versus alternatives. It also warns about undocumented idempotency and advises checking on a real account, which is valuable usage guidance.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds beyond that: cancel via status_id=0 preserves history, loss_reason_id enumerations, custom_fields merge semantics (unset means keep, empty string clears), and raw JSON return. No mention of auth/ratelimit, but annotations carry the safety burden and nothing contradicts them.

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?

Compact intro followed by scannable bullet-style scenarios; Args and Returns are cleanly separated. Every line earn hers place with no filler or tautology.

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 multi-scenario mutation tool, the combination of description, annotations, and rich schema covers purpose, common use cases, parameter semantics, return format, and the key sibling alternative. Nothing required for correct invocation 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?

Although the context signal reports 0% schema coverage, the actual input schema contains full descriptions for every parameter. The description still adds the 'only send what changes' behavior and organizes parameters by scenario, going slightly beyond the schema's per-field documentation.

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?

States specific verb 'изменить' (update), resource 'event', and enumerates three concrete operation types (reschedule, cancel, custom-field edit). Explicitly contrasts with kronos_delete_event, so an agent can distinguish it from siblings at a glance.

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?

Provides three clearly marked scenarios with the exact parameters to pass for each, instructs to 'pass only what you actually change', and names kronos_delete_event as the inferior alternative for cancellation because it destroys history—explicit when/when-not guidance.

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