Статус операции записи

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

The annotations only say that this operation is not read-only and does not destroy data. On top of that, the description explains the verification strategy for each object type (assigned link, label, line count, composite key plus field fingerprint), the meaning of the unverifiable and not_found outcomes, and the rule that 'a missing object does not by itself authorize a retry because 1C may still be executing.' It also clarifies that nothing is written into 1C. This is exactly the behavioral context the annotations do not provide.

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?

Each sentence adds a distinct behavioral fact, and the central point comes first: status lookup, then verification rules, then the retry and close-out rules. The text is dense, and the multi-clause sentences about register settings and document lines require careful reading, but nothing is redundant.

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 definition covers verification logic, the possible outcomes, the guardrails against duplicate writes, and the close-out procedure. An output schema exists, so return shapes need no explanation, yet the description still explains what the key statuses mean. This is sufficient for an agent to use this tool safely without further documentation.

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 baseline would be 3, but the description adds workflow meaning: operationId must come from a preview; markNotApplied is legitimate only after a human has checked the database; and a successful match is recorded as success even if the operation is marked not applied. The 120-second floor lives in the schema rather than in the description, but the surrounding reasoning is still supplied.

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 opening sentence names a specific verb and resource: the state of a write operation, identified by the operationId returned by a preview. This distinguishes it from the many sibling creation tools, which perform the actual writes. An agent can tell from the first line that this is a read-side status check on an already-submitted write operation.

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 states explicitly when this tool must be used (after a lost response to verify whether the object was created), when replies are inconclusive (unverifiable, not_found), and when a new preview is allowed (only after not_applied or a rejected result whose cause has been fixed). It also states the prerequisite for markNotApplied (a human has manually verified the 1C database). Few alternatives are named by their own names, but the workflow position is unambiguous.

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