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

Beyond the annotations, the description discloses the irreversible consequence (the sent notification cannot be recalled — consistent with destructiveHint=true), the side effect of notifying the tutor, the fact that the model never receives the form keys, and the three possible response outcomes including a site-level refusal text. This is exactly the behavioral context that annotations alone cannot 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?

The invocation constraint and irreversibility warning are front-loaded, and each sentence carries information. It is slightly denser than needed — the key-provenance point is restated in the description and in the schema — but there is no 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?

The description covers the two-step request flow, the tool's position as step one, its trigger conditions, and its full set of responses; with no output schema, this is the only place return values are described and it does so adequately. Nothing an agent needs to reason about or route away from this tool 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 100%, so the schema already documents all nine parameters, including enums for locale and lesson_format. The description adds only the provenance of the form-key parameters (token/rendered_at come from the card, not the model), which is partially restated from the schema itself, so the baseline 3 applies.

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 the specific verb and resource — creating a booking request (заявка) and triggering a tutor notification — plus where it originates (the card form's booking button). It also names the sibling add_request_details as the second step, allowing an agent to separate the two without reading either schema.

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 trigger condition is explicit and narrow ("Вызывается только формой карточки после нажатия пользователем кнопки записи"), and it explicitly states the negative case ("Модель этот инструмент не вызывает и ключей формы не получает"). The alternative for completing the same request is named with its role.

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