tochka_invoice

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

The description lacks disclosure of behavioral traits. Annotation 'openWorldHint': true suggests non-standard behavior, but no details are given about side effects, authorization requirements, rate limits, or idempotency. The tool issues an invoice (a write operation), but nothing addresses these aspects.

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 description is structured with an Args list, which is clear, but it is somewhat lengthy (16 lines for parameters). Some information (e.g., 'optional' labels) is redundant with the schema's 'required' list. The first sentence is concise and front-loaded, but the parameter documentation could be more terse.

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?

Given the tool's complexity (12 parameters, 5 required), the description covers the input sufficiently but omits details on return value (beyond 'Returns documentId'), error behavior, and validation rules. With an output schema existing, it is not required to explain return values, but the description does not leverage it. It is adequate but not fully comprehensive.

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?

Despite 0% schema description coverage, the description adds significant meaning: it explains each parameter's role (e.g., 'Buyer company name', 'Total amount (calculated from positions if empty)', 'JSON array of positions...'). It also notes that 'total' can be auto-calculated. However, 'positions' is described as a JSON array but schema types it as string, causing potential confusion. Overall, it compensates well for the lack of schema descriptions.

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 states 'Issue an invoice to a buyer (they pay me). Returns documentId.' This provides a specific verb ('Issue') and resource ('invoice to a buyer'), and the parenthetical clarifies directionality. It distinguishes from sibling tools like 'tochka_pending_invoices' (list) and 'tochka_delete_invoice' (delete).

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?

No guidance is provided on when to use this tool vs alternatives. The description does not mention any prerequisites, exclusions, or comparison to related tools such as 'tochka_send_invoice_email' or 'tochka_download_invoice'. The agent must infer usage from context.

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