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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world write (readOnlyHint=false, idempotentHint=false, openWorldHint=false), so the safety profile is covered structurally. The description adds meaningful context beyond that — the CRM card and callback task created, the free-consultation fact, the PII consent requirement with policy links, and the failure behavior ('ничего не записывается'). It stops short of explaining idempotency/dedup across repeat calls, but the added disclosure is substantial.

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?

Front-loaded with what happens and then the consent precondition; every clause carries operational weight, including the policy/consent URLs and the enumerated return fields. It is dense for a single paragraph but not padded — only the return-value enumeration overlaps with what an output schema would normally carry.

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 write tool with no output schema and no annotations beyond generic hints, the description covers effect, precondition, contact requirement, and return shape (accepted, reference, callback_until_msk) plus error behavior. Complete enough to invoke correctly; only repeat-call/deduplication behavior and the exact rate limit remain unstated.

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 coverage is 100%, so the schema already documents each of the 7 fields. The description adds a genuine cross-field rule not encoded in the schema ('Нужен телефон или e-mail') and clarifies that urls are read by the lawyer. Since the field-level semantics remain the schema's job, this sits at the high-coverage baseline.

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 immediately discloses the concrete side effect (CRM card + callback task). It is clearly distinguishable from siblings like draft_pretrial_claim or infringement_action_plan, which produce documents rather than route a person to a lawyer.

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 gives an explicit, hard gating rule: call ONLY when the person themselves asked to be contacted, has seen what will be sent, and explicitly consented to personal-data processing. It further states the contact requirement (phone or e-mail) and that missing consent/contact or exceeding a limit yields an error, which effectively defines the when-not case.

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