DokladBot

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 only declare readOnlyHint=false, destructiveHint=false, openWorldHint=false. The description adds the crucial behavior that the output is a mere draft with no external side effect ('NIKAM neodesila') and that sending is out-of-band, which is exactly the kind of disclosure annotations cannot convey.

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 core action front-loaded and the no-send constraint placed immediately after. No wasted framing, though the capitalization of 'NAVRH' and 'NIKAM' is stylistic noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-required-param generator with no output schema, the description covers what is produced and its lifecycle. It does not describe the returned artifact format (file/id/location) or whether regeneration overwrites a prior draft, which are minor gaps.

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

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

Schema coverage is 100%, including enum descriptions for submissionType, so the schema already carries the parameter meaning. The description's gloss of priznani/kontrolni matches the enum docs and adds no new format or constraint detail.

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 (vygeneruje) and resource (navrh XML podani DPH) and scopes it to a month with two concrete variants (priznani / kontrolni hlaseni). It is clearly distinguishable from sibling read tools like list_vat_filings or get_vat_summary.

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?

Makes the usage context clear: this only prepares and stores a draft, while actual submission happens in the dashboard after user review. It does not name sibling alternatives (e.g. list_vat_filings for reading existing filings), so it stops short of explicit 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?

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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one piece of behavioral value – that the payload includes a per-rate VAT breakdown – which matters because there is no output schema, but it says nothing about missing-document behavior, permission needs, or response shape otherwise.

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 compact sentence with the resource up front and the payoff (VAT breakdown) trailing. Nothing is wasted, and it is well matched to the complexity of a single-parameter getter.

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 lookup with full schema coverage and annotations, the description covers what the tool fetches and what the payload contains (VAT breakdown), which compensates for the absent output schema. It is nearly complete, missing only edge-case or error context.

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 documented in the schema as coming from list_documents. The description adds no further parameter semantics, 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 specific verb+resource ("detail jednoho dokladu" = detail of a single document) and adds the return scope (VAT breakdown by rate), so the agent can distinguish it from list_documents. It stops short of explicitly naming the sibling it differs from, but the singular-vs-list distinction is clear from the description and 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?

Usage is only implied: the singular "jednoho dokladu" and the required id parameter signal this is the lookup-by-id path after list_documents. There is no explicit when-to-use/when-not statement or named alternative, leaving the agent to infer 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?

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=true, destructiveHint=false and openWorldHint=false, so the safe read-only profile is covered structurally. The description adds useful content scope (breakdown by rate, input vs output), but says nothing about aggregation level, period semantics, or what happens when month/quarter are omitted. No contradiction with 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?

Two dense sentences, zero filler: the purpose and scope come first, then the disambiguating clause. Nothing is repeated from the title or 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?

For a read-only summary with no output schema, the description conveys what the summary contains but not its granularity (per-rate lines? per-month?), nor the required year plus optional month/quarter interaction. With annotations covering safety and a partly documented schema, this is adequate but leaves small gaps.

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

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

Schema description coverage is 67%: year and month carry descriptions (month even notes the quarter/month exclusivity), and quarter is a self-explanatory enum. The description itself adds no parameter meaning beyond the schema, so the baseline of 3 is appropriate for medium-to-high coverage.

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 (VAT summary for a period) and enumerates its contents: bases and tax by rate, input and output. It even disambiguates from the sibling generate_vat_filing by noting it is the basis for the return, not the return itself, though it never names that sibling 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?

"Podklad pro priznani, ne priznani samotne" clearly routes the agent: use this for supporting VAT figures, and the actual filing is a different operation. It implies the alternative without naming a specific tool or listing exclusions, so it stops 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.

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 that results are paginated, which is useful, but says nothing about default ordering, filter combination behavior, or limits beyond what the schema states.

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 no filler, and the core scope (what is listed) is front-loaded. The second sentence efficiently covers the return shape.

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 5 optional filters, no output schema, and no required parameters, the description only minimally covers return behavior ('strankovany seznam'). It is adequate but leaves filter interaction and ordering unexplained for a tool whose whole value is filtered listing.

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 80%, so type, limit, search, and status are already documented in the schema. The description adds no parameter-level detail beyond reiterating that filtering and fulltext exist, 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 ('Vypis ... dokladu') and scopes it to both received and issued documents with example types (uctenky, faktury). It implicitly distinguishes itself from the singular get_document sibling, though it never names that sibling 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?

Mentions that filtering and fulltext are available, which hints at use cases, but gives no explicit when-to-use guidance or exclusion criteria relative to get_document, search, or list_overdue_invoices. 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description's one value-add is disclosing that only *unpaid* documents are returned, a filter semantic not stated in the schema. It says nothing about result volume, pagination, or what the defaults produce.

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 zero filler. It is not padded, but it is also so terse that it omits information an agent would benefit from, which keeps it below a 5.

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-required-parameter read tool with full schema coverage and annotations covering safety, the description is adequate but minimal. It omits routing guidance versus the many neighbouring list_* tools, which is the main 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 both parameters (days window, status enum) are fully documented in the schema itself, which sets the baseline at 3. The description adds only a loose hint that an 'upcoming' window exists, without explaining the days/status interaction.

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 Czech description names a specific resource and scope: unpaid documents (neuhrazené doklady) that are past due or approaching due date. An agent can tell this apart from generic siblings like list_documents or list_bank_transactions. It does not name a sibling explicitly, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to choose this tool over alternatives such as list_documents or list_bank_transactions, nor any mention of prerequisites. Usage is only implied by the resource noun.

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 safety is covered. The description adds scope detail (it returns both priznani and kontrolni hlaseni), but says nothing about pagination, ordering, or what happens for a year with no filings.

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, and the key scoping concept ('previously generated') is front-loaded. It is terse to the point of under-specification, but no sentence 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?

With no output schema and no annotations about return shape, the description should carry more of the load: it never says what fields a filing record contains, how results are ordered, or how 'year' affects the list. For a tool whose sibling generate_vat_filing creates the same entities, this leaves meaningful gaps.

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

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

Schema coverage is only 50%: the 'year' parameter has no description anywhere, and the description does not explain whether it filters by filing period or filing date, or whether it is optional. The companyId description in the schema already covers the other parameter, so the description adds nothing.

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: listing already-generated VAT filings (returns and control statements) for a company. The word 'Drive' (previously generated) implicitly separates it from the sibling generate_vat_filing, though it never names that sibling 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?

'Drive vygenerovana' implies this is for retrieving existing filings rather than creating them, which is useful context against generate_vat_filing. However, no explicit when-to-use/when-not guidance or alternative tools are named, so the routing signal 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 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?

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.