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

No annotations are given, so the description carries the full behavioral burden. It does disclose two non-obvious traits: the record is enriched from the external ARES registry, and an existing record is not overwritten (effectively a no-op/skip rather than an upsert). It does not say what happens when the IČO is invalid or not found in ARES, nor whether any permission or connectivity is required.

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, front-loaded sentences with zero filler; the core action comes first and the non-overwrite caveat follows immediately. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained, and the ID scheme and ARES sourcing are covered. For a mutation tool with no annotations, though, a brief note on failure behavior (missing/invalid IČO, unreachable ARES) 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?

Schema description coverage is 100%, so all three parameters (ico, email, customer_id) are already documented in the schema, including the ARES enrichment note for ico. The description only reiterates the IČO/ARES linkage and adds no semantics about the format or constraints of customer_id or email beyond 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?

Uses a specific verb ('Přidá') and resource ('odběratele do adresáře') and names the mechanism ('podle IČO, data z ARES'), which clearly separates it from read-side siblings like list_customers or lookup_company. It stops short of explicitly naming the sibling it replaces, so a 5 isn't warranted.

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?

'Existující záznam nepřepíše' gives an important usage constraint — calling it for an already-present customer is a no-op rather than an update. However, there is no explicit statement of when to choose this over lookup_company (read ARES data) or how to then modify an existing entry.

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 says the tool writes a record but is silent on what happens if expense_id already exists (overwrite vs. duplicate error), whether the write is reversible, what validation failures look like, or that this is a mutating, non-read-only operation requiring accurate accounting data. For a 17-parameter write tool with zero annotation coverage, this is a significant gap.

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 and the purpose stated first. It is efficient, though for a tool with 17 parameters and a multi-step import-recovery workflow the brevity edges toward under-specification rather than true 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?

Has an output schema, so return values need not be described, and 100% schema coverage handles parameters. Given that, the description only needs to establish purpose and the import-failure entry point, which it does. The gap is the missing tie to list_import_issues, not missing return or param detail.

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 every one of the 17 parameters already carries its own meaning (including the non-obvious reverse_charge, claim_date, supplier_country and business_share semantics). The description adds no parameter guidance beyond what the schema states, so the baseline 3 applies.

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 in Czech: 'Ručně zapíše přijatou fakturu (výdaj)' — manually records a received invoice as an expense. It also scopes it to documents the import cannot read. However, it does not distinguish itself from the similarly-named sibling add_manual_invoice, so an agent must guess between the two.

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?

'hlavně doklady, které import neumí přečíst' implies the entry point (documents flagged by import), but never names the sibling that surfaces those documents (list_import_issues) nor contrasts with add_manual_invoice, remove_expense, or mark_expense_paid. Usage is inferable but not stated as an explicit condition.

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 does disclose one important behavioral fact — that no document is generated and an existing PDF must be supplied — but says nothing about duplicate invoice numbers, idempotency, validation, required permissions, or whether the record links back to the import issue.

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 sentence with the action front-loaded and the qualifying condition immediately after it. No filler, and the parenthetical carries real disambiguating information rather than restating the name.

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 write tool, the description supplies the workflow context an agent needs (import failure, pre-existing PDF) while the schema fully documents parameters and an output schema covers the return. Only edge-case behavior such as duplicate numbers or failure modes is 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 description coverage is 100%, including nested LineInput fields with Czech explanations for unit, quantity, VAT rate, and net unit price. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 ("Zapíše do evidence vydanou fakturu") and adds a distinguishing clause: the invoice is one the import could not read and the PDF already exists, so nothing is generated. That separates it from issue_invoice, which produces a PDF, though it never names that sibling directly.

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 when-to-use condition is explicit and narrow: only for issued invoices that the import failed to parse, with an existing PDF. The parenthetical "nic se generuje" implicitly rules out the generation path, but no alternative tool is named and no explicit when-not case is 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?

No annotations are supplied, so the description carries the full behavioral burden. It discloses that results include per-month paid/overdue status and a computed next-year estimate (useful computed-value disclosure), but never states that it is read-only, whether ČSSZ data requires prior authentication/setup, or anything about data freshness. For a simple lookup this is adequate but not rich.

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 tightly packed sentence with a colon-delimited enumeration of outputs; no filler, and the resource is front-loaded before the details.

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 need not be explained, and the sole parameter is fully documented in the schema. The description is nearly complete for a one-parameter read tool; the only omission is any note on access requirements or what to do if ČSSZ data is not configured.

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% and the single 'year' parameter is already documented in the schema with its default ('Rok. Default letošní.'). The description adds no additional meaning about the year parameter, so the baseline of 3 applies.

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 names a specific resource and its scope: monthly ČSSZ advance payments, showing which months are paid or overdue plus a next-year advance estimate. An agent can immediately tell this is a payment-schedule lookup, distinct from every sibling tool (invoicing, customers, VAT). No explicit verb is used, which keeps it just 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?

Usage is only implied by the listed contents – an agent infers it is for checking advance payment status or forecasting next year's advance. There is no explicit when-to-use statement, no prerequisites, and no mention of alternatives (none of the siblings actually overlap, so this gap is minor).

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 the key consequence: the invoice stays in the records but is not counted, and delivery to the customer changes the correct action entirely. It does not cover permissions required, whether the cancellation is itself reversible, or any rate/duplicate-call concerns, which is a real but modest gap for a destructive mutation.

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, effect first, exception second, with no filler. The phrasing is slightly terse and the split into a fragment as the second sentence is a little clipped, 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?

For a two-parameter mutation the description covers the effect on data, the user-intent prerequisite, and the branch to the sibling tool; an output schema exists so return values need not be explained. Only authorization and reversibility are unaddressed, which is a minor residual gap given no annotations are supplied.

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% and both parameters are documented in the schema, including a concrete example for 'reason'. The description adds no further meaning about the number format or what makes a good reason, so the baseline 3 applies.

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 ('Stornuje vydanou fakturu') and immediately disambiguates scope from the nearest sibling by naming issue_credit_note as the alternative path. An agent can distinguish cancel_invoice from issue_credit_note without opening either 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?

Gives an explicit precondition ('Jen pokud ji uživatel výslovně ruší') and an explicit exclusion with the substitute tool ('Pokud už byla doručena odběrateli, nestornuj — vystav dobropis přes issue_credit_note'). Both the when and the when-not, plus the named alternative, are present.

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 the two behaviors that matter most: it writes into a local Mail.app mailbox (side effect on the user's machine) and it never transmits anything. Gaps remain around preconditions — the invoice presumably must exist and be issued, and Mail.app must be present on macOS — and around failure behavior for an unknown number.

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, front-loaded with the action and followed immediately by the non-sending guarantee. No filler, no restatement of the name.

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 need no explanation, and the parameter set is small and fully described. What is missing for a tool that touches the user's mail client is precondition and failure context (invoice must exist, Mail.app required), which keeps it short of a 5.

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 field meanings (recipient defaulting to the customer's address from the directory, invoice number, custom message body) are already fully documented in the schema. The description adds nothing parameter-specific beyond implying that a PDF for that invoice gets attached.

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 concrete verb and artifact: it opens a DRAFT email in Mail.app with the invoice PDF attached. The added 'Nic neodesílá' immediately separates it from the sending/issuing siblings such as issue_invoice, so an agent can place it without opening the 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 makes the key usage boundary explicit — this prepares a draft, sending is left to the user — which is exactly the distinction an agent needs before choosing a mail-related action. It does not, however, say what to do if the invoice is not yet issued (issue_invoice first) or which sibling to prefer for other mail tasks.

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 behavioral burden. It does disclose the important side effect — files are written to Přehledy/<rok>/ — and the two output formats, but says nothing about overwriting existing files, whether the operation is safe to repeat, or whether permissions or a closed year are required.

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 front-loaded sentence stating resource, scope, formats, and destination with zero filler. Nothing is padded or repeated.

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 need no explanation, and the destination and formats are covered. The only real gap is file naming/overwrite semantics for a tool that writes to disk.

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% and the single parameter already documents that it defaults to the current year. The description adds only the indirect hint that the year also determines the target subfolder, which is marginal beyond 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 names a specific resource (the income/expense book, i.e. Czech tax evidence) with a year scope and the concrete deliverables (CSV + PDF) written to a named folder. That is enough to distinguish it from export_invoice_pohoda and export_vat_return, 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 statement of when to choose this export over export_vat_return, tax_overview, or export_invoice_pohoda, and no prerequisites (e.g. whether the book must be closed or the year complete). Usage is only inferable from the word 'daňová evidence'.

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 the key side effect: a file is written next to the existing PDF, in windows-1250, validated against XSD. It omits failure behavior, overwrite semantics, and whether exporting twice is idempotent — material gaps for a file-producing write operation.

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 that packs the action, the artifact, the encoding, the validation guarantee, and the file location with zero filler. Nothing could be removed without losing 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?

An output schema exists, so return values need not be explained, and both parameters are fully documented in the schema. However, for an export that mutates the filesystem, the definition leaves out preconditions and repeat-run behavior that an agent would need to call it confidently.

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%, and the schema itself explains that 'number' is the invoice number from the records and that 'eu_classification' is the Pohoda VAT code required for reverse-charge EU services. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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 ('Uloží fakturu jako Pohoda XML') plus the output format specifics (windows-1250, XSD-validated, written alongside the PDF). This distinguishes it clearly from sibling exports like export_vat_return and export_book, though it never names or contrasts 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?

No when-to-use or when-not-to-use guidance is given, and no prerequisites are stated (e.g. whether the invoice must already be issued, or whether this can be run repeatedly). The agent must infer that this is the Pohoda-specific export path purely from the format named in the sentence.

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 so well on the traits that matter: it writes files to a specific directory tree, it conditionally emits the SH statement only when EU services exist, and it explicitly does not submit anything. It is silent on overwrite behavior when prior quarter files already exist and on what happens if the necessary underlying data is missing, which are the remaining behavioral unknowns.

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 compact sentences front-loaded with the output artifacts, followed by the destination and the crucial 'does not file' caveat. The path template is dense but earns its space because it encodes the naming convention. Slightly more formatting would help separate the conditional SH case from the unconditional outputs.

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 need not be explained, and the description covers what is generated, where it lands, the EU-services condition, and the manual upload follow-up. Overwrite semantics and error conditions for an incomplete quarter are the notable omissions for a file-writing export tool.

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 year, quarter, preview, and filed_on are already documented in the schema. The path template in the description implicitly shows how year and quarter are consumed and hints at quarterly granularity, but adds no meaning about preview or filed_on beyond what the schema states. Baseline 3 is appropriate.

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 names the concrete artifacts produced (DPHDP3, DPHKH1, and conditionally DPHSHV) rather than just repeating 'VAT return' from the tool name, so it actually widens the scope the name suggests. It also states the target system (EPO) and the destination path, letting an agent identify the tool without opening the 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 makes clear this is the preparatory step in the filing workflow and that submission is manual afterwards, which tells the agent this tool should not be followed by any automated submit call. It does not address how it relates to the sibling tax_overview, which is the closest candidate for confusion, so it stops short of full alternative 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?

No annotations are supplied, so the description bears the full burden. It does disclose the fields returned (items, payment data, SPAYD string, PDF path), which is meaningful behavioral context for a retrieval tool, but it omits what happens when the number is not found, whether it is strictly read-only, and any permission or error behavior.

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 sentence, front-loaded with the operation and followed by a compact enumeration of returned content. Nothing is redundant or padded.

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 one-parameter read tool with an output schema, the description covers the essentials and summarizes the payload without needing to restate the return structure. Minor gaps remain around not-found behavior and locating the invoice number, but the core is 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 coverage is 100% with a single required parameter ('number', documented as 'Číslo faktury'), so the schema already does the work. The description adds no further meaning such as expected format, whether a variable symbol or prefix is accepted, or whether the number must come from list_invoices or peek_invoice_number. Baseline 3 applies.

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 names a specific resource and action ('Detail faktury z evidence') and enumerates the content returned: items, payment details, SPAYD QR string, and PDF path. It reads clearly as a single-invoice retrieval tool, distinguishable from sibling list_invoices or get_supplier, though it never names those alternatives 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 only implied: 'detail of an invoice' suggests fetching one invoice by its number rather than listing. There is no explicit statement of when to use this versus list_invoices, nor any note that the invoice number must already be known, leaving the agent to infer the sibling 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?

No annotations are provided, so the description carries the whole burden. It does disclose useful behavior beyond the name: the data originates from a local supplier.yaml file rather than a remote system, and the response bundles a default account. It says nothing about failure modes if the file is missing or unconfigured, which is the main remaining gap.

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 compact sentence with the resource and the data source front-loaded and no filler. It is terse to the point of omitting any usage guidance, but every word carries 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?

This is a simple zero-parameter read, and an output schema exists, so return values need not be spelled out. The description covers the source and contents of the result; only guidance on when to use it and what happens on a missing config file is absent.

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, so there is nothing for the description to disambiguate. Baseline 4 applies; the mention of 'výchozí účet' clarifies the shape of the payload even though it is not a parameter.

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 names the resource precisely – the invoicing supplier read from supplier.yaml, plus the default account that comes with it – so an agent knows exactly what it returns. It lacks an explicit verb and does not differentiate itself from siblings such as list_customers or lookup_company, but the scope is unambiguous.

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 to call this versus alternatives, nor any prerequisite (for example, that supplier.yaml must exist or be configured). The agent must infer the usage context from the name alone.

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 non-obvious domain behavior: positive amounts on the document, deduction in VAT reporting in the correction-date period, and the exact file format produced. It stops short of stating preconditions (must the original be issued/paid?), whether the original invoice is flagged or left untouched, or failure modes such as crediting more than the invoice total.

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 paragraphs, twenty-odd words each: the first states what is produced, the second states when to use it and the accounting consequence. Nothing is redundant and the core action 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?

An output schema exists and all four parameters are documented, so the description only needs to cover intent and side effects. Those are largely covered, but for a mutation tool with no annotations a sentence on preconditions and on what happens to the original invoice 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?

Schema description coverage is 100%, and every property — original_number, reason, issue_date and the lines sub-object — carries its own Czech explanation in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies; it does at least reinforce the positive-amounts convention that governs 'lines'.

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 names a specific verb and resource ('Vystaví opravný daňový doklad (dobropis) k vydané faktuře') and pins down the output artifact precisely: PDF/A-3 with ISDOC, DocumentType 2, no QR. That level of specificity makes it unmistakable against siblings like issue_invoice or cancel_invoice.

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 routing rule: 'Použij místo storna, když už faktura odešla odběrateli' — use this instead of cancellation once the invoice has left to the customer. The alternative (cancel_invoice/storno) is named and the selecting condition is stated, so the agent does not have to infer it.

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 supplied, the description carries the full burden and does disclose meaningful behavior: the exact output format/version, that the invoice is persisted to the records, and that a summary is returned. It omits whether issuing consumes the next number from the sequence, whether the operation is reversible, and what permissions are needed.

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: the first front-loads what the tool produces and persists, the second front-loads the prerequisite checks. 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 19-parameter mutation tool with an output schema and full schema coverage, the description covers the essentials: outputs, persistence, and the pre-flight validation steps. It could go further on numbering behavior and reversibility/cancellation, but the core is present.

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 all 19 parameters, including the vat_rate and currency defaults and the customer ID source, are already documented in the schema. The description only reinforces where customer_id comes from (list_customers); it adds no line-item or rounding semantics beyond 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 gives a specific verb and resource ('Vystaví fakturu') and even names the concrete artifacts produced (PDF/A-3a, ISDOC 6.0.2, QR Platba+F) plus the side effect of storing it in the records. It does not, however, distinguish this tool from close siblings such as add_manual_invoice or issue_credit_note, so an agent still has to infer the boundary from the names 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?

It states a real precondition workflow: verify the customer with list_customers / lookup_company and confirm the amounts with the user before issuing. That is clear when-to-use context naming actual sibling tools, but there is no guidance on when NOT to use it (e.g. versus add_manual_invoice or cancel_invoice).

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 behavioral burden, and it discloses the backing store (customers.yaml), which implies a simple read of local data. It does not explicitly state that the call is read-only and side-effect free, nor anything about ordering or emptiness, though the low-risk nature of a zero-argument directory read limits the exposure.

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 resource and the file it reads stated first, followed by the actionable cross-reference. Nothing redundant or padded.

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-argument listing tool with an output schema provided, the description contains what an agent needs: what is listed and how the resulting customer_id is consumed. Only the explicit read-only/no-side-effect statement is missing.

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, so the baseline is 4; there is no parameter meaning that could be added. The description's only semantic contribution is explaining that the returned customer_id is the value to feed into issue_invoice.

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 names the resource (customer directory / customers.yaml) so it is clear this returns a customer listing, and the customer_id reference ties the output to the rest of the workflow. The verb itself is implicit in the noun 'directory' and carried mostly by the tool name, so it falls short of a fully self-contained verb+resource statement, but it is far from tautological.

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 provides a downstream usage hint (use customer_id in issue_invoice) but never says when to call this versus siblings like lookup_company or get_supplier, nor what preconditions apply. Usage is only implicitly derivable from the fact that it is a zero-argument directory listing.

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. It discloses what the results contain (a PDF path per item) and implicitly that this tool is a read-only listing, because the writes happen through separate tools. It says nothing about ordering, whether every item has a downloadable PDF, or permission or authentication needs.

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 scope-defining sentence comes first and is followed by a two-sentence procedure, so the structure is front-loaded and there is little waste. The workflow has been folded into the description, which adds length but each sentence does carry actionable content.

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 is adequate for a zero-parameter listing tool, and because an output schema exists, the return shape does not need to be restated. It covers what gets listed, how to follow up, and how to handle ambiguity. What it leaves out, such as ordering and what to do when no PDF path is provided, is minor.

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, which is the baseline-4 case; there is no argument meaning to add. The description does mention the fields to extract (supplier, number, DUZP, VAT summary, country), but those belong to the downstream tools' parameters, not this 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 first sentence names a specific resource (documents the import could not read) and enumerates the three qualifying causes: missing ISDOC, foreign format, foreign supplier. That is a clear verb-plus-resource statement. The remainder shifts into a follow-up workflow rather than purpose, and it does not directly contrast with siblings such as list_invoices or sync_invoices.

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 says what to do with each result (read the PDF, then route to add_expense via pdf_path or to add_manual_invoice for issued documents), so the alternative tools are named with their selecting conditions, and it tells the agent to ask the user rather than guess on reverse charge or private use. It never states when not to use this tool, nor any precondition for calling it.

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, yet it says nothing about whether the result is paginated, ordered, capped, or scoped to a workspace/company. It implies a read-only listing but never states it explicitly, nor does it mention any limits on the number of returned invoices.

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 filler; the scope qualifier is placed at the end where it reads naturally. It is efficient but so terse that brevity shades into under-specification.

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 and both optional parameters are fully documented in the schema, which covers most of the load for a simple list tool. However, with no annotations and no statement of default filtering, ordering, or result limits, an agent still cannot predict what it will get back for a bare call.

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% — month is documented as YYYY-MM and status explains issued = unpaid, paid = paid — so the baseline is 3. The description adds only a loose hint about overdue invoices and does not clarify the default behavior when month or status is omitted.

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?

"Vydané faktury z evidence" largely restates the tool name (list_invoices) as a noun phrase, and the only added information is the scope note that overdue invoices are included. It does not distinguish this from siblings such as get_invoice (single invoice) or sync_invoices, leaving the agent to infer that this is the bulk retrieval path.

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 get_invoice, sync_invoices, or export_book. The one contextual hint — that overdue invoices are included — is useful but describes scope, not when to choose this tool.

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 the behavioral load. It does disclose that the lookup hits the external ARES registry and enumerates what comes back, which implies a read-only operation, but it says nothing about failure behavior for an unknown or malformed IČO, rate limits, or whether the call is free of side effects.

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: the action, the key parameter, and the returned fields, with no filler. Every clause earns its place.

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 one-parameter read tool with a full schema and an output schema, the description covers source, input, and returned fields. The remaining gap is the not-found / invalid-IČO case, which an agent would want to know before calling.

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% for the single parameter, and the schema already specifies 'IČO firmy (8 číslic)'. The description only restates 'podle IČO' without adding format, validation, or fallback guidance, so the baseline of 3 applies.

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 names a specific verb and resource ('Najde firmu') plus the data source (ARES) and the fields returned (název, sídlo, DIČ, registrace k DPH), which clearly separates it from the invoice/customer siblings. It does not explicitly contrast with a sibling like get_supplier, but the ARES-registry framing makes the distinction evident.

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: an agent can infer this is the tool for resolving a Czech IČO to company details, presumably to fill in customer or supplier data. There is no explicit statement of when to prefer it over get_supplier/add_customer, and no preconditions or exclusion cases 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?

Bez anotací nese popis plnou tíhu, ale podává jen účel — zmiňuje vazbu na daňovou evidenci skutečných výdajů, což je užitečný dopad operace. Neuvádí však, zda je označení vratné, co se stane při opakovaném volání, ani jaká oprávnění jsou potřeba.

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?

Jediná věta, ihned sděluje akci a objekt, bez zbytečných slov. Nic podstatného nechybí ani nepřebývá.

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?

Jde o jednoduchý mutační nástroj se dvěma plně popsanými parametry a existujícím výstupním schématem, takže popis je téměř dostačující. Rezervou je chybějící informace o chování při již zaplaceném výdaji a o možnosti vrácení.

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?

Krytí schématu popisy je 100 % (expense_id jako název PDF bez přípony, paid_date s defaultem dnes), takže popis nemusí parametry vysvětlovat. Popis k nim nic dalšího nepřidává, což při úplném schématu odpovídá základu 3.

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?

Uvádí konkrétní sloveso (označí jako zaplacenou) i objekt (přijatou fakturu/výdaj) a závorkou 'výdaj' ji odlišuje od faktur vydaných. Chybí však výslovné odlišení od sourozeneckých nástrojů 'mark_paid' a 'record_payment', se kterými se dá snadno splést.

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?

'Pro daňovou evidenci se skutečnými výdaji' naznačuje kontext použití (režim skutečných výdajů), ale není řečeno, kdy zvolit tento nástroj místo 'mark_paid' nebo 'record_payment', ani jaké jsou předpoklady (např. že výdaj existuje a není již zaplacený).

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 of behavioral disclosure, and it discloses almost nothing. It does not state whether the operation is idempotent, what happens to an invoice that is already paid or whose number is unknown, whether a payment record is created, or what permissions are required.

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 sentence with the verb and resource front-loaded, and it contains no padding. It is efficient, but the extreme brevity leaves little room to say anything useful for a mutation tool.

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?

This is a bulk mutation of financial records with no annotations covering safety or reversibility, and the description does not compensate. An output schema exists, so return values need not be explained, but the missing behavioral details and the missing comparison with record_payment or mark_expense_paid leave the definition inadequate for a tool that changes invoice state.

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%, and both parameters are documented in the schema, including the 'due' and default-today semantics of paid_date. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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 and resource: it marks invoices as paid. That implicitly separates it from mark_expense_paid, but it never names or contrasts with the similar siblings record_payment and mark_expense_paid, so an agent must infer the boundary from the tool 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?

The parenthetical '(napr. podle vypisu z banky)' gives one concrete usage scenario, which is useful context. However, there is no guidance on when to use this instead of record_payment, no prerequisites, and no exclusions, so the routing guidance is only implied.

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 add real context: the tool launches a browser UI and runs as a background LaunchAgent service. However it omits behavior an agent would want — whether calling twice reuses or spawns a second instance, where the browser opens, and that it returns immediately while the service keeps running.

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, front-loaded with the action and resource, then a single architectural note. Nothing is wasted and nothing is buried.

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 need no explanation, and there are no parameters to document. The only shortfall is the missing lifecycle detail (idempotency, port/URL, service installation), which is modest but real for a launcher tool.

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 no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool applies.

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+resource — opening a graphical dashboard in a browser — which is unambiguous. It also distinguishes itself implicitly from all siblings, none of which deal with a dashboard, though it doesn't say so 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 when-to-use guidance, no mention of alternatives, and no prerequisites such as whether the background service must already be installed. For a zero-argument launcher the implied usage is fairly clear, but nothing is stated.

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 does disclose the single most important trait — that nothing is reserved and the counter is not advanced — but omits whether the number could change before issuance, any permission requirements, or side effects. Adequate but not complete for an unannotated 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?

A single compact sentence with no waste, and the non-reserving caveat is placed immediately after the purpose. It is arguably terse enough to leave gaps, 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?

A one-optional-parameter read tool with an output schema, so return values need not be explained. The description covers purpose and the non-reserving guarantee; only explicit guidance on its relationship to issue_invoice is missing.

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%, with issue_date documented as YYYY-MM-DD defaulting to today. The description adds nothing about the parameter, which is acceptable given the schema already covers it, but it does not explain how the date affects the returned number.

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 resource and action: returns the next invoice number according to the records. The parenthetical '(nic nerezervuje)' distinguishes it from the write-side siblings such as issue_invoice, though the name itself carries much of that load.

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 non-reserving note implies a preview/peek use case, but the description never explicitly says when to call this instead of issue_invoice or how the result should be used. The distinction is implied rather than stated.

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, and it discloses almost nothing beyond 'records'. It does not say whether a new record is created, whether re-recording is idempotent, how it interacts with tax_overview or export_vat_return, or what permissions are required. For a financial mutation tool that is a significant gap.

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 the verb and resource first and the tax domains in parentheses. No filler, nothing to trim, and no burying of the key 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?

The rich input schema plus the presence of an output schema mean return values and field formats do not need restating. However, a six-parameter financial write tool with zero annotations and several adjacent payment tools leaves the agent without enough to decide confidently when this tool is the right one.

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%, with the kind enum, period format (YYYY-MM), paid_on, and tax_year defaults all documented in the schema. The description adds no parameter meaning beyond what the schema already provides, so the baseline 3 applies.

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: records a paid advance (záloha) or top-up payment (doplatek), scoped to four tax domains (income tax, social, health, VAT). An agent can tell this apart from generic payment tools like mark_paid. It stops short of a full 5 because it never names the tax-versus-invoice-payment boundary 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 only implied: the parenthetical list of tax kinds signals this is for tax authority payments rather than invoices. There is no explicit when-to-use/when-not, and no routing to siblings such as mark_paid or mark_expense_paid, which an agent must infer.

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 for a destructive operation. It implies removal from the records but says nothing about irreversibility, whether the deletion is soft or hard, what happens to linked payments or exports, or what permissions are required. Only the user-intent precondition is disclosed.

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 front-loaded sentence with a scoping clause after the dash. Nothing is redundant and the constraint arrives before any elaboration.

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 need not be explained, and the single required parameter is fully documented in the schema. However, for a destructive tool with no annotations, the omission of reversibility and side-effect information leaves a meaningful 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?

Schema description coverage is 100% and the single parameter already documents its format ('ID výdaje (název PDF bez přípony)'). The description adds no further meaning about the identifier, so the baseline of 3 applies.

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+resource ('Odebere přijatou fakturu z evidence' — removes a received invoice from the records) and pairs it with a scope condition. It does not name or contrast any sibling such as add_expense or mark_expense_paid, and the wording switches from 'expense' in the tool name to 'received invoice' in the text, which is understandable in-domain but not fully crisp.

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?

A clear precondition is given: use it only when the user has explicitly deleted the invoice or does not want it recorded. That is real when-to-use guidance. There is no when-not guidance beyond that and no alternative tool is named.

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 burden. It does disclose that this is an import/write operation ('načte ... do evidence') and that it only pulls new documents, which hints at incremental behavior, and it explains that unprocessed items surface through list_import_issues. It says nothing about what happens on duplicates, failed ISDOC parsing, permissions, or whether re-running is safe, which matters for a mutating sync with zero annotation coverage.

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 blocks: the sync action first, then the follow-up procedure. Nothing is redundant. The second part reads as an imperative instruction to the agent rather than descriptive documentation, which is efficient but slightly atypical in tone.

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 need no explanation, and with zero parameters the surface is small. What remains under-specified is the substance of the sync itself: what counts as 'new', what happens to documents that fail to parse, and whether side-effect records (expenses vs. invoices) are created automatically or only via the listed follow-up tools.

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, so there is nothing for the description to disambiguate beyond the schema. The baseline for a parameterless tool applies.

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 names a specific verb and resource: it fetches new PDFs from issued (ISDOC) and received (ISDOC/Alza) invoices into the ledger. That clearly separates it from siblings like list_invoices or get_invoice, which only read existing records. The phrase 'do evidence' (into the records) is slightly vague about what exactly gets created, which keeps this from 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?

It gives an explicit follow-up workflow for leftover documents: list_import_issues, then read the PDF, then add_expense or add_manual_invoice. That routes the agent to the correct siblings once the sync runs. It does not state when to skip the sync or how it relates to list_invoices/get_invoice for already-synced documents, so it falls short of full when/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 it usefully discloses a non-obvious side effect: it "automatically first loads new invoices from the Issued/Received invoice folders." That tells the agent the call triggers invoice ingestion before reporting, which is valuable and not derivable from the schema. It still omits whether the overall operation is read-only, what permissions are needed, and whether the auto-load is idempotent.

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 compact sentences/blocks: the first front-loads the reported metrics, the second covers the auto-load behavior and dashboard alternative. There is minor redundancy in the run-on metric list, but nothing that should 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?

An output schema exists and all parameters are documented, so the description only needs to convey purpose and the ingestion side effect, which it does. For a multi-metric aggregation tool the remaining gap—safety/return-shape—is largely covered by the output schema, leaving it adequately 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 100%, so year, method (ytd/3m), and with_forecast are already fully documented in the schema. The description adds nothing about how the period affects the reported figures, so it earns the baseline 3 rather than more.

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 enumerates the specific report contents an agent will get: income, tax and insurance estimate vs. advances, VAT for the period, unpaid invoices, flags, and deadlines. This makes it identifiable as an aggregated tax/finance overview rather than a single-record tool, though it uses a colloquial header ("Jak jsem na tom") instead of an explicit verb and doesn't directly name distinguishing siblings like export_vat_return.

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: "Grafický přehled: ucetka dashboard" hints that the visual dashboard is a separate route, implying this tool is for the data summary. There is no explicit when-to-use/when-not or named alternative in the tool family, so the agent must infer the division of labor.

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