DokladBot

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

Goes well beyond the annotations: it names the concrete external systems (Pohoda, ABRA Flexi) behind openWorldHint, confirms the idempotent no-double-send behavior declared by idempotentHint, and adds a side effect not in the annotations — the action is recorded in the document history. That is exactly the added context this dimension rewards.

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 core action, then layers default behavior, the opt-in flag, idempotency, and audit logging in short, purposeful sentences. Dense but every clause carries information; only marginal room to tighten.

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 full annotation coverage and no output schema, the description covers defaults, external side effects, idempotency, and history logging. Remaining gaps are minor: whether approval is reversible, required permissions, and the resulting document state are not stated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3; the description still adds meaning by clarifying that sendToAccounting defaults to non-accounting approval and that an already-forwarded document will not be forwarded again. It does not elaborate on comment or companyId, but those are already fully documented in 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?

States a specific verb and resource ("Schvali doklad") and immediately qualifies the two distinct approval modes (local-only vs. forwarding to accounting). This is unmistakably different from the sibling reject_document / bulk_reject_documents tools without needing to open 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?

Gives clear operational context: the default invocation is approval only, and the accounting forward is strictly opt-in via sendToAccounting. It does not explicitly name alternatives (e.g., when to reject instead) or state prerequisites/permissions, so it stops 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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavior beyond annotations: each document receives a history record and the response includes notFound and alreadyInAccounting categories, with already-accounting documents explicitly skipped. It stops short of covering permissions, reversibility, or whether the batch is atomic.

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 are front-loaded with the core action and limit, followed by side effects and return categories. Every sentence earns its place and no filler is present.

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 destructive bulk mutation with no output schema, the description supplies the return categories and skip behavior, which are essential for correct invocation. It could be slightly more complete by mentioning authorization requirements or whether rejection is reversible, but the core operational context 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 both ids and reason are already documented in the schema, including the 100-item limit. The description repeats the max-100 constraint and clarifies that the reason is shared, but adds no new syntax or meaning 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 states a specific bulk action ('Zamitne vice dokladu najednou') with a shared reason and a hard limit of 100. This clearly distinguishes it from the singular sibling reject_document without needing to open 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 for rejecting multiple documents at once with a common reason, which implies use over reject_document for batches. However, it does not explicitly name reject_document as the alternative for single-document rejection or state when not to use bulk mode.

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?

Beyond the annotations it discloses the critical precondition (source filing must be SUBMITTED/CONFIRMED/REJECTED), the side effect (produces draft XML and sends nothing), and that it overwrites any prior unsent correction draft. That last point is exactly the kind of consequence an agent needs before calling and is not derivable from destructiveHint=false or idempotentHint=true.

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 action and precondition are front-loaded, followed by kind semantics and then the non-submission/overwrite caveat. It is a dense run-on paragraph with semicolon-separated clauses, but every clause carries information an agent needs.

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 6-parameter mutation tool with no output schema, the description covers preconditions, side effects, overwrite behavior and kind selection, which is most of what is needed. The remaining gap is the meaning of the two numeric/pattern parameters (okec, cisloUfo).

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 50%, and the description compensates well for `kind` by explaining the enum values and the deadline-based fallback that the schema does not encode. However, `okec` and `cisloUfo` are undocumented in both schema and description, so the coverage gap is only partly closed.

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 and resource ('Pripravi opravu uz odeslaneho DPH podani') and immediately scopes it to filings in state SUBMITTED, CONFIRMED or REJECTED, which cleanly separates it from generate_vat_filing (new filing) and submit_vat_filing (sends). An agent can tell what this does 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 gives explicit conditions for choosing between the correction kinds – opravne before the deadline (full resubmission) vs dodatecne after it (differences only, line 66) – and states that kind is auto-derived from the deadline when omitted. The only gap is that it never names sibling tools (e.g. generate_vat_filing) as alternatives, so tool-level routing is inferred 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation safety profile is covered. The description adds real value beyond that: the created invoice waits for approval in the DokladBot dashboard and is never auto-sent to the customer, which is exactly the behavioral context an agent 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?

Two tight sentences with zero waste; the critical constraint (draft, not sent) is front-loaded in the second sentence.

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 output schema and 44% param coverage, the approval-workflow disclosure covers the most important gap but leaves return value (e.g., draft identifier) and several parameters unexplained.

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 only 44% across 9 parameters, and the description mentions no parameter at all. Parameters like buyerDic, buyerIco, buyerAddress, and note are undocumented in both places, so the description does not compensate for the coverage gap.

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 a draft of an issued invoice) and emphasizes 'NAVRH' so the agent knows no finalized invoice is produced. It does not explicitly name any sibling it contrasts with, but the sibling set is almost entirely read/list tools, so the operation is easily distinguishable.

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 draft-then-approve framing tells the agent this is the entry point for issuing an invoice, but there is no explicit when-to-use, no prerequisites (e.g., which company/credentials), and no mention of alternatives such as generate_vat_filing.

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?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=true; the description usefully clarifies that the 'destruction' is only a move to trash with full restorability, plus the accounting-program lockout. That is real added value, but it stops short of stating what the caller sees on success or on a blocked document, so the mutation's outcome remains implicit.

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 key framing (soft delete, not permanent) before the edge cases, and every clause carries information. The final sentence is dense, packing both the accounting-program restriction and the 'cannot reject either' analogy into one line, which slightly hurts scanability.

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, non-read-only operation with no output schema, the definition covers reversibility, escalation limits, and the blocking condition. Nothing needed to call it safely 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?

With a single required parameter and 100% schema coverage, the schema already documents 'id' and even points to list_documents as its source. The description adds no format or lookup guidance beyond that, so 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 ('Presune doklad do kose') and immediately qualifies it as soft deletion, which distinguishes it from the sibling restore_document and from any hard-delete expectation. An agent knows exactly what operation this performs 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?

Explicitly names the condition that blocks use (documents already sent to Pohoda/ABRA Flexi cannot be trashed, mirroring the reject path) and the recovery alternative (restore_document). It also rules out permanent deletion via the assistant entirely, so there is no ambiguity about trying to escalate.

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?

Beyond the annotations it discloses the most important trait: nothing is transmitted, only a draft XML is prepared, saved and must be sent separately from the dashboard after user review. It also mentions XSD validation against the Czech financial administration schema and that includePending=false is the default. It does not state idempotency (what happens if the same period is generated twice) or whether an existing filing is overwritten.

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 purpose and the non-sending caveat are front-loaded, and the remaining sentences carry operative rules rather than filler. It is dense with long parentheticals, so an agent must parse several clauses, but no sentence is purely 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?

There is no output schema, and the description compensates by describing the return payload: summary (tax liability or overpayment, return lines, KH sections, deadline), errors and warnings, and an XML download link. For an 8-parameter generation tool with a nuanced period model, the definition is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already carries each parameter's meaning; the description still adds real value by explaining the monthly-vs-quarterly conditional logic, the companyId default (main VAT-registered company, id from list_companies) and that includePending defaults to approved documents only. The okec and cisloUfo parameters are not elaborated on in prose, but their schema descriptions cover 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?

The description opens with a specific verb and resource ("Vygeneruje NAVRH XML podani DPH") and enumerates the three exact submissions produced, each mapping to a submissionType enum value (DPHDP3/DPHKH1/DPHSHV). It also explicitly separates this from sending ("Podani se NIKAM neodesila ... odeslani probiha vyhradne v dashboardu"), which distinguishes it from sibling submit_vat_filing.

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 the selection rule for the two mutually exclusive period parameters (monthly payer -> month, quarterly payer -> quarter 1-4 with quarterly period from company settings) and notes that a legal-person quarterly payer still files monthly KH, producing multiple submissions with khMonthly=true. It also covers an exclusion ("Identifikovana osoba kontrolni hlaseni nepodava") and the document-selection rule (approved only by default, DUZP else issue date, same as get_vat_summary).

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the concrete dimensions of the summary, but says nothing about the default time window, aggregation granularity, or currency, which materially affect the result.

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 enumerates the outputs with no filler. It is efficient, though extremely terse for a tool whose output shape is not defined anywhere else.

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, the description is the only source describing the return content, and it does list the key aggregates. It nonetheless omits the time scope and format of 'vyvoj v case', which an agent needs to interpret the response correctly.

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 schema is an empty object, so there is nothing for the description to disambiguate. Baseline 4 applies; no param-level gaps exist.

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 resource and enumerates the returned aggregates (prijmy, vydaje, pocty dokladu, vyvoj v case), so an agent knows it is an aggregated financial overview rather than a raw listing. It does not, however, distinguish itself from the closely related sibling get_vat_summary or explain how the cashflow scope differs from 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 when-to-use guidance, no mention of when to prefer get_vat_summary or list_bank_transactions, and no stated prerequisites or context (e.g. accounting period). The agent must infer the trigger condition 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that the value is current/point-in-time; it says nothing about currency, account scoping, or whether stale data is possible.

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 wasted words. It is a noun phrase rather than a full clause, which is terse but acceptable for a trivial read 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?

For a zero-parameter read with readOnly annotations and no output schema, the description is minimally adequate but leaves open what 'kredit' denotes (account credits vs. monetary balance) and what units or currency are returned.

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 of 4 applies. There is nothing for the description to clarify beyond what the empty schema already implies.

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 specific resource (credit balance) and qualifies it as current, which is enough to tell it apart from sibling reads like get_vat_summary or get_cashflow. The verb is only implied by the tool name, and there is no explicit differentiation statement against those siblings.

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 call this versus get_cashflow or other financial summary tools in the sibling set. The agent must infer that a point-in-time credit balance is the intended use case.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds no behavioral context beyond restating the purpose: no note on auth requirements, no indication of whether a missing/unconnected databox is an error or a normal response, and no rate or freshness information.

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 that is front-loaded with the core question. No filler, though it is arguably too terse to be maximally useful.

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?

There is no output schema, so the description is the only place an agent could learn what the returned status looks like (possible state values, what 'not connected' means). It stops at the purpose statement and leaves the response shape entirely unspecified, which is a real gap for a status-check 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% and the single parameter companyId is documented in the schema as coming from list_companies. The description adds nothing about the parameter, so the baseline 3 for fully-schematized params is correct.

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 (datova schranka / databox) and the specific question it answers: whether the company has one connected and what the connection state is. It is clear what the tool returns conceptually, but it does not distinguish itself from the sibling list_databox_messages, which an agent might also reach for when dealing with databox functionality.

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 call this versus alternatives such as list_databox_messages, nor any stated prerequisite (e.g. that it presupposes a valid companyId or a registered databox). The agent must infer the use case 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?

Annotations already declare readOnlyHint, non-destructive, and closed-world behavior. The description adds useful content-scope context: it includes VAT breakdown by rate and line items, but excludes the document file. It does not cover permissions or error behavior, but the annotations carry the safety profile.

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 states the resource and the included/excluded data with no wasted words.

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, the description usefully clarifies what the response includes and excludes. It is nearly complete for a one-parameter detail tool, though it could say more about error cases or exact returned 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 coverage is 100%: the single id parameter is documented as coming from list_documents. The description adds no parameter-level detail beyond what the schema already provides, so the baseline score 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 clearly identifies the tool as retrieving the detail of a single document, including VAT breakdown by rate and line items, and explicitly excludes the document file. It distinguishes itself from list_documents by scope (one document vs. list), though it does not name 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?

The description states what the tool returns but gives no explicit guidance on when to use it versus alternatives such as list_documents or search. Usage is only weakly implied by the name and description.

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?

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral caveat — 'orientacni' signals the calendar is indicative and not authoritative — but says nothing about the return format or how the window is applied.

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 fragments with no filler: the scope and subject come first, the indicative caveat second. Nothing is wasted, though the fragments are terse enough to feel clipped.

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 read-only calendar with one optional parameter this is nearly adequate, but with no output schema the description should at least sketch what a deadline entry contains (dates, obligation labels, applicability). That return-shape gap keeps it at minimum viable.

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?

One optional parameter with 100% schema coverage (including its default of 60 days and 1-365 bounds), so the schema fully documents the input. The description adds no meaning beyond that, which is the expected baseline when coverage is 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?

The description names a specific resource (upcoming tax deadlines) and scopes it precisely to Czech sole traders and VAT payers, enumerating the obligation types (VAT, ZP/SP advances, income tax). This clearly separates it from siblings like generate_vat_filing or get_vat_summary, though it does not explicitly name an alternative.

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 reach for this tool versus generate_vat_filing, list_vat_filings, or get_vat_summary. The word 'orientacni' implies it is informational rather than a filing action, but that inference is left to the agent.

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?

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: what fields the response carries, that XSD validation results and databox delivery receipts are included only for submitted filings, and that includeXml enlarges the response with the full XML.

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 that front-loads the resource and then enumerates the return contents, with the includeXml note last. Every clause carries information; the enumerated field list is long but each item is meaningful for decoding the response, given there is no output schema.

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, the description carries the full burden of explaining return values and does so exhaustively — status, validation, summary sections, addressee, reviewer/timestamp, and conditional databox delivery fields. Nothing an agent needs to call or interpret the result 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 coverage is 100%, so both parameters are already documented; baseline would be 3. The description adds value by clarifying the provenance of 'id' (from list_vat_filings or generate_vat_filing) and noting that includeXml injects the complete XML into the response rather than just a fragment.

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 (detail of one generated VAT filing) and enumerates the concrete payload: status, XSD validation result, summary, addressee, review metadata, databox delivery status. It also names the sibling tools that produce the id (list_vat_filings, generate_vat_filing), so an agent can place it in the workflow without opening a 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?

Explicitly says the id comes from list_vat_filings or generate_vat_filing, which tells the agent when this tool is the right next step. It does not state exclusions (e.g., use list_vat_filings instead when you only need the overview), 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?

Beyond the read-only and non-destructive annotations, it discloses document inclusion and exclusion rules, approval defaults, warnings, reverse-charge treatment, DUZP fallback logic, and turnover exclusions. These details expose substantial calculation and output behavior rather than merely restating the safety hints.

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 and key limitation are front-loaded, and nearly every sentence supplies a distinct operational rule. The long single paragraph is dense and harder to scan than a short structured summary, so its presentation is not optimal despite the low amount of redundant wording.

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 complex financial report with no output schema, it covers the principal outputs, warnings, exclusions, tax-date logic, and turnover field unusually well. The remaining gaps concern period-selection edge cases and explicit sibling routing rather than core behavior needed for a normal 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?

The schema already covers most arguments, and the description repeats much of the companyId and includePending behavior. It adds useful consequences of month selection and explains how documents are assigned to the selected period, but does not clarify the year-only default or how conflicting month and quarter values are handled.

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 defines a VAT summary for one company and period, including tax bases, VAT by rate, input/output amounts, and CZK currency. 'Podklad pro priznani, ne priznani samotne' clearly distinguishes it from filing-oriented siblings such as generate_vat_filing and get_vat_filing.

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 establishes the use case as supporting preparation of a VAT return, not producing the return itself, and also identifies monthly reporting and non-payer turnover use cases. It does not explicitly route users who need an actual filing to generate_vat_filing or get_vat_filing, so the alternative-selection guidance is incomplete.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one behavioral nugget -- that results include document-matching status -- but says nothing about pagination, ordering, or default scoping (e.g. companyId required to get meaningful data).

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, which is structurally sound. However it is arguably too terse for a 3-parameter list tool that is missing usage and parameter guidance.

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, the description should hint at return contents; it does mention matching status, which is useful, but omits pagination/limit behavior and the meaning of unrelated parameters. Annotations carry the safety burden, keeping this at a minimum-viable level.

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 only 67% (companyId has no description at all), and the description contributes nothing about limit, matched, or companyId. It does not compensate for the undocumented parameter or clarify default behavior beyond what the schema already states (min/max, default 50, enum meaning).

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 (bank transactions) and adds scope ('stazene' = downloaded) plus the matching-status facet. No sibling tool covers transactions, so no differentiation is strictly needed, but it does not explicitly contrast with list_documents or search.

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 indication of when to call this versus siblings such as search, list_documents, or get_cashflow, nor any prerequisite or context conditions. The agent must infer usage entirely from the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the result includes companyId, which is useful, but says nothing about scope (all companies vs. filtered), pagination, or ordering. With annotations carrying the safety burden, 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?

Two short sentences, both front-loaded and purposeful: the first defines the resource and its identifier, the second ties it to the downstream tools that need it. No 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?

With no output schema and no parameters, the description must convey what comes back, and it does (companies plus their companyId). A simple no-arg list tool does not need more, though a note on scope or whether all companies are returned would close the last 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?

The tool takes zero parameters, so the baseline is 4. The description's mention of companyId refers to a returned field rather than an input, but it correctly signals that no input filtering is needed.

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 specific verb+resource ('Firmy uzivatele' – the user's companies) and states the key returned field (companyId). It does not explicitly distinguish itself from sibling list tools such as list_suppliers or list_documents, but the resource 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?

The second sentence supplies real routing context: it tells the agent that the databox and VAT filing tools require companyId, which is exactly the value this tool yields. That is a clear conditional use case, though it stops short of an explicit 'use this tool when you need X' statement or naming the exact siblings (get_databox_status, generate_vat_filing).

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?

Beyond the readOnly/destructive/openWorld annotations, the description discloses high-value behavioral facts: listing does not trigger legal delivery, opening a message legally counts as delivery, and content download via AI is impossible. This is exactly the kind of side-effect and constraint context an agent cannot get from structured fields.

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 tight sentences, front-loaded with what the tool returns before the constraints. Every sentence carries distinct information (fields, no-delivery side effect, content-download prohibition) with no 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?

For a read-only listing tool with annotations covering the safety profile and no output schema, the description supplies the return fields plus the crucial legal/behavioral caveats. An agent has everything needed to call it correctly and to know what it must not attempt.

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 both parameters (companyId, days) are already documented in the schema; the description adds no parameter syntax, defaults, or format detail. Baseline 3 applies when the schema carries the parameter burden.

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+resource ('Seznam OBALEK prijatych pisemnosti') and enumerates the returned fields (sender, subject, date, status), so an agent knows exactly what the tool produces. It does not, however, name or contrast any sibling tool (e.g. get_document), so sibling differentiation is only implicit.

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 a clear usage context ('Cteni seznamu NESPOUSTI doruceni') and a strong exclusion ('Stazeni obsahu zpravy pres AI neni mozne'), telling the agent that content retrieval must happen elsewhere. The alternative is described as a workflow ('v dashboardu'), not as a named sibling tool, so routing is clear but not tool-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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: results are paginated, returned in a slimmed form without document files (only hasImage), and VAT-rate amounts are expressed in the document's currency.

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 tight sentences, front-loaded with the core purpose, then the return shape, then the currency caveat. No filler; each sentence carries distinct 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 12-parameter, no-output-schema list tool, the description covers purpose, return shape (slimmed, hasImage) and a non-obvious data caveat (VAT amounts in document currency). The main gap is the absence of routing guidance among the many sibling list/search 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?

Schema description coverage is 92%, so the schema already documents nearly every parameter including enums and formats. The description only alludes to filtering and fulltext generically and adds no syntax or semantics beyond the schema, 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?

The description states a specific verb and resource ('Vypis prijatych i vydanych dokladu') and names the concrete document kinds (uctenky, faktury) plus the filtering/fulltext capability. It is clearly a list operation, distinguishable from get_document, but it does not explicitly name the sibling it differs from.

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 by 's filtrovanim a fulltextem' – an agent can infer this is the tool for browsing/filtering documents. However, there is no explicit when-to-use vs when-not guidance, and no pointer to get_document for a single record or to search for cross-entity lookup.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral boundary (receivables only, never payables), but says nothing about result shape, ordering, counts, or whether the days window also affects overdue results.

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 tight sentences: what it returns first, the exclusion second. No filler, no restatement of the title, and the scope statement 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?

There is no output schema, so the description is the only place a caller could learn what a result row contains (debtor, amount, due date) — and it does not. For a simple two-optional-parameter read tool this is a modest gap rather than a blocking 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% and both parameters are documented there, including defaults ('vychozi 30', 'Vychozi overdue'), so the baseline of 3 applies. The description contributes nothing about how 'days' interacts with status=overdue, which is the one ambiguity worth clarifying.

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 (list issued invoices) plus scope: overdue or approaching due date, framed as 'who owes me'. It also explicitly excludes payables, so the agent knows this is receivables-only and cannot confuse it with a liabilities/cashflow query among the siblings.

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 negative routing is explicit: 'Zavazky k uhrade tento nastroj nevraci' tells the agent this is not the tool for payables. The status enum additionally encodes the overdue/upcoming/all modes, but the description never contrasts this tool with nearby siblings like get_cashflow or get_tax_deadlines.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds essentially no behavioral context beyond parameter intent — no pagination, ordering default, result count, or empty-result 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 compact sentence with the resource front-loaded and the optional modifiers trailing. Nothing is wasted, though the extreme terseness comes at the cost of the detail that usage and behavioral dimensions need.

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 three-parameter read tool with no output schema, the description omits the limit parameter, default ordering, and anything about what a supplier record contains. Combined with the missing sibling differentiation, an agent can invoke it but not 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 coverage is 67%, and the description maps onto the two richest parameters: 'top podle utraty' restates the 'spend' enum and 'fulltext filtr' corresponds to q. The 'limit' parameter (1-50) is undocumented in both the description and the schema, so the description only partially compensates.

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 clear verb+resource ('Seznam dodavatelu' = list suppliers) and names the two optional modes (top by spend, fulltext filter). It is understandable in one read, but it does not distinguish this tool from the closely related 'list_companies' sibling, leaving the agent to guess which list 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?

'volitelne top podle utraty nebo fulltext filtr' implies that the spend-sort and fulltext modes are opt-in refinements, which is usable context. However, it gives no explicit when/when-not guidance and never mentions the sibling list tools (list_companies, search), so the agent has no routing signal.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the default-resolution rule for the main VAT-payer company, which is genuinely useful behavioral context, but says nothing about what the listing contains or how year scoping affects results.

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, front-loaded with what is returned and followed by the scoping default. No filler; the only cost is that terseness comes at the expense of detail.

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, the description should hint at the return shape and at how 'year' filters results, and it does neither. For a two-parameter listing tool it is minimally adequate, but leaves real gaps an agent must guess at.

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 50%: companyId is documented in the schema and reinforced by the description's default rule, but the 'year' parameter is unexplained in both places. The description partially compensates for the coverage gap on companyId but leaves year's filtering semantics entirely to inference.

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 uses a specific verb ('Drive vygenerovana' = lists previously generated) plus a precise resource (VAT filings) and even enumerates the subtypes (priznani, kontrolni a souhrnne hlaseni). It implicitly contrasts with the singular get_vat_filing and with generate_vat_filing, 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?

It gives one useful conditional: omit companyId and the main company is used if it is a VAT payer. But it never says when to prefer this list tool over get_vat_filing (single) or generate_vat_filing, nor any prerequisites, so usage 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?

Annotations already declare destructive=true, idempotent=true, readOnly=false, so the safety profile is covered. The description adds real value beyond that: the rejected document is excluded from VAT and export, the action is reversible via approval, and an audit entry is written to document history.

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, each carrying distinct information: action, consequences, reversibility, audit trail. The core action is front-loaded and nothing is 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 two-parameter destructive mutation with no output schema, the description covers effect (VAT/export exclusion), reversibility, and audit logging. Only the interaction with bulk_reject_documents and any permission requirements are 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 100%, so both parameters (id, reason) are already documented in the schema, including length bounds. The description only echoes 'with a reason' plus examples, adding marginal meaning. 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?

Names a specific verb (rejects) and resource (document) and adds the reason argument with concrete examples (duplication, private expense). It doesn't explicitly contrast itself with approve_document or bulk_reject_documents, though the reversal sentence hints at the approval relationship.

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 examples of rejection reasons imply when the tool applies, and the reversal note implies the inverse operation belongs to approve_document. However, no explicit when-to-use predicate or reference to bulk_reject_documents for multi-document cases 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?

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds a genuinely non-obvious side effect: the restore is recorded in the document's history, which matters for audit-trail reasoning. It stops short of describing error behavior when the document is not in the trash.

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, purpose front-loaded, and the behavioral note second. 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 one-parameter mutation with full schema coverage and no output schema, the description covers what it does and its main side effect. Only precondition/error semantics (document must be in the trash) are missing, which is a minor 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 'id' parameter is already documented as the ID of a document in the trash. The description adds no format, sourcing, or lookup guidance beyond that, 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: returns a document from the trash back among documents. This is clearly distinct from siblings like delete_document, get_document, and update_document. It does not explicitly name or contrast with a sibling, 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 implied by 'z kose' (from the trash): call this to undo a deletion. However, it never states the precondition that the document must currently be in the trash, nor what happens if it is not, and it names no alternatives or exclusions.

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?

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only the scope of searchable resources; it says nothing about result format, limits, or whether companyId restricts the corpus, so it adds limited value beyond the annotations.

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, front-loaded sentence with no redundant phrasing. It is efficient, though its extreme terseness leaves little room for the missing guidance noted elsewhere.

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, the description should carry more weight: it does not explain what a result contains, how many results come back, or how the search corpus relates to the companyId parameter. For a search tool with 17 siblings, this leaves the agent under-informed.

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 only 50%: q is documented in the schema, but companyId has no description anywhere. The description mentions no parameters at all and does not compensate for the undocumented companyId, so an agent cannot tell whether it scopes the search to one company.

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 (fulltext search) and enumerates the searched resources (documents, invoices, suppliers), so the agent knows what this does. However, it does not distinguish itself from siblings like list_documents, list_suppliers, or get_document, which also surface those entities.

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 indication of when to prefer this fulltext search over the sibling list_* tools or get_document. Usage is only weakly implied by the word 'fulltext,' and no prerequisites or exclusions are 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?

Anotace deklarují destructive=true, idempotent=true a openWorld=true; popis jde výrazně nad ně a vysvětluje předpoklady odeslání (stav REVIEWED, bez chyb validace, XSD, připojená datová schránka, ještě neodesláno) i to, že opakované volání podruhé neodešle. Právní účinky a obsah náhledu jsou uvedeny.

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?

Je front-loaded a informačně hustý – každá věta nese funkční obsah (náhled, podmínky, právní varování, stav). Je nicméně velmi hutný, výčet obsahu náhledu mohl být stručnější.

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?

Mutující nástroj s právními účinky a bez output schema: popis pokrývá předpoklady, co vrátí náhled, a kam se obrátit pro stav doručení. Pro správné volání agentovi nic podstatného nechybí.

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?

Schéma má 100% pokrytí, takže baseline je 3; popis však přidává význam parametru confirm – co přesně náhled obsahuje a jaké podmínky musí platit pro skutečné odeslání. U id odkazuje na list_vat_filings, což je užitečné doplnění.

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 a objekt (odešle DPH podání – přiznání, kontrolní nebo souhrnné hlášení) a kanál (datová zpráva z připojené datové schránky). Agent okamžitě ví, co nástroj dělá, a odliší ho od validate_vat_filing, generate_vat_filing nebo get_vat_filing.

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?

Explicitně říká, kdy použít confirm=true a kdy ne (bez něj jen náhled), a přidává tvrdou podmínku: použít až po výslovném souhlasu uživatele s náhledem. Pro stav doručení odkazuje na get_vat_filing, takžealternativa je jasná.

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?

Annotations already declare the safety profile (readOnly=false, destructive=true, idempotent=true), and the description usefully adds side effects beyond them: VAT-breakdown edits recompute base and VAT totals, foreign currency is re-converted at the CNB rate to DUZP, and the change is logged to document history. It does not address the destructive angle named by the annotations — e.g. that 'note' overwrites the existing value, or that fields omitted from the call stay untouched versus being cleared — so the added context is real but partial.

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, each carrying a distinct fact (fields, VAT recalculation, FX conversion, audit trail), with the field list front-loaded. No filler or repetition, though it could be tightened into fewer, more structured clauses.

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 destructive 15-parameter mutation with no output schema, the description covers the main computational side effects but leaves important operational questions open: partial vs. full replacement semantics, whether locked/approved documents can be edited, permission requirements, and what a successful response contains.

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 60%, so the baseline is 3. The prose explains the semantic consequence of the VAT-rate fields (recalculation of base and VAT totals) and the currency conversion rule, which is genuine value beyond the schema, but it never mentions totalAmount, receiptDate, or the null-means-clear convention that the schema defines for taxDate and companyId.

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 and resource ('Opravi udaje dokladu') and enumerates the mutable fields (date, DUZP, VAT-rate amounts, type, company, note), so an agent knows exactly what class of operation this is. It does not explicitly differentiate itself from siblings such as correct_vat_filing or delete_document, which keeps it 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?

There is no when-to-use guidance, no exclusion of alternatives, and no stated prerequisites (e.g. whether an approved/filed document may still be edited, or when to prefer correct_vat_filing over editing amounts). The agent must infer usage purely from the verb and field list.

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?

Annotations only declare the safety profile (not read-only, non-destructive, closed-world). The description adds genuinely new behavioral context: files go into a processing/approval queue rather than being stored directly, and processing consumes account credits — an important cost side-effect not captured anywhere else. It still doesn't say whether the upload is synchronous or what happens on rejection.

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 tight sentences with the action and accepted formats front-loaded, followed by the queue/credit consequence. No filler; could arguably be one clause shorter but every sentence 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?

For a 3-parameter upload tool with no output schema, the description covers the action, accepted inputs, downstream workflow, and the credit cost. The main gap is the return value (e.g. a document/queue ID) and any file-size limits, but overall it is complete enough to invoke correctly.

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 67% and all three params are required and documented in the schema. The description reinforces the accepted MIME types (PDF/JPG/PNG) and that content is base64, but adds no syntax, size-limit, or prefix details beyond what the schema already 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?

States a specific verb (nahraje/upload) plus the resource (uctenku nebo fakturu) and the accepted formats, and explains the destination (queue for processing and approval in the dashboard). It clearly distinguishes itself from read-side siblings like list_documents or get_document, though it doesn't name any 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?

Usage is implied rather than stated: the agent can infer this is the tool for submitting a receipt/invoice file, and the mention of 'fronta ke zpracovani a schvaleni' hints at the async workflow. There is no explicit when-to-use vs. when-not-to-use guidance or named alternative (e.g. create_invoice_draft for pre-approval drafts).

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?

Goes well beyond the readOnly/non-destructive annotations by confirming no write occurs and describing the output shape (errors and warnings plus a summary with deadline) and the concrete failure classes detected. It omits severity semantics or whether results block submission, so not 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?

Front-loaded with the core purpose and read-only nature, then parameters. The long parenthetical check list is dense and slightly hard to scan, but every item names a concrete validation, so little 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 7-parameter, no-output-schema tool it supplies purpose, defaulting behavior, period selection rules, and a description of what the result contains. Remaining gap is the undocumented okec and cisloUfo parameters, which an agent cannot reason about from the definition alone.

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?

Adds real meaning for companyId defaulting and for month-vs-quarter selection by payer type, which the 71%-covered schema only partially expresses. However, okec and cisloUfo are left unexplained in both schema and description, so the gaps are not fully closed.

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 action (period check before VAT filing) plus the crucial disambiguation 'nic neuklada' (saves nothing), which separates it from generate_vat_filing, submit_vat_filing and correct_vat_filing in the sibling list. The parenthetical enumeration of what is checked further pins down 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?

Explicitly frames usage as a pre-submission check ('pred podanim DPH') and gives payer-type routing rules (monthly -> month, quarterly -> quarter) plus the default-company behavior. It does not explicitly say when to skip it or name an alternative validator, so it falls short of a 5.

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