Konverter Pro

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

Annotations declare a non-read-only, non-destructive, non-idempotent mutation, and the description adds real context beyond them: the answer is persisted for future files of the same client unless remember=false. That persistence side effect is exactly the kind of disclosure an agent needs and is not in the annotations. It does not cover failure modes or what happens to unmatched questions.

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 tightly written sentences with the core action front-loaded and the persistence caveat second. No filler, though 'whole question groups' adds ambiguity rather than precision.

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?

No output schema exists, so the description should say more about outcomes — e.g. what is returned, whether partial answers are accepted, or what happens to an invalid account. For a mutation tool that also changes future state, the picture is adequate but incomplete.

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 67% schema coverage, the description usefully explains the account format and the remember default. However, it never addresses the language parameter or the job_token linkage, and 'to whole question groups' is ambiguous against the schema's per-question_id array structure.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a concrete verb and resource: assigning an account number (4-8 digits, the user's chart) to question groups. That is a meaningful clarification of the otherwise vague name 'answer_questions'. It stops short of naming the sibling list_open_questions, so an agent must infer the pairing.

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

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

There is no explicit statement of when to call this versus list_open_questions, nor a prerequisite note that a job_token from upload_statements is required (only the schema says that). The one conditional it does give — remember=false — is about behavior, not tool selection.

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, openWorldHint=true, and idempotentHint=false; the description adds the non-obvious consequence that a new link invalidates the previous one and that payment occurs outside the tool. It also clarifies that file release is a separate step (download_result). Missing the currency/amount context and failure behavior, but the value-add over annotations is real.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each doing work: what it is, how to use the result, and the replacement caveat. The parenthetical is information-dense but not wasteful; the opening describes the artifact rather than the action, which slightly delays the verb.

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 only two parameters, no output schema, and full annotation coverage, an agent has what it needs: what's created, what to do with the link, the next step, and the replacement semantics. It could say more about the returned value's shape and required job state, but nothing critical is absent.

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

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

Schema coverage is 100% and both parameters are documented in-schema, including job_token's origin from upload_statements and the language default. The description adds no parameter-level detail, so the schema carries the full burden and baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the concrete artifact ('A Stripe payment page for the quoted files') and its accepted methods (card, other methods, invoice with VAT), so the agent knows this produces a payable link rather than a quote. It does not literally say 'creates a link', but the resource and scope are unambiguous against siblings like get_price_quote.

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 spells out the workflow: produce the link, show it to the user, then call download_result once paid. It also warns that 'a new link replaces the previous one', which implies when to create one. It stops short of stating prerequisites such as requiring a prior quote or job in a specific state.

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 (which only say non-read-only, non-idempotent, non-destructive), the description adds real behavioral facts: links expire after 1 hour and a verification value is returned alongside them. It does not explain why the call isn't idempotent (e.g. repeated calls mint new links) or whether payment gating produces an error an agent could handle.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single dense paragraph that front-loads what the file is before moving to availability, return values and per-format requirements. Some clauses ('once it is ready and paid (or covered by the API key's plan)') are run-on, but nothing is padding.

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

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

With 8 params, a nested object and no output schema, the description covers the essentials: gating condition, returned links and their expiry, the verification value, and conditional per-format inputs. The remaining gap is that 'the verification' is never defined, and error behavior when the job is unpaid is unmentioned.

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

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

Schema coverage is 100% and the schema already documents each parameter with patterns, enums, defaults and conditionality, so the description's format-specific notes (datev.berater_nummer / mandanten_nummer for anonymous jobs, account_iban for MT940) largely restate what is already there. A baseline 3 is appropriate, with no meaningful extra meaning added.

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 action (download the final, verified file) and enumerates the concrete output artifacts (DATEV Buchungsstapel, Lexware CSV, MT940), so an agent knows exactly what it produces. It does not explicitly distinguish itself from the closest sibling, get_preview, which is the main thing keeping 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?

It gives a clear precondition for use: the file must be ready and paid (or covered by the API key's plan). That context tells an agent when to call it, but it never says to poll get_job_status first or that get_preview exists for an early look, so alternatives and exclusions are left implicit.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is a polling endpoint, cost is per-file, and the payload includes verification detail plus a 'next step', which tells the agent this tool drives the workflow rather than just reporting a flag.

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 followed by one imperative polling instruction, front-loaded with the scope ('Per file'). No wasted clauses, though the field list is packed tightly enough that readability suffers slightly.

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 burden of describing returns and does so at a useful level of abstraction (state, verification, blockers, open questions, next step). What is missing is what a completed or terminal state looks like and how to distinguish it, which would complete the polling loop.

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

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

Schema coverage is 100% with both parameters documented, including that job_token comes from upload_statements and language defaults to 'de'. The description adds no parameter-level detail beyond the schema, 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?

The description names the resource (job status) and enumerates what is returned per file: processing state, verification results, format readiness with blockers, open questions and next step. It is clearly a status/verification read, distinguishable from siblings like download_result or get_preview. Minor deduction for domain jargon ('KP's verification') that an agent without context may not parse.

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 instructs polling 'every few seconds until every file is read', which is real operational guidance. It stops short of naming alternatives or when-not-to-use (e.g., use list_open_questions to resolve blockers, download_result once ready), so the routing is implied rather than stated.

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

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

Adds real behavior beyond the annotations: previews of unpaid jobs are truncated to the first pages, output is draft-marked, and the returned link expires after 1 hour. Annotations only declare the non-read-only/non-idempotent/non-destructive profile; the description supplies the cost, truncation and expiry semantics that matter for planning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with what the tool returns and immediately followed by the constraints (partial pages, draft marking, 1-hour link). 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?

Covers the output (download link) and its lifetime, but for an 8-parameter tool with a nested object and no output schema it says nothing about the DATEV-header/MT940-balance requirements for anonymous or balance-less statements, nor about whether a preview can be re-requested for the same job (annotations mark it non-idempotent). Adequate but with clear 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 100%, with enums and the nested DATEV object fully documented, so the description need add nothing. It mentions no parameter at all, leaving format, file_id and the DATEV/MT940 arguments entirely to the schema — acceptable baseline, no added value.

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 (a preview of the job output) and its distinguishing traits: free, partial for unpaid jobs, watermarked as draft. It never names the clear sibling contrast (download_result returns the real deliverable), so differentiation is implied rather than asserted.

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 inferable from 'free preview ... draft so it is not imported by mistake', which hints this is the pre-purchase inspection path, but there is no explicit when-to-use/when-not and no alternative tool is named for the full result.

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?

The description adds substantial behavioral context beyond the annotations: it discloses the pricing units, minimum charge, VAT treatment, and the special case where a KP API key causes the customer's plan to pay. Annotations already cover safety and idempotency, so this added billing behavior is the main value here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences and front-loads the pricing formula. It is dense but every clause contributes useful information, with no obvious 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, non-destructive tool with full schema coverage and no output schema, the description sufficiently explains what the returned quote represents and how it is calculated. It does not describe error states or quote expiration, but those are secondary for this tool's complexity.

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

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

Schema coverage is 100%, and both parameters are already documented in the schema. The description adds context about what the returned price applies to (ready, unpaid files) but does not add syntax or meaning for the parameters themselves.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool returns the price of a job's ready, unpaid files, and explains the pricing formula. It is specific about the resource and computation but does not explicitly distinguish its role from sibling tools like create_payment_link.

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

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

There is no explicit guidance on when to call this tool versus alternatives such as create_payment_link or get_preview. The billing formula implies it is used to determine cost before payment, but the description leaves that inference 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 readOnly, idempotent, non-destructive and closed-world, so the bar is lower. The description adds genuinely useful context not in the schema: that results are grouped per KP's review and each group carries a proposal, count, total and examples. No pagination or size behavior is mentioned, which keeps it from 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?

Two compact sentences, return shape described first and the action directive second, with no filler. The first sentence is dense and slightly awkward ('grouped like KP's review'), 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, the description carries the return-shape burden and does describe the group fields and examples. What is missing is minimal: no note on volume/limits or what happens when there are zero open questions, but an agent has enough to call it correctly and know what to do next.

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

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

Schema description coverage is 100%, with job_token, file_id and language all documented in-schema including the file_id fallback case. The description adds nothing parameter-specific, 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: lists bookings that could not be assigned to an account with certainty, and describes the grouping (booking type, counterparty, single booking). This is clearly distinct from siblings like get_preview or download_result, and an agent can tell what it returns 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?

The closing sentence 'Answer them with answer_questions' explicitly routes the agent to the correct follow-up tool. It does not state exclusions or prerequisites (e.g. job must be finished), but the pairing with answer_questions is clear enough to act on.

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 non-read-only, non-idempotent, non-destructive behavior. The description adds important context beyond them: anonymous jobs without a KP API key, free preview, pay-per-job for final output, and 7-day data deletion, which materially affects whether an agent should start a job.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core action and workflow, and each sentence contributes input types, file delivery, return value, or pricing/auth behavior. The long list of file formats is dense but appropriate, and there is 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 complex 8-parameter upload tool with nested file objects and no output schema, the description covers the essential entry-point workflow, file input modes, job_token return, default target, and anonymous-job behavior. It leaves minor gaps such as the 20-file limit and duplicate handling to the schema, which is acceptable.

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 75%, so the schema already documents most parameters. The description adds useful context for file delivery via content_base64 or https URL, the job_token, and the default DATEV target, but it does not explain chart, language, client_number, or force_duplicate 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 action (start a conversion job or add files with job_token), the exact input types (German bank statements and payment-provider reports), and the output targets. It is immediately distinguishable from siblings such as get_job_status and download_result, which are downstream consumers of the job_token.

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 implicitly positions itself as the entry point by saying it returns a job_token for all further tools, and explicitly distinguishes starting a job from adding files to an existing job. It does not name sibling alternatives or state when not to use it, but the workflow context is clear.

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