SofortFax (KI-Fax-Credits)

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

Annotations already declare readOnlyHint=false and destructiveHint=false; the description adds real behavioral context beyond them — the 30-minute validity window, accepted formats (PDF, JPG, PNG, camera), and 10 MB size cap. It also states the tool sends nothing, which is useful reassurance for a preparatory action.

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 dense sentence that front-loads the primary action before the constraints and follow-up. Every clause carries information (validity, formats, size, next step, cost), though the density makes it slightly harder to scan than separate lines would.

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-value burden, and it does so implicitly — upload_url is referenced and upload_id is mentioned as the input to send_fax. That covers the essentials for a zero-parameter tool, leaving only minor ambiguity about the exact returned field names.

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 coverage is 100%, so there is nothing for the description to clarify. Baseline 4 is appropriate for a no-parameter tool.

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 ("Erstellt einen sicheren Einmal-Upload-Link") and immediately binds it to a purpose ("für das Fax-Dokument"). It also names the follow-up sibling send_fax, so an agent can place it in the fax workflow 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?

Describes the workflow clearly: user opens upload_url, uploads the file, then call send_fax with the upload_id. The "Kostet nichts und sendet nichts" line clarifies the tool's role versus the send step. It lacks an explicit when-not-to-use or a direct sibling comparison, but the sequencing leaves little ambiguity.

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, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds one useful non-annotation detail: the balance is scoped to 'dieses Keys' (this API key), not the whole account. It does not add return format, rate-limit, or freshness context.

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 identifies the returned resource and its scope. No filler or redundant restatement of the title.

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-only balance lookup with no output schema, the description conveys the essential return value (remaining fax credits) and its per-key scope. It could be slightly richer about output units/format, but nothing an agent needs in order to call it correctly is missing.

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

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

The tool takes zero parameters and the schema is a closed empty object, so there is nothing parameter-level for the description to clarify. Baseline 4 applies for a parameterless tool.

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 ('Zeigt' / shows) and a specific resource ('verbleibende KI-Fax-Guthaben (Credits) dieses Keys'). This is clearly distinct from siblings like get_fax_price (pricing) and get_fax_status (status), so an agent can select it without ambiguity.

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 gives no when-to-use or when-not-to-use guidance, and does not mention the sibling tools. For a balance-check tool, the context of use (e.g. before sending a fax vs. checking price or status) is left entirely 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description does add real operational context — 1 credit per fax, capped at 40 pages — which is genuinely useful for cost reasoning, but it never says what the check returns or what happens on a disallowed number.

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

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

Two tight sentences with no filler, and the validation purpose is front-loaded. Slight deduction because the second sentence shifts topic to pricing rather than reinforcing the tool's core behavior.

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 should carry the return semantics — yet it never states whether the tool returns a boolean permission, a price, or a credit cost. For a zero-required-parameter query tool this leaves a meaningful gap.

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

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

Schema coverage is 100% with both parameters described, so the baseline is 3. The 'bis 40 Seiten' phrasing corroborates the schema's 1–40 range but adds no interpretation of what happens if pages is omitted or how fax_number affects the result.

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 name promises a price lookup, but the description actually describes a permission check ('Prüft, ob eine Faxnummer erlaubt ist') plus a pricing note. The verb+resource is present but the two sentences point at different purposes, and no sibling (send_fax, get_fax_status, get_account_balance) is distinguished.

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

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

No indication of when to call this versus get_account_balance (cost/credits) or get_fax_status (status). There are also no stated prerequisites, even though the tool validates a fax number before sending.

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, idempotentHint and non-destructive, so the safety profile is covered. Because there is no output schema, the description adds genuine value by disclosing the returned status vocabulary and the conditional transmission-report link after delivery, though it omits error behavior for an unknown fax_id.

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 first, then the status vocabulary, then the conditional report link. The parenthetical enumeration is long but every item earns its place by telling the agent which states to expect.

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 return values and does so reasonably well (statuses plus report link). Somewhat thin on failure/edge behavior for an invalid fax_id and on the link's format, but sufficient for a simple idempotent read 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?

There is a single parameter with 100% schema description coverage, so the schema already documents fax_id adequately. The description adds nothing about the parameter beyond what the schema states, which matches the baseline 3 for 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 (returns) and resource (fax status), and enumerates the six possible status values so an agent knows exactly what this tool reports. It is clearly distinct from the siblings send_fax, get_fax_price and create_upload_link, which perform write, pricing and file-handling tasks respectively.

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 contains no when-to-use, prerequisite, or alternative-selection guidance; it only says what the tool returns. The workflow hint (fax_id comes from send_fax) lives in the schema, not the description, so the description itself gives the agent no routing information.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful scoping fact that results are limited to this AI credit key's faxes, but says nothing about ordering, pagination beyond the limit parameter, or how status values are represented.

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 the scope and returned field front-loaded and zero filler. It is efficient, though the terseness leaves room for one more routing sentence without becoming bloated.

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

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

For a one-parameter, read-only list tool with full schema coverage and no output schema, this is close to sufficient: the agent knows the scope, the result content, and the limit. Missing only ordering guarantees, which is minor for a simple history 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 100% — the limit parameter's range and default (1–50, Standard 10) are fully documented in the schema. The description adds nothing about the parameter, so the baseline 3 for a single well-documented param 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 ("Listet"), resource ("Faxe") and scope ("dieses KI-Credits-Keys"), plus what is returned ("mit Status"). It implies a recency-ordered list, distinguishing it from the single-item get_fax_status, but never names that sibling to make the split explicit.

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 prerequisites, and no mention of the obvious alternative get_fax_status for a single fax. The agent must infer that this tool is the bulk/recent-listing variant purely from the word "letzten".

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 declare non-read-only, open-world, non-idempotent, non-destructive; the description adds genuinely new facts: a 1-credit cost with a 40-page ceiling, that confirmation/delivery-report/thank-you mail are sent to 'email', and that the result distinguishes sent vs. scheduled vs. unpaid. It does not explain irreversibility of a sent fax or failure/refund behavior, which a paid mutation of this kind warrants.

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 purpose, cost and the confirmation requirement, then the document options, then the outcome semantics. Dense but every sentence carries decision-relevant content; the document enumeration is long but mirrors eight real parameters, so the length is largely earned.

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 an 8-parameter, nested-object, no-output-schema mutation tool, the definition covers cost, required user confirmation, all input routes, scheduling window (present in schema) and the semantic shape of the result, so an agent need not guess at return values. Minor omission: no guidance on retry/idempotency after an ambiguous result, which matters given idempotentHint=false.

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 baseline is 3, but the description goes further by explaining the choice logic between the four document parameters and their origin (upload_id comes from create_upload_link, file is auto-populated by ChatGPT, base64 is only for very small files). That is decision-relevant meaning beyond the field descriptions.

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

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

States a specific verb and resource ('Sendet ein echtes Fax über SofortFax') and immediately distinguishes itself from the read-only siblings by naming the price model and the triggering of a real-world action. An agent can tell it apart from create_upload_link (a prerequisite) and get_fax_status (the follow-up) 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?

Gives clear operational context: obtain user confirmation of number, document and schedule first, and routes file input among four mutually exclusive sources, explicitly pointing to create_upload_link as the preferred path for on-device files. It stops short of naming when to prefer send_fax over the sibling list in a workflow sense, but the required preconditions are explicit.

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