Отложенные действия

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds substantial behavior beyond them: completed tasks are retained and shown, ordering is by earliest deadline, no status means the response is dominated by old history, the panel performs filtering rather than the request, outputs cap at 300 records, and the total count is not disclosed. This is exactly the kind of context that prevents mis-calls.

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?

A single dense paragraph where every sentence earns its place: examples, retention behavior, ordering, filter advice, and response cap. It is not bullet-structured and slightly overlaps the schema's limit maximum, but nothing is padded and the most important caveat (no status → old history) 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 optional-parameter list tool with annotations covering the safety profile, the description explains the key call-shaping behaviors: ordering, inclusion of done/cancelled records, the 300-record ceiling, and the lack of total-count reporting. The only gap is that no output schema exists and the description does not sketch the record fields returned per task, so an agent cannot fully predict response shape.

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 baseline is 3. The description adds value by explaining the consequence of omitting status (you get old history) and by tying the 300-record cap to the limit parameter semantics, which helps the agent reason about pagination. It reinforces but does not duplicate the schema.

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 concrete examples of what is listed — «написать через три дня», «напомнить, если не ответил» — and states the resource (scheduled tasks in a case). The verb «Показывает» plus the scope makes it clearly a read-only listing tool, and its domain is distinguishable from the only same-domain sibling, tasks_cancel, by being a list rather than a mutation.

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?

Gives explicit in-tool guidance: ask for upcoming items with status=pending because the panel filters, and warns that omitting status returns stale history. It does not explicitly name alternative tools or state when-not-to-use conditions, so it falls short of full exclusion-based guidance, but the usage context is clear.

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