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

With no annotations at all, the description carries the full burden and does disclose real behavioral facts: which fields are copied from the bill, that the basis field is auto-filled as 'Счёт № от', the date default, and the duplicate guard. It still omits whether the act is created as a draft or finalized, how numbering is assigned, and what the call returns — gaps that matter for a write tool.

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?

Two short sentences with no filler; the core inheritance behavior leads, and the two operational gotchas (date format/default, duplicate rule) follow compactly. 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?

For a five-parameter create tool with no annotations and no output schema, this covers the essentials an agent needs to call it correctly, including the non-obvious duplicate constraint. The undocumented number/template_id parameters and the absent return-value story keep it short of 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 and it partially does: act_date gets a format and default, allow_duplicate gets its trigger condition, and bill_id's role is implied by the inheritance sentence. However, number and template_id — two of five parameters — are never mentioned anywhere, leaving an agent to guess their purpose.

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 a specific verb and resource: creates an act (акт) from an issued bill, and explains that line items, client and bank account are inherited from the bill. This distinguishes it in practice from elba_create_act and elba_upd_from_bill, but the description never names those siblings, so an agent must infer the split from the name alone.

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?

Usage is implied rather than stated: you use it when you already have a bill and need the corresponding act. The one explicit conditional — a second act for the same bill requires allow_duplicate=true — is genuinely useful routing information, but there is no guidance on when to prefer elba_create_act or elba_upd_from_bill instead.

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?

No annotations are provided, so the description carries the full behavioral burden. It does add useful structural context by declaring that items and bank_account_id behave identically to elba_create_bill and that template_id comes from elba_templates, which reduces guesswork. It says nothing about side effects, whether a draft or posted document is produced, permissions, or what the call returns — significant omissions for an unannotated mutation tool.

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?

Five short lines, purpose front-loaded, with each subsequent line mapping to a parameter group — no filler. The telegraphic style is dense but every sentence earns its place. It loses a point only because the compressed cross-references demand the agent already know the sibling tools' payload conventions.

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 10-parameter mutation tool with no annotations and no output schema, the description covers payload construction but not outcome: it never says whether the created act's id/number is returned, nor how it relates to elba_document_link for later attachment. The sibling routing and field-origin notes make it broadly usable, but an agent must guess at the return value and at required-field prerequisites.

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, and it partly does: it explains the reason_name/reason_number/reason_date trio as the basis document (e.g. invoice number and date) and delegates items, bank_account_id and template_id to their source tools. It leaves contractor_id (required), number, act_date and with_nds entirely unaddressed — with_nds in particular is a boolean whose effect an agent cannot infer from the name alone.

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 first line states a specific verb and resource ('Создать акт выполненных работ'), which is precise enough for an agent to know this creates a completed-works act document. The final sentence names the sibling elba_act_from_bill, giving partial differentiation among the many sibling tools. It stops short of distinguishing this from elba_create_upd, the other document-creation sibling that overlaps in scope.

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 last sentence gives one explicit routing rule: an act based on an issued invoice is easier via elba_act_from_bill, which is genuine when-to-use-alternative guidance. However, there are no prerequisites (e.g. resolve contractor_id via elba_find_contractor first) and no guidance on when to pick this over elba_create_upd. The agent gets one useful branch but must infer the rest.

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?

With no annotations, the description carries the full burden and largely does: it discloses that the bill is written to the journal, that duplicate (same client + same amount within a week) creation is blocked unless allow_duplicate=true, and the return shape (number, amount, status). It does not mention permissions or irreversibility, which are the remaining behavioral gaps.

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 the purpose, then one parameter per line with concrete defaults and formats — dense but efficient for a 10-parameter tool with zero schema coverage. Some phrasing (the template-oferta warning) is slightly verbose but contributes real meaning.

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 mutation tool with no annotations, no output schema, and 10 undocumented parameters, this description is close to sufficient: it covers defaults, formats, the dedup guard, and return value. The missing contractor_id semantics and comment handling are the only material gaps.

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 0% and the items schema is a bare object with additionalProperties, so the description must compensate — and it does well, spelling out items structure with quantity/unit defaults, nds_rate, bill_date format, number default, template_id, bank_account_id rules, project, and allow_duplicate. The notable omission is contractor_id, a required parameter given no explanation, and comment is never mentioned.

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 line states a specific verb and resource ('Выставить счёт клиенту') that unambiguously identifies a bill-creation operation, distinguishing it from elba_get_bill or elba_repeat_bill by its transactional nature. It stops short of naming the sibling tools it is not, so the separation is implicit rather than stated.

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 create-a-new-invoice context is clear, and it usefully redirects to elba_templates for template selection and warns the template text may not match the contract. However, it never says when to prefer this over elba_repeat_bill for an existing bill, nor any exclusions, so the guidance is implied rather than explicit.

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?

No annotations are provided, so the description carries the full burden. It implies a persistent write but says nothing about permissions, whether a duplicate INN is rejected server-side, irreversibility, or required fields beyond 'name'.

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?

Two short sentences with the action first and the safety check second. Nothing is wasted and it 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 an unannotated mutation tool with nine mostly undocumented parameters and no output schema, the description omits required-field expectations, uniqueness behavior, and the success response. It covers only the dedup workflow.

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?

Nine parameters with 0% schema description coverage; the description only hints that INN identifies the contractor for dedup purposes. Name, KPP, OGRN, address, and the three contact fields are never explained, so the coverage gap is not compensated.

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 a concrete verb and resource ('Создать контрагента'), which clearly distinguishes it from elba_find_contractor and elba_get_contractor. It does not explain what a contractor record contains or how it relates to the bill/act tools, so it stops short of a 5.

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 an explicit prerequisite: run elba_find_contractor by INN first to avoid duplicates, and names the sibling. No guidance on when not to create, or what to do when a match is found (update vs. abort).

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?

No annotations exist, so the description carries the full burden. It does disclose the key behavioral branch — with_nds produces a UPD with an invoice (status 1), otherwise a transfer-only document (status 2), and that item-level nds_rate overrides the header value — which is genuinely useful. However it says nothing about permissions, whether the document is created as a draft, how the number is assigned, or what happens on validation failure.

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?

Four dense, front-loaded clauses with no filler; the document-creation fact comes first and the sibling redirect last. It is compact but reads as a run-on, and the dependency on another tool's schema ("items — как в elba_create_bill") forces the agent to open a second definition.

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 10-parameter mutation tool with no annotations and no output schema, the description covers the core semantics but leaves most parameters and the entire return behavior (e.g. the created document id) unstated. An agent can probably construct the happy-path call, but not confidently handle the optional date/reason/bank-account fields.

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% across 10 parameters, so the description must compensate. It does add real value for the three hardest ones: the items shape (delegated to elba_create_bill plus a "type" discriminator), with_nds, and the nds_rate value set (withoutNds, nds0, nds5, nds10, nds20, nds22) — enum values that the schema does not declare. But number, upd_date, reason_date, reason_name, reason_number and bank_account_id receive no explanation at all.

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 ("Создать УПД") and immediately clarifies what the two document variants are via the with_nds explanation (status 1 vs status 2). It also explicitly routes the agent away from elba_upd_from_bill, so it is distinguishable from its closest sibling without opening any 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?

It names an alternative and the condition that selects it: "УПД по выставленному счёту — elba_upd_from_bill". It also states a conditional requirement (nds_rate is mandatory when with_nds). It does not cover when to prefer elba_create_act or when this tool should not be used, 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?

No annotations exist, so the description carries the full burden. It adds real behavioral context — the link is public, renders/ downloads as PDF, QR payment is invoice-only, and the link is persisted in the journal — but it omits link lifetime/expiration, whether generating a link is a mutating/publishing side effect, and any auth requirements.

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 core definition is front-loaded in the first clause, and parameter semantics follow compactly. The final sentence ('Ссылка на счёт из журнала сохраняется в журнале') is somewhat circular and adds little beyond the journal-persistence impression already given.

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?

With no annotations and no output schema, the description should describe the return value (a URL string) and link properties such as expiry or revocation, which it does not. It is adequate for calling the tool — document_id plus two booleans — but leaves behavioral gaps an agent would want.

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 explain with_signatures (stamp and signature) and qr_payment (QR payment, invoices only), which is more than the schema offers, but document_id — the sole required parameter — is left completely unexplained.

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 identifies the resource (a public link to an invoice/act that the client opens and downloads as PDF), so an agent can tell what the tool produces. However, it uses a noun phrase rather than an explicit verb (create/generate), and it does not distinguish this tool from the sibling elba_link_publish, which sounds closely related.

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?

Usage is only implied: the description says the link is sent to the client and that qr_payment is only valid for invoices, which gives a useful eligibility rule. It never states when to choose this over elba_link_publish or elba_get_bill, nor any prerequisites, so an agent must infer the routing.

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?

With no annotations, the description carries the full burden. It signals that name-based matching is less reliable than INN, which is genuinely useful behavioral context, but it says nothing about whether it is read-only, whether partial/fuzzy matches can return multiple contractors, or what happens when filters are omitted (all parameters are optional).

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 front-loaded sentence with no filler; the key reliability hint is embedded efficiently. It is arguably too terse for a 3-parameter, zero-coverage schema, but nothing is wasted.

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?

An output schema exists, so return values needn't be described. However, with all parameters optional and no schema descriptions, the definition should clarify what an empty call does, how kpp combines with inn, and how this differs from elba_lookup_inn/elba_get_contractor.

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% across 3 parameters, so the description must compensate. It covers inn and name only loosely (INN is the reliable key) and never mentions kpp at all, leaving one parameter completely undefined and no format hints for any of them.

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?

Clear verb+resource ('Найти контрагента в Эльбе') with the lookup keys stated (ИНН and/or name), so an agent knows exactly what the tool does. It does not differentiate from the closely related siblings elba_get_contractor and elba_lookup_inn, which look like plausible substitutes.

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 parenthetical 'надёжнее' implies a preference for searching by INN over name, which is mild when-to guidance. It never says when to use this instead of elba_lookup_inn or elba_get_contractor, and gives no exclusions or prerequisites.

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?

With no annotations, the description carries the full burden, and it does disclose some real behavior: the payment-status enum values and the rule that total is null when Elba failed to return the sum for at least one line item. It does not state read-only nature, permissions, or error behavior, and the closing note about journal updates is cryptic.

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?

Three short sentences, front-loaded with the purpose and return fields; little waste. The final sentence about journal updates is terse and hard to parse, slightly weakening an otherwise tight structure.

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 one-parameter read tool with no output schema, the description helpfully enumerates the returned fields and status values, standing in for the missing output schema. It falls short on the parameter's expected format and on any indication of behavior when the id is invalid or not found.

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 single bill_id parameter has 0% schema description coverage, so the description must compensate — it only implies 'по id' without stating the id format, where to obtain it, or how it relates to other tools. That leaves the one required parameter under-explained.

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 'Счёт по id' (bill by id) and enumerates the returned fields — number, line items, total, payment status — so the agent knows this is a read-by-identifier tool. It is distinguishable from elba_create_bill and elba_track_bill by the 'by id' framing, though it never names those siblings explicitly.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of alternatives like elba_track_bill, elba_unpaid, or elba_repeat_bill. The 'по id' phrasing implies a lookup when an id is known, but that 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?

No annotations are supplied, so the description carries the full behavioral burden, yet it only hints at read semantics via 'карточка'. It says nothing about error behavior for a missing/invalid contractor_id, whether the call is safe/non-mutating, or what the returned contact data looks like beyond the word 'контактами'.

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?

It is a single short phrase with no filler, so it is not verbose. But the brevity comes at the cost of substance, so the terseness reads as under-specification rather than disciplined concision.

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?

With no output schema, no annotations, and an undescribed parameter, the description needed to compensate and does not. It leaves unclear what fields are returned, whether contacts are always present, and how the ID should be sourced.

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% and the single parameter contractor_id is undocumented in both schema and description. The description does not say whether the ID is the internal Elba identifier (as opposed to INN, which elba_lookup_inn handles), which is a meaningful ambiguity for this tool family.

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 phrase 'Карточка контрагента с контактами' indicates it retrieves a contractor record along with contact details, which is more than a tautology. However, it never states the retrieval verb explicitly and does not differentiate it from the sibling elba_find_contractor, so an agent cannot tell from the text alone which of the two to call.

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?

There is no guidance on when to use this versus elba_find_contractor (search) or elba_create_contractor. No prerequisites, no statement about needing an existing ID, and no exclusions are given; the agent must infer everything from the tool name.

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?

No annotations exist, so the description carries the full burden. It discloses two valuable behaviors: the API does not return current link settings, so with_signatures and qr_payment are reset rather than preserved, and the stale-link payment risk if an invoice is cancelled without unpublishing. It says nothing about permissions, idempotency, or what happens when link_id/document_id resolve to nothing.

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?

Four short sentences, no filler. The core action and its two modes come first, followed by the operational trigger and then the parameter sourcing notes, which is the right order for an agent deciding whether and how to call it.

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 5-parameter mutation tool with no annotations and no output schema, the description covers the action, the mode switch, both identifier options, and a destructive-side-effect warning. It stops short of describing the return value or failure modes, which would matter for confirming the link state actually changed.

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 and largely does: it explains published's default and inverse meanings, gives two alternate identifiers (link_id from elba_document_link, or document_id for journal invoices), and warns that with_signatures and qr_payment must be re-supplied each call. It still leaves the meaning of qr_payment/with_signatures beyond their reset behavior unstated.

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 a specific verb+resource pair (снять/вернуть публичную ссылку с публикации) and immediately defines both modes via the published flag. It also anchors the resource to the sibling elba_document_link by naming it as the source of link_id, so the agent can tell this apart from the tool that creates links.

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 a concrete when-to-use rule: unpublish when the invoice is cancelled, because the client would otherwise open and pay via the stale link. It does not state when not to use it or what the alternative is for the republish case beyond the published=true flag, but the operational trigger is explicit.

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?

With no annotations, the description carries the full burden and does disclose useful traits: the upstream source (egrul.nalog.ru), that no key is required, and a real data limitation (addresses are not returned by the FNS search). It also flags the 'terminated' field as a blocker for billing. Missing are error behavior for an unknown/invalid INN and any throttling or freshness notes, which keeps it below a 5.

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 purpose, output field list and data source are front-loaded in the first sentence, and the later sentences each add distinct value (address limitation, mapping to elba_create_contractor, terminated warning). It is dense — four clauses separated by semicolons — but nothing is 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?

An output schema exists, yet the description still summarizes the key returned fields and their business meaning (terminated blocks invoicing), which helps the agent decide next steps. Combined with the source disclosure and the create_contractor mapping, an agent has enough to call it correctly; only invalid-INN handling is left unaddressed.

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 0% and the single 'inn' property has no description, only a title. The description establishes that INN is the lookup key against the FNS registry, which is meaningful, but it never gives the expected format (10 digits for organizations, 12 for ИП), leaving the only parameter underspecified.

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 pair: fetch organization/ИП requisites by INN from the FNS EGRUL/EGRIP registry, and enumerates the returned fields (full/short name, KPP, OGRN, head, registration and termination dates). It never contrasts with the confusable siblings elba_find_contractor / elba_get_contractor / elba_organizations, so an agent still has to infer which lookup to prefer.

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 concrete operating guidance: works without an API key, does not return addresses, results should be cross-checked against the client's own data, and a 'terminated' result means no invoice may be issued. It also tells the agent how to feed the result into elba_create_contractor (name vs short_name), which is real routing value. It stops short of stating when to use elba_find_contractor instead.

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?

No annotations exist, so the description carries the full burden, and it says nothing about read-only behavior, whether an API key/credential is required to scope the results, how many organizations are returned, or whether bank accounts include sensitive data. It does not contradict anything, but it discloses almost no behavioral traits.

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 short sentence with no padding, and the resource is front-loaded. It is efficient, though the missing verb makes it slightly less informative than its length allows.

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 has no annotations, no output schema and no parameters, so the description is the only place an agent could learn what comes back (organization fields, bank account fields, ordering) and what 'key' means. Neither is addressed, leaving a read tool whose response shape is entirely unknown.

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?

With zero parameters the baseline would be 4, but the phrase 'доступные по ключу' implies a key-based scoping input that has no corresponding parameter in the schema, creating ambiguity about whether the key is an auth token or something the agent must supply. That single unexplained concept is the only semantic content on offer.

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 noun phrase 'Организации, доступные по ключу, и их банковские счета' identifies the resource (organizations plus their bank accounts) but supplies no verb, so whether it lists, fetches or filters is left implicit. It is distinguishable from the bill/contractor siblings by resource, but it doesn't say how the list is scoped or what triggers it.

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?

There is no statement of when an agent should call this rather than another tool, and no prerequisites or exclusions. The only hint is that organizations are 'available by key', which is not turned into actionable 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?

With no annotations, the description carries the full burden and does real work: it discloses a write side effect ("Обновляет статусы в журнале") and a stateful cursor semantics (first call only advances the marker, history is not returned). What is missing is the read-vs-write safety framing, permission requirements, and behavior when no new payments exist.

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?

Two sentences, no filler. The high-value surprise (first call yields no history) is front-loaded ahead of the field listing, which is exactly the right ordering for an agent deciding whether to call it.

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 zero-parameter tool with no annotations and no output schema, the description supplies the stateful behavior and side effect that an agent could not infer otherwise. It stops short of covering the empty-result case or any authorization preconditions, which are the only remaining gaps.

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 tool takes zero parameters and the description correctly spends no words on arguments, instead describing the returned fields and the marker/state model. Baseline for a 0-param tool is 4, and nothing here detracts from it.

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?

"Оплаты по счетам с прошлой проверки" names the resource (invoice payments) and the scope (since last check), and the listed fields (invoice, status, amount, received) make the payload concrete. It reads distinctly from siblings like elba_unpaid or elba_get_bill because of the incremental "news feed" framing, though it never names an alternative explicitly.

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 "since last check" phrasing implies polling usage, and the note that the first call only sets a marker is a genuine operational caveat an agent must know. However there is no explicit statement of when to prefer this over elba_unpaid or elba_get_bill, and no when-not 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?

With no annotations, the description carries the full burden and does a fair job: it warns that omitting items copies them verbatim, that copied item names may still say last month, that bill_date defaults to today, and that duplicate detection behaves as in elba_create_bill. It does not cover the effect of allow_duplicate or whether number is auto-assigned.

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 and front-loaded: the copy scope comes first, then parameter behavior notes. Each sentence adds something, though the phrasing is dense and slightly telegraphic.

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 mutation tool with no annotations and no output schema, the description covers the main behavioral risks (silent copying, stale item names, duplicate handling). It still leaves the return value and roughly half the parameters undocumented, so an agent cannot fully predict the result.

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 explains items (format elba_create_bill, override vs copy) and bill_date (default today), but number, comment, allow_duplicate, and the semantics of bill_id as the source bill are left entirely to the bare 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 opening line states a specific action: create a new invoice using a previous one as a template, listing exactly which fields are carried over (client, items, VAT, bank account, template, project). The copy semantics implicitly distinguish it from the sibling elba_create_bill, though it never names that distinction explicitly.

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?

Usage is implied — reach for this when repeating a prior invoice rather than building a new one — but there is no explicit statement of when to prefer elba_create_bill instead. The note about passing items to override and the default bill_date give partial operational 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?

With no annotations, the description carries the burden and does well: it states cancelled invoices are excluded, that divergent invoices are re-read from Elba, that amounts may come back null, and that the errors field lists invoices that failed to re-read. It leaves out any permission/auth or performance notes, which is the only real gap for a read-only report.

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-loads the summary definition, then filters, then behavioral caveats in a logical order with no filler. It is dense and somewhat run-on across sentences, but each sentence carries new information.

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 4-parameter report with no output schema and no annotations, the description covers purpose, filters, exclusion rules, and even the shape of the response (byProject list, project null for unassigned, null amounts, errors). Only the semantics of project/contractor_id remain underspecified.

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 0%, and the description compensates by listing all four filters and giving date_from/date_to both a format (YYYY-MM-DD) and an anchor (invoice date). project and contractor_id are named but not explained (name vs. id is left ambiguous), so coverage is good but not complete.

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?

Names a concrete artifact and its content: a summary over the invoice journal with counts of issued/paid/unpaid/closed-by-act-or-UPD, totals and per-project, plus the invoice list itself. It even adds that the list doubles as a lookup by invoice number, which tells an agent exactly what resource it gets back.

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?

Usage is implied through the filter list and the note that the invoice list can locate an invoice by number, but there is no explicit when-to-use statement and no reference to alternatives such as elba_unpaid or elba_get_bill. An agent can infer the reporting role, but must guess how it overlaps with sibling tools.

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?

With no annotations, the description must carry behavior. It implies a read-only lookup list of templates, which is the key behavioral hint, but says nothing about pagination, ordering, auth/organization scoping, or whether templates are per-organization — all of which matter in an API where sibling tools are org-scoped.

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 short sentence: resource first, then the actionable purpose of its output. Nothing redundant, nothing that could be cut.

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 trivial and has an output schema, so the description only needs to establish what the data is and why to fetch it — both covered. A brief note that the result is an unfiltered template catalog for the current organization would close the remaining gap.

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?

Zero parameters, so there is nothing to document; baseline 4 applies. The description instead documents the semantics of the returned template id and where it is consumed.

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?

Names the resource precisely (document templates: invoices, acts, contracts) and pairs it with its downstream consumers, so an agent can tell it apart from elba_create_bill / elba_create_act. It stops short of an explicit verb like 'list/returns', so the enumerating nature is implied rather than stated.

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 pointer to 'id for template_id in elba_create_bill and elba_create_act' gives a concrete trigger: call this before creating a bill or act that needs a template. No exclusion or edge cases (e.g. what to do with no templates, or whether defaults exist) are given.

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?

There are no annotations, so the description carries the full burden for a mutation. It does add real context by clarifying that this registers an already-existing external bill into the journal rather than creating a bill, but it says nothing about idempotency, what happens if the bill is already tracked, required permissions, or failure modes.

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?

One tight sentence with the qualifying scope front-loaded after the action; nothing is padded. It is efficient but very short for a mutation whose semantics are non-obvious.

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?

A mutation tool with no annotations, no output schema and two undocumented parameters needs more: what the journal entry becomes, whether the call is idempotent, and how bill_id/ project are interpreted are all missing. An agent can guess the intent but not call it safely.

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 and does not. Neither bill_id (is it an Elba ID, an external document number, an INN-scoped identifier?) nor the optional project parameter is explained anywhere.

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 gives a specific verb ('Добавить в журнал' – add to the journal) plus the resource (a bill) and a scope qualifier: bills not issued through this server. That implicitly separates it from elba_create_bill, but it never names that sibling, so the differentiation is inferred rather than stated.

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 clearly states the situation that selects this tool: bills entered manually in Elba or that predate the journal. It does not explicitly say 'do not use for new bills – use elba_create_bill instead', leaving the exclusion to be inferred from the scope phrase.

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?

With no annotations, the description carries the full burden and does substantial work: it discloses the reconciliation behavior (paid/cancelled re-read only on divergence), the effect of recheck_all, and a failure mode — debt comes back null if any amount is unknown or an invoice failed to re-read. Missing are cost/latency implications of recheck_all and any permission requirements.

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?

Four tight sentences: what is returned, the reconciliation rule, the flag, then the output shape and null condition. Front-loading the resource and putting output details last is the right order. Density is high but nothing is padding.

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?

With no output schema and no annotations, the description steps in to enumerate the returned fields (number, client, project, amount, paid, days outstanding, link) and the null-debt edge case, which is exactly the burden it must carry. Remaining gaps are ordering, whether the result is paginated or bounded, and how 'unpaid' is scoped by date.

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 0% — recheck_all has a bare boolean with a default and no explanation — so the description must compensate, and it does: it defines the flag's effect as re-reading all invoices rather than only divergent ones. For a single parameter that is adequate, though it doesn't say how expensive the all-invoices path is.

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 resource and filter: unpaid invoices assembled from the journal status plus the payment feed, with the paid portion reconciled. That is far more than a restatement of the name. It does not explicitly contrast itself with siblings like elba_report or elba_payment_news, so an agent still has to infer which aggregation it wants.

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?

Usage is implied rather than stated: the agent learns that paid/cancelled invoices are re-read only when the feed diverges from the journal, and that recheck_all=true forces a full re-read. That is genuinely useful selection logic for the single parameter, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative.

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?

With no annotations, the description carries the full burden and does real work: it discloses that most fields are inherited rather than supplied, that document status is derived from whether the bill carries VAT, and that duplicate UPDs per bill are blocked by default and must be explicitly permitted. It stops short of stating permission requirements, whether the document is created as a draft or published, or what the call returns.

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?

Three tightly packed sentences with no filler: the derivation is front-loaded, the status logic follows, and the two parameter rules close it out. Dense but every sentence carries information; only the mixing of behavioral rules with parameter rules slightly weakens the structure.

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 five-parameter mutating tool with no annotations and no output schema, the description covers the surprising behavior well but leaves gaps an agent would want: what the generated document's identity is in the response, whether number/upd_date are overrides, and whether the created UPD is editable afterwards.

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 so well for two of five parameters — product_type with its default and scope ('for all line items') and allow_duplicate with the exact condition that requires it — but number, upd_date and even bill_id are never explained (e.g. whether number overrides the auto-generated document number, or which date upd_date sets).

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 a specific operation (generate a UPD from an issued bill) and immediately explains the data source: line items, client, bank account and VAT are inherited from the bill, with the basis field set to «Счёт № от». It does not, however, distinguish itself from siblings elba_create_upd or elba_act_from_bill, so an agent must infer which generator to pick.

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?

Usage is implied through the conditional rules given — a VAT bill yields status 1, a non-VAT bill status 2, and a second UPD for the same bill requires allow_duplicate=true. Missing is any explicit statement of when to prefer this over elba_create_upd (creating a UPD from scratch) or elba_act_from_bill, leaving the sibling selection to inference.

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