FrankKi

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'listet' is consistent with that, so there is no contradiction. The description adds the partner address-book scope and optional filtering as context, but it does not disclose pagination behavior, result format, or other side effects beyond what annotations establish.

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 short and front-loads the core action, but it repeats the same content in German and English, creating redundancy. The bilingual duplication may be intentional, but it prevents the description from being maximally concise.

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 list tool, the description covers the resource and search filters, and annotations cover the safety profile. It still leaves limit and reasoning undocumented and provides no guidance on when to choose address_search_company instead, so it is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meaning. It clarifies that searchQuery can filter by name, city, or client, but it leaves limit and reasoning undocumented, making those parameters ambiguous for an agent.

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

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

The description uses the specific verb 'Listet' (lists) with the resource being 'addresses in the partner address book' and states optional filters by name, city, or client. It clearly conveys the operation, though it does not explicitly contrast it with the sibling address_search_company, so it stops short of full sibling differentiation.

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 explains that the tool lists addresses and may optionally be filtered, implying a read/listing scenario. However, it gives no explicit when-to-use guidance, no exclusions, and does not mention alternative tools such as address_search_company or address_upsert.

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

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

Annotations already declare the operation read-only and non-destructive, and the description aligns with that by using 'Sucht' and 'liefert' rather than mutation verbs. It adds useful context about the directory scope and the authority PO box, but it does not disclose behavior for no matches, multiple matches, or malformed queries.

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 short and front-loaded with the core purpose, and the bilingual German/English pair makes it broadly readable. The English translation duplicates the German sentence exactly, adding length without new information, which keeps it from a perfect score.

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 parameter documentation, the description is the only source of behavioral and semantic context. It covers the return value in general terms but leaves the country/reasoning parameters undefined and gives no guidance on result ambiguity or edge cases, so an agent cannot fully predict the tool's behavior.

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 input schema has no parameter descriptions (0% coverage), so the tool description must clarify parameters. It clarifies that the search targets company/authority names and makes query semantics inferable, but it does not explain the optional country parameter or the reasoning parameter at all.

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 and resource: searching companies and public authorities in a directory and returning the matching mailing address, including authority PO boxes. This clearly differentiates the tool from sibling address tools like address_validate (validation) and address_list (listing).

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 implies the tool should be used when an agent needs a directory lookup for a company or authority mailing address. However, it does not state when to prefer an alternative, such as address_validate for validation or address_list for browsing, nor does it mention any exclusions.

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

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

Annotations already establish readOnlyHint=false and destructiveHint=false, so the mutation profile is known. The description adds the useful behavioral fact that the address is validated using country-specific rules. However, it does not disclose upsert semantics, such as whether addressId selects an existing record for update, what happens on validation failure, or whether omitted fields are preserved or overwritten.

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

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

Two compact sentences, in German and English, front-load the operation and validation behavior without extraneous detail. The bilingual duplication is justified in a German-context tool and every sentence contributes meaning.

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

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

For a 12-parameter upsert with no output schema, the description is too thin. It omits create-vs-update selection, country defaulting, validation failure behavior, and any explanation of the listed address attributes. An agent would need to infer or probe the tool to call it correctly in non-trivial cases.

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 8%, so the description needed to carry most parameter meaning, but it does not. It only broadly implies that fields like name, street, and city are address-book attributes and that country matters for validation. It fails to explain the create-vs-update role of addressId, the meaning of isDefault, addressType, mandantennummer, or behavior around required fields.

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: 'Creates or updates an address in the partner address book' and adds a distinct behavior, country-specific validation. This clearly separates it from read-only siblings like address_list and address_search_company, and from address_validate, whose exclusive purpose is validation. The bilingual text reinforces the intended resource and operation.

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 makes the usage context clear: call this tool when an address needs to be created or updated in the partner address book. It does not explicitly name alternatives or state when not to use it, such as directing validation-only needs to address_validate. Thus it provides clear context but no exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context beyond that: 'the address book is left untouched', 'country-specific rules', and the specific failure result 'ADDRESS_INVALID'. The only minor gap is no mention of success return values or soft-warning behavior, so it's not a full 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?

The description is compact and front-loaded: first sentence states purpose and result, second sentence clarifies non-mutation and routes to the alternative. The bilingual version is not wasteful; every sentence carries meaningful 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?

The description covers purpose, read-only behavior, and the hard-failure result, and it identifies the correct sibling for mutations. However, with 12 parameters and no output schema, it omits what a successful validation returns, how soft failures are handled, and any input-format expectations. This is adequate but has 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 only 8% (only 'country' is documented), and the description does not compensate. It does not explain the meaning or expected format of name, street, city, zip, houseNumber, or other parameters, nor how they relate to the validation logic beyond the generic 'address' context. This leaves the agent to infer parameter semantics from the schema alone.

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

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

The description states a specific verb and resource ('validates an address using country-specific rules') and a concrete outcome ('reports hard failures as ADDRESS_INVALID'). It also explicitly distinguishes itself from address_upsert by naming it as the tool for creating or changing an address, so an agent can tell them apart immediately.

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 explicit usage guidance: it is 'a check only' and should not be used for mutation, and it directly names the alternative tool (address_upsert) for creating or changing an address. This leaves no ambiguity about when to choose this tool over its sibling.

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 semantic unit ('Beträge sind Netto-Kosten in Cent'), which prevents misreading the numbers, but says nothing about caching, freshness, or result size for a metrics endpoint.

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 bilingual DE/EN pairing is duplicated but that is inherent to the tool's convention, and each sentence front-loads the metric list followed by the unit caveat. No filler beyond the required translation.

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 content, and it does so by naming every metric family plus the amount unit. It is nearly complete for a read-only reporting tool, missing only result shape/detail per metric.

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 high (83%), so the schema already documents topN, since, until, metric and months bounds and defaults. The description only mentions that cost_per_mandant and delivery_times are time-scoped, which the schema also states, so it adds little beyond the baseline.

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 ('Liefert die aggregierten Kennzahlen des Partnerkontos') and enumerates the exact metric families returned. This clearly separates it from siblings like wallet_balance or pricing_tiers, which report different data.

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 enumeration of metrics implies when the tool is relevant (reporting/rebilling overview), but it never states when to prefer it over alternatives or what prerequisite state is needed. Usage is inferred rather than directed.

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 flag destructiveHint/readOnlyHint; the description adds substantial behavioral context beyond that: dual OAuth scope requirements, a human-in-the-loop fallback path via approvalUrl, a 10-minute dispatch delay after agent approval, and the cancellability window via order_cancel. These are exactly the operational traits an agent needs before committing a destructive 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?

Content is front-loaded and dense, but the entire text is duplicated in German and English, roughly doubling length for the same information. The scope rule, the human fallback, and the cancellation window are all useful, but the bilingual mirroring is pure redundancy.

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

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

For a destructive mutation with no output schema, the description covers the essentials: permission prerequisites, the human fallback, post-approval timing, and reversibility. Minor gaps remain around the undocumented comment/reasoning params and no contrast with the _app sibling.

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 0%, so the description must carry the load. It clarifies the decision enum semantics ('approve' vs 'reject') and references the returned approvalUrl, but says nothing about comment, reasoning, approvalId, or clientOrderId, leaving three of five parameters undocumented anywhere.

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 clear verb-resource pair ('Gibt eine wartende Freigabe frei oder lehnt sie ab' / approves or rejects a pending approval) with the decision alternatives spelled out. However, it never differentiates itself from the sibling approval_decide_app, which appears to be a near-namesake, leaving an agent to infer the distinction.

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 explicit conditional guidance: 'approve' is only permitted when the OAuth connection carries approval:self_approve, otherwise the human must open the returned approvalUrl, and approval:decide is also required. It also names order_cancel as the follow-up escape hatch within 10 minutes. It stops short of stating when to prefer this tool over approval_decide_app.

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 readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the description carries extra burden. It adds crucial behavioral context beyond annotations: the permission requirement (approval:self_approve), that card view and cardNonce are only preview evidence, and that missing permission routes to the browser. It still omits what happens to the approval record on approve vs reject and whether the effect is reversible.

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 duplicated in German and English, roughly doubling its length with no added information. Most sentences earn their place, but the bilingual repetition wastes tokens and is not front-loaded; the key permission condition is buried after the generic opening.

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 0% schema coverage, the description covers the critical gating condition and fallback, but leaves the semantics of decision, reasoning, and approvalId unexplained, and does not describe the return behavior of a successful call. It is adequate but not complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains cardNonce only as 'preview evidence', which is useful, but adds no meaning for approvalId, decision, or reasoning beyond what the schema types/enums already imply. Baseline is 3 for low coverage; the cardNonce hint is a small addition but the other three parameters remain undescribed.

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

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

The description states a specific verb and resource: 'App-internes Entscheidungs-Tool' / 'Internal app decision tool' that approves or rejects based on an OAuth permission. This is clearly distinguished from siblings like approval_decide and template_decide_app by the 'app-internal' scope and the OAuth requirement. However, it never explicitly names the artifact being decided on (approval) or the possible decisions, relying on the schema for that.

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 condition for when a call 'may approve': when the verified OAuth connection carries approval:self_approve. It also explains fallback behavior when permission is absent (the card leads to the signed-in browser). It does not explicitly contrast this with approval_decide or template_decide_app, but the app-internal framing and permission gating imply the separation.

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 behavioral details beyond the readOnlyHint annotation: newest-first ordering, time-limited PDF preview, included fields, and the default pending filter. This gives the agent useful expectations about the output and its constraints without contradicting 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?

The description is compact and front-loaded with the main purpose, followed by the default behavior and the follow-up tool. It is bilingual, which duplicates content, but both languages carry the same key information and the extra length is modest and intentional for accessibility.

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 list tool with five optional parameters and no output schema, the description conveys the key return elements (approvalIds, PDF preview, cost, reason, deadlines) and the default pending state. The main missing piece is a note about pagination behavior, but limit/offset are self-explanatory from the schema.

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 80% schema description coverage, the baseline is 3. The tool description does not add parameter-specific semantics; it only mentions default pending status, which relates to the 'status' parameter already documented in the schema. The 'reasoning' parameter lacks both schema and description coverage, but the high overall schema coverage keeps this at baseline.

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

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

The description states a specific verb and resource: 'Lists your account's approvals, newest first' with concrete fields (PDF preview, cost, reason, deadlines). It also distinguishes itself from the sibling approval_decide by explicitly directing the agent to use that tool for the returned approvalIds, which is more than a generic listing description.

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 provides clear context for when to use this tool: to retrieve approvals before making a decision, and explicitly names approval_decide as the next step. It also clarifies the default status filter ('Only the pending approvals by default'). However, it does not explicitly state when not to use it or mention alternatives like approval_status_app for single-status lookup.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about time-limited links and the expiration-triggered renewal, which is beyond the annotations. However, it does not disclose whether new URLs are returned, whether old links are invalidated, or what happens if called before expiry.

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 compact and front-loaded with scope and action. The bilingual German/English repetition is somewhat redundant but acceptable in a multilingual context; both versions say the same thing without extra fluff.

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 tool with safe-read annotations, the description is mostly usable: an agent knows when to call it and what it does. However, there is no output schema and no mention of the return value or what the renewed links look like, so an agent is left unsure about the tool's result.

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 0% and the description does not explain the approvalId parameter at all. An agent must infer from the tool name and context that approvalId identifies the relevant approval card. The description does not compensate for the lack of schema-level parameter documentation.

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

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

The description states a specific verb ('erneuert' / 'renews'), a specific resource ('Bildlinks der Briefseiten' / image links of the letter pages), and a clear scope ('Nur fuer die interaktive Freigabe-Karte'). It also adds the condition 'wenn die alten abgelaufen sind', which distinguishes this renewal tool from generic URL/list tools like letter_page_urls_app or template_page_urls_app.

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 explicitly says this is for the interactive approval card only, and gives a clear trigger condition: renew links when the old ones have expired. It does not name alternative sibling tools explicitly, but the 'only for the interactive approval card' constraint provides a clear exclusion boundary.

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 caller-side rationale (rendering end state and countdown on a stale card) but no auth, rate-limit, or idempotency details beyond that.

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?

Short and front-loaded with the scoping restriction before the explanation. The bilingual DE/EN duplication is mildly redundant but does not obscure the message.

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 single-parameter read tool with annotations covering safety and no output schema, the description is sufficient to call it correctly. It could note the expected return shape, but the absence of an output schema lowers that obligation.

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 0% and the description never mentions approvalId or its UUID form. With only one required parameter and no compensating text, the description adds no meaning beyond the schema's type declaration.

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 (reads the current state of an approval) and scopes it ('for the interactive approval card only'). This implicitly separates it from approval_list and approval_decide, though no sibling is named explicitly.

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

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

The phrase 'For the interactive approval card only' gives a clear when-to-use constraint and warns against general use, which is strong context. It does not, however, name alternatives such as approval_list or approval_decide for other workflows.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, but the description adds substantial behavioral context beyond them: it validates mandatory details, creates a final PDF, calculates price, reserves cost, inserts into the approval queue, and explains that dryRun leaves balance and queue untouched. It also clarifies card/portal behavior after submission.

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

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

The purpose is front-loaded and the workflow is logically ordered, but the full German and English duplication doubles the length without adding new information. The description is not bloated for a complex tool, yet it could be tighter by avoiding duplicate text and grouping related parameter 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?

For a 29-parameter tool with low schema description coverage and no output schema, the description covers the workflow and side effects well but leaves significant gaps around parameter roles and return/result expectations. It is minimum viable but not fully complete for an agent to invoke confidently with all optional parameters.

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 29 parameters and only 28% schema description coverage, the description must compensate but does not. It mentions high-level concepts like Pflichtangaben, Empfänger, AVV, Limits, and dryRun, but leaves most parameters (content, recipient fields, templateId, scheduledAt, etc.) unexplained. It also references approval:self_approve, which is not present in the approvalMode enum, adding ambiguity.

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 ('submits a letter') and the exact workflow goal ('for human approval'), then enumerates validation, PDF creation, pricing, cost reservation, and queue insertion. This clearly distinguishes it from approval_decide, approval_list, and letter_create_draft by making it the submission step.

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 clear context for use: submitting a letter for human approval, with conditional behavior for approval:self_approve and dryRun. It does not explicitly name alternatives like approval_decide or letter_create_draft, so exclusions are absent, but the intended invocation context is clear.

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, which correctly characterizes this as a non-destructive scheduling operation. The description adds the useful detail that the call returns a job ID rather than the export artifact itself, which helps manage agent expectations. It does not disclose asynchronous behavior in more depth (e.g., that results may be delivered later or that jobs can fail after scheduling), but that is partly covered by the sibling status tool.

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

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

The description is compact: one German sentence and one English translation, with the primary purpose and return value front-loaded. Each clause earns its place by conveying the schedule semantics and the job-ID mechanism. The minor redundancy between the two languages is acceptable for bilingual coverage and does not materially bloat the entry.

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 tool with no output schema and 0% schema description coverage, the description provides the essential scheduling semantics but not enough detail on optional parameters, delivery behavior, or how to correlate the returned job ID with archive_export_status. The presence of the close sibling archive_export_status mitigates the gap, but a fully complete definition would explicitly mention polling and explain the optional filter/notification fields.

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

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

Schema description coverage is 0%, so the description should compensate, but it only clarifies 'format' indirectly by listing formats in prose and establishes that 'since'/'until' define the export date range. It leaves 'target', 'reasoning', 'notifyEmail', 'senderProfileFilter', and 'mandantennummerFilter' unexplained; an agent must guess their semantics from names alone. The format enum provides self-documenting options, which keeps this at a baseline 3, but the description does not compensate strongly enough 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?

The description uses a specific verb ('plant ein' / 'schedules'), names the resource ('Archiv-Export'), and enumerates the supported formats (GoBD-CSV, DATEV, PDF-Bundle, Mandanten-Allokation). The distinction that it returns a job ID for status polling helps clarify it from a potential immediate-export tool, but it does not explicitly differentiate it from archive_export_status, which is the obvious sibling.

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

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

The description states a clear trigger: schedule an export for a date range and receive a job ID, and the sibling list contains archive_export_status, implying that one would call this tool first and then poll with the returned ID. However, it never explicitly says 'use archive_export_status to check progress' or lists conditions under which another archive tool would be preferred, so the cross-tool routing is only implied, not stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with that read-only profile. It adds behavioral detail beyond the annotations by disclosing that the download URL is valid for 90 days and only appears once the job is complete.

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 short and front-loaded, putting the core status and URL behavior in the first sentence. The German and English lines repeat the same information, which is slightly redundant, but the bilingual presentation still keeps the description compact and readable.

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 low-complexity tool with one required parameter and no output schema, the description covers the essential behavior: it returns job status and, when complete, a download URL with a 90-day validity. It does not enumerate possible status values or failure behavior, but that is a minor gap for a simple poll-style status 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 0%, so the description should compensate for missing parameter documentation. It only refers to 'an archive export job' and never explains the required jobId parameter or the optional reasoning parameter. While jobId's UUID format is self-explanatory, the description adds no parameter-level 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 opens with a specific verb ('Liefert'/'Returns') and names the exact resource: the status of an archive export job. It also adds the completion condition and the 90-day download URL, making the tool's role unmistakable and distinguishing it from archive_export by function and name.

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 clearly frames the tool as a status-retrieval endpoint for a previously created export job, which strongly implies it should be used after archive_export to check completion and obtain the download URL. It does not explicitly name archive_export as the counterpart or state when not to use it, but the contextual signal is clear.

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 minimal annotations, the description discloses rich behavior: server-side scaling to A4 PDF, optional rotation, page-count validation (max 30), automatic EXIF orientation handling, and the fact that rotation applies on top of EXIF correction. It also clearly implies a persisted write operation, consistent with readOnlyHint=false.

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 main action and format, then covers transformation, limits, and rotation. It is concise despite being bilingual; the English repetition adds length but also makes the content robust for mixed audiences. No filler or vague marketing language.

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

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

The core operation and transformation rules are well covered, including the page-count limit and EXIF behavior. However, there is no description of the return value or result confirmation (no output schema), no explanation of the position/title/reasoning parameters, and no guidance on the precedence or mutual exclusivity of imageUrl versus imageBase64.

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 43%, so the description must compensate, but it only elaborates on rotation (mostly repeating the schema) and the accepted image formats. It does not explain title, letterId, position, reasoning, or how to choose between imageUrl and imageBase64. This leaves the majority of parameters under-documented.

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

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

The description opens with a specific verb ('Lädt ... hoch'), a concrete resource ('ein Bild (PNG/JPEG) als Anhang zu einem Partner-Brief'), and states the server-side conversion to an A4 PDF page. This clearly separates it from sibling attachment_upload_pdf, since the input format and transformation are 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?

The description gives clear context: use this tool when you need to attach a PNG/JPEG image to a partner letter and have it converted to PDF. It does not explicitly name the sibling attachment_upload_pdf or state 'for PDFs use that tool instead,' but the image-only restriction and conversion behavior make the intended use evident.

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 discloses validation behavior beyond the annotations: file size max 50 MB and merged page count max 30 pages including the letter and other attachments. This informs the agent about important failure conditions that are not visible in the schema or annotations. It doesn't mention side effects or what happens on validation failure, but the added constraints are meaningful.

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 bilingual and repetitive, but each language contains a clear purpose sentence followed by a validation sentence. There is no filler, and the action is front-loaded. The duplication makes it longer than strictly necessary, but it remains tightly structured.

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

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

The description covers purpose and validation limits, but for a 6-parameter mutation tool with no output schema it leaves gaps: it doesn't state that at least one of pdfUrl/pdfBase64 is required for a successful call, nor explain the role of position, title, or reasoning. It is adequate for basic understanding but incomplete for reliable invocation.

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 33% (only pdfUrl and pdfBase64 have descriptions). The tool description adds no parameter-level guidance: it doesn't explain letterId, title, position, or reasoning, and doesn't clarify that pdfUrl and pdfBase64 are mutually exclusive alternatives. With low schema coverage, the description fails to compensate.

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

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

The description states a specific verb and resource: 'Lädt ein PDF als Anhang zu einem Partner-Brief hoch' / 'Uploads a PDF as an attachment to a partner letter.' The PDF qualifier clearly distinguishes this tool from the sibling attachment_upload_image, and the partner-letter context separates it from other upload tools like letterhead_upload or signature_upload.

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 provides clear context for when to use the tool: when a PDF needs to be attached to a partner letter. It does not explicitly name alternatives or exclusions, such as pointing to attachment_upload_image for images, but the purpose statement leaves little ambiguity about 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?

Goes beyond the annotations by disclosing the write side effect that found logos are persisted as design assets in the account, and by clarifying that no brand is actually adopted until a separate brand_kit_save call with brandingOwnershipConfirmed. This explains the non-read-only annotation and sets expectations that the result is a reviewable proposal rather than a committed change. It does not quantify cost, rate limits, or what happens to existing brand 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?

The content is front-loaded and the proposal-then-save sequence is stated early. However, the entire description is duplicated verbatim in German and English, roughly doubling the length without adding information, which conflicts with the requirement that every sentence earn its place.

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

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

There is no output schema, so the description must carry the return-value burden, and it does: it enumerates exactly what the proposal contains (colours, typeface mapping, logo candidates, imprint data) and where the logos are stored. A three-parameter tool with full schema coverage is adequately covered by this.

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

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

Schema description coverage is 100%, so the schema already documents websiteUrl, reasoning, and maxLogoCandidates with constraints. The description adds no per-parameter semantics (e.g. how the logo count affects cost or quality), so the baseline of 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 and resource ('Liest eine öffentliche Firmenwebsite aus und schlägt daraus ein Briefkopf-Design vor') and enumerates the concrete outputs (brand colours, mapped typeface, logo candidates, imprint data). It is clearly distinguishable from siblings like brand_kit_get and brand_kit_save, which it explicitly names as the adoption step.

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

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

Explicitly frames the workflow: this tool only produces a proposal ('Das Ergebnis ist ein Vorschlag zur Abstimmung mit der Kundin oder dem Kunden'), and adoption requires a follow-up brand_kit_save carrying brandingOwnershipConfirmed. It routes the agent well, but does not state when not to use it (e.g. when a brand kit already exists and brand_kit_get should be used instead).

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 return payload (logo references, colours, font), which is genuinely useful, but says nothing about permissions, absence behaviour when no kit exists, or format specifics.

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 text is essentially duplicated across German and English, doubling length without adding information, and it contains a filler keyword-hack sentence ('Suche technisch nach brand_kit_get') that carries no meaning for an agent. The useful content (read brand values, returns logo/colours/font, feeds design tools) could be stated in one 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 read-only getter with annotations and no output schema, the description does cover the expected return content, which is the main thing an agent needs. It is nonetheless thin on scoping (whose brand kit, per user/workspace) and on the purpose of its one parameter.

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 0% and the single 'reasoning' parameter is undocumented in both the schema and the description, so the description fails to compensate for the gap. With only one optional parameter and no enums the cost is limited, but the 'reasoning' field is left entirely unexplained.

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

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

The description states a specific verb and resource ('Liest die gespeicherten Markenwerte' / reads the saved brand values) and enumerates what comes back (logo references, colours, font). It is distinguishable from brand_kit_save and brand_import_from_website by being the read side, though it does not explicitly name them as the write/import counterparts.

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 points the agent downstream ('für die weitere Gestaltung mit letter_design_preview und letter_design_save'), which implies when this tool belongs in a workflow. However it gives no when-not guidance and does not contrast with the obvious alternatives (brand_kit_save, letterhead_list, sender_profile_get), leaving the choice largely to inference.

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, destructiveHint=false and openWorldHint=false, so the write/safety profile is covered. The description adds genuinely new context: the ownership-confirmation gate for usage rights and the fact that the response returns saved state plus a review link.

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 action is front-loaded and the ownership prerequisite is well placed, but the full German text is duplicated verbatim in English, doubling length for no added information, and the meta-instruction "Suche technisch nach brand_kit_save" consumes space without helping invocation.

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 correctly states what the response contains (saved state and review link), and it covers the key prerequisite and the nested brandKit fields. Reasonably complete for a save tool, with only the reasoning parameter left unaddressed.

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

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

Schema description coverage is only 33%, with just brandingOwnershipConfirmed documented in the schema. The description partially compensates by explaining that parameter's semantics and by naming the brandKit contents (logo, colours, font), but it never mentions the "reasoning" parameter, leaving a gap for a low-coverage 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 leads with a specific verb ("Speichert"/"Saves") and enumerates the resource (logo references, colours, font) plus its scope (the user-facing letterhead & brand result). It is clearly distinguishable from brand_kit_get and brand_import_from_website, though it does not explicitly name 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?

Implied usage only – the agent can infer this is the write counterpart to brand_kit_get, but no when-to-use vs. when-not or alternative is stated. It does disclose one real prerequisite (brandingOwnershipConfirmed must be true), which is the most useful usage signal present.

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

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

Annotations only declare write/non-destructive/closed-world. The description adds real behavior beyond them: FrankKi re-computes and rejects mismatching sums, the draft carries no cost until sent, the layout is DIN 5008 with the user's letter design, and mandatory § 14 UStG details are validated. It still says nothing about permissions or quota/rate limits on document creation.

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

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

The core sentence is front-loaded and efficient, but the entire description is duplicated in German and English, including the identical JSON example twice, which roughly doubles length without adding information. The bilingual duplication costs more than the marginal accessibility benefit at this length.

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 compensates by naming the returned letterId and the three tools that consume it, and by explaining the document payload semantics and the recompute-and-reject rule. Given 15 parameters and deep nesting, more could be said about the unillustrated top-level fields, but an agent has enough to call it correctly in the common case.

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 47%, below the bar where the schema alone suffices. The embedded worked example meaningfully illustrates the nested 'document' payload (documentType, documentNumber, leistungszeitraum, zahlungszielTage, lineItems, totals) plus recipientAddressId, but roughly half the top-level parameters (designId, signatureId, senderProfileId, reference, sequenceScope, clientLetterId, mandantennummer, language) get no mention at all.

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

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

The description names a specific verb and resource ('Erzeugt aus strukturierten Belegdaten ein fertiges Dokument und legt es als Briefentwurf an') and enumerates the distinctive pipeline: recompute line items/net/VAT/gross, § 14 UStG mandatory-detail check, optional number draw, DIN 5008 typesetting with the letter design. That makes it separable from the plain-letter sibling letter_create_draft without opening either schema.

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

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

It gives clear downstream routing — order_send sends, approval_submit routes to a human, letter_schedule defers — and notes the draft is free until sent, which is useful context. But it never states when to choose this tool over letter_create_draft or what prerequisites (e.g. sender profile, address book entry) must exist first. Usage is implied rather than 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 only cover the safety profile (readOnly, non-destructive, closed-world), so the description adds substantial behavioral context: signed export links (ZUGFeRD PDF/A-3, XRechnung XML), that transmission to a portal is the caller's job, and the meaning of DOCUMENT_EXPORT_NOT_READY (retry) vs DOCUMENT_EXPORT_NOT_SUPPORTED (permanent, with the workaround).

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?

Content is front-loaded and every section is informative, but the entire text is duplicated verbatim in German and English, roughly doubling length without adding meaning. For a single-ID fetch tool this is heavier than necessary.

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 does the work of explaining the return shape, export URLs, error semantics, and follow-up tools, which is thorough. The remaining gap is that neither input parameter is described anywhere.

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 0% and the description says nothing about documentId (format, source, how to obtain it) or the reasoning field. It explains return payload fields, which are not parameters, so it fails to 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 ('Liefert ein Dokument mit allen Belegdaten') and enumerates exactly what is returned: Positionen, Summen, USt-Sätze, Bezug, letterId, orderId. An agent can immediately distinguish this single-document fetch from the sibling document_list.

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 concrete downstream routing: paste referencePrefill unchanged into document_create for Mahnung/Zahlungserinnerung/Gutschrift, and points to order_status for tracking the send. It never explicitly contrasts document_get with document_list, but the usage context is clear.

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; the description adds useful behavioral detail: scope to the user's created documents, newest-first ordering, and filter dimensions. It does not mention pagination behavior or response shape, but for a read-only list operation that is a minor gap.

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

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

The description is front-loaded with the core purpose and next-step routing, and it is not overly long. The German and English sections duplicate each other, which adds some redundancy, but it remains compact enough for an agent to parse quickly.

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 9-parameter read-only list tool with no output schema, the description covers the main scope, sort order, filters, and workflow links. It could be more complete by stating that it returns summaries (via the document_get hint) or describing the remaining parameters, but it is sufficiently complete for selection and basic invocation.

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 only 44% schema description coverage, the description helps by naming filter categories (type, client, recipient, referenced document) that map to documentType, mandantennummer, recipientQuery, and referencesDocumentId. However, it leaves several parameters (since, referencesNumber, reasoning) semantically uncovered and does not clarify the distinction between referencesNumber and referencesDocumentId.

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 ('Listet/Lists'), the resource ('deine erzeugten Dokumente / documents you created'), the concrete document types, and the ordering ('neueste zuerst'). It also names sibling tools document_get and document_create as next steps, so an agent can distinguish listing from fetching or creating.

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 clear context: use this tool to list/filter created documents, then follow up with document_get for full payloads or document_create for follow-up documents. It does not explicitly list exclusions or alternative list tools like letter_list, but the next-step routing provides adequate guidance.

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

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

Despite annotations marking this non-destructive, the description adds real operational context: the draft is free until sent, preview link expires in 24h, defects can be re-drafted only while draft (printed = final), first pages return as images to inspect (subject, address window, line breaks), findings appear in warnings, and idempotency behavior is detailed. This far exceeds what the annotations 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?

Front-loaded with purpose and outputs, which is good, but the description is long and the German/EN duplication nearly doubles its length. The blocks example is useful but the overall size is bloated for an already-rich 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 15-param mutation tool with no output schema, the description covers outputs (page count, preview link, cost estimate, warnings), workflow, exclusivity of body inputs, and escalation rules. An agent has enough to call this correctly and handle the result.

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%, so the description must compensate for undocumented params. It fills the key gap: the content-vs-blocks mutual exclusivity with a worked blocks example and a pointer to the frankki://blocks-guide resource for styleDefs and limits. It doesn't cover senderAddressId, presetName, or reasoning, leaving some gaps.

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

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

The description names a specific verb and resource (creates a letter draft) and enumerates its concrete effects: produces a preview PDF in the stored design, stores the draft, and returns page count, a 24h preview link, and a cost estimate. It is clearly distinguished from siblings like letter_preview, order_send, and letter_schedule.

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?

Explicit guidance: use content XOR blocks, never both; next steps with letterId route to letter_preview, order_send, or letter_schedule; for deadline letters ask about Einschreiben and cite shipping_quote pricing; leave legal questions to a lawyer. Alternatives and conditions are named, not 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 flag destructiveHint=true and readOnly=false, so the safety profile is known; the description adds genuinely new context: it is an archive-style removal, new sends fall back to remaining letterheads, and already-sent letters retain their original for auditability. It does not mention permissions or error behavior, but the reversibility/audit semantics are a real addition 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?

The description is padded with an irrelevant enumeration of letter types (Kündigung, Rechnung, Mahnung, Angebot, Vertrag, Behördenpost) and duplicates the entire content in German and English. The core behavior — archive/delete with fallback to remaining letterheads — is buried rather than front-loaded.

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

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

With no output schema, the description must carry the full load, and it does explain the post-deletion state and auditability well. However, it omits prerequisites, whether/how the design can be restored, and any mention of the second parameter, leaving meaningful gaps for a destructive 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 coverage is only 50%: designId is well described (DE+EN) in the schema, but the second parameter, 'reasoning', has no description anywhere and the tool description never mentions it. For a destructive operation where a reasoning/audit field likely matters, the description fails to 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 — archives/deletes a saved letterhead (Briefdesign) — which is clearly distinguishable from siblings like letter_design_save and letter_design_list. The parenthetical 'archiviert (löscht)' introduces mild ambiguity about whether this is a hard or soft delete, but overall the operation is identifiable.

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 explicit when-to-use or when-not guidance, and no alternatives are named. The agent can infer that this removes a letterhead, but nothing directs it to letter_design_list/letter_design_preview first or explains prerequisites for deletion.

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 that full design JSON is returned and that designs can be archived, but it does not state pagination, response size, or how 'partner' scoping works, leaving a few behavioral gaps.

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 concise sentences (DE then EN mirror) are front-loaded with the core action and add the key context that a design is referenced by name or id when sending. The bilingual duplication adds length but not obscurity; still slightly more verbose than strictly necessary.

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 annotations covering safety, no output schema needed, and only two params (one documented in schema), the description provides enough context for an agent to call the tool: it describes the returned payload (full design JSON) and the business role of the resource. Missing only explicit guidance on the reasoning parameter and archived exclusion default, which is partially in schema.

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

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

Schema coverage is 50%; includeArchived is fully documented in the schema, but the 'reasoning' parameter is undocumented anywhere. The description does not compensate by explaining includeArchived semantics beyond what the schema says, nor does it explain what 'reasoning' should contain. Baseline 3 for partial 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 clear verb (lists), resource (letterheads/Briefdesigns), and scope (partner's saved designs with full JSON), and distinguishes it from siblings like letter_design_list_presets and letterhead_list by naming the concrete artifact a design is. The bilingual DE/EN phrasing is specific and 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 description explains what a design is used for (referenced by name or id when sending; carries every kind of mail), which implies the tool's context but does not explicitly say when to use this versus letter_design_list_presets, letterhead_list, or letter_design_preview. Usage is left to inference from the resource definitions.

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 a safe read-only, closed-world, non-destructive operation, yet the description adds meaningful behavior: the catalogue grows with each curated/passed-review design, and the cost profile changes sharply depending on whether presetId triggers PNG rendering. The cost tradeoff is genuinely useful context annotations cannot express, though rate limits or result-size bounds are unmentioned.

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?

Content is front-loaded and well ordered, but the German and English versions are full duplicates, doubling the length without adding information. Every sentence is useful once, but the payload is roughly twice the necessary size.

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 list tool with no output schema, the description adequately covers modes, cost and content, but leaves the preview mechanics vague: what 'pages' controls (limit 2), what resolution thumb vs full means, and whether reasoning is required for audit are all 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 25%, and the description covers only presetId (whose semantics are already in the schema description). The 'pages' cap (max 2), the 'resolution' thumb/full enum, and 'reasoning' are left undocumented in both places, so the low-coverage gap is only partially compensated.

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

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

States a specific verb and resource: returns owner-approved native-v2 letterheads as safe starting points, and enumerates the document classes they suit. This is clearly distinguishable from siblings like letter_design_list (user designs) and letterhead_list without opening either schema.

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

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

The description explicitly explains the two operating modes: omit presetId for a cheap text-only list, supply presetId to render exactly one composer preview with an inline PNG. It gives clear context for choosing between the modes but never names an alternative sibling tool or states when this list should be preferred over letter_design_list.

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

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

Annotations already declare readOnlyHint/destructiveHint/openWorldHint, but the description adds substantial context beyond them: the renderer reuses the production resolution and composer, real partner sender data is combined with a fictional recipient and sample body, output is an inline PNG, page 2 appears only for continuationHeader, no cost is incurred and no draft is mutated. This is exactly the kind of behavioral disclosure the annotations cannot carry.

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

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

The core behavior is front-loaded in the first two sentences, which is good. But the entire text is duplicated verbatim in German and English, roughly doubling length for no added information, and the enumeration of document types is padding rather than specification.

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

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

There is no output schema, so the description carries the return-value burden and does so reasonably: inline PNG, one page by default, a second only for continuationHeader, and what the empty variant shows. Gaps remain around the resolution/thoroughness parameter and the reference object, but the picture an agent needs to call and interpret this preview tool is largely present.

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

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

Schema description coverage is only 22% across 9 parameters, so the description must compensate and only partly does: it explains sampleVariant empty vs typical (and that sampleContent overrides both) and the pages behavior (page 2 for continuationHeader), plus the saved-vs-inline distinction between designId and design. It says nothing about resolution (thumb/full), reference, sampleSubject or reasoning, leaving several parameters undocumented in both places.

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

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

The first sentence names a specific verb and resource: it renders a saved or inline letter design (schemaVersion 1 or 2) through the same resolution/composer as a real send. The scope (design preview rather than letter send) is clear enough to separate it from letter_preview, though no sibling is named 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 via concrete scenarios ('So siehst du vorab, wie Kündigung, Rechnung, Mahnung ... aussehen') plus the reassurance that the run is free and the letter stays a draft, which encourages safe exploratory use. However, it never states when to use this instead of letter_preview or letter_get, and gives no exclusions.

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

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

Annotations already establish this is a non-destructive, closed-world mutation, and the description usefully adds that the design is fully validated and checked against postal clear zones before storage, plus what is returned. However, it is silent on key mutation behavior: whether saving overwrites an existing design with the same name, what errors the validation can raise, and any permission requirements.

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

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

The core action is front-loaded, but the text is fully duplicated in German and English and padded with uninformative sentences (the mail-type enumeration, the client-unload search hint). Roughly half the content does not help the agent decide or call the 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?

With no output schema, the description correctly explains the return values and the pre-storage validation, which is meaningful for a mutation. Against a very large nested design schema it is still incomplete: the input designId semantics, overwrite behavior, and failure modes are 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 description coverage is only 40% (name and brandingOwnershipConfirmed documented, designId and reasoning not), so the description is expected to compensate and does not. It never explains the designId input — which presumably drives update-versus-create semantics — nor the purpose of reasoning, and only mentions 'schemaVersion 1 or 2' in passing without linking it to the design payload.

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 ('Speichert ein wiederverwendbares Briefpapier (Briefdesign) ... im Partnerprofil'), the supported schema versions, and the return values (designId plus stored-source hash). An agent can distinguish it from letter_design_list/preview/delete from the name and description alone, though it never names a 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?

No guidance on when to use this versus letter_design_preview, letterhead_upload or template_save, and no prerequisites aside from the branding confirmation buried in the schema. The 'if the client unloaded the tool, search for letter_design_save' line is a discovery workaround, not usage guidance, and the mail-type sentence adds no selection criteria.

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 mark the operation as read-only and non-destructive. The description adds useful behavioral context by stating that the response includes the letter, its associated order, and a PDF download URL that is only valid for 24 hours. It does not cover error cases, but that is acceptable for a simple read-only retrieval.

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 short, front-loaded with the main verb and resource, and includes the important URL-expiry detail at the end. The main inefficiency is repeating the same content in German and English, but overall it is compact and readable.

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

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

The description covers the main return values and the time-limited URL, which is useful since there is no output schema. However, it does not explain the optional `reasoning` parameter or how the agent should obtain/use the IDs, leaving the invocation details partially dependent on inference.

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 0%, so the description needed to explain the parameters, but it never mentions orderId, letterId, or reasoning. The parameter names are somewhat self-explanatory, yet the purpose of `reasoning` and whether both IDs are required or how they relate remain unclear.

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 ('Returns/Liefert') and a specific resource: one of the partner's letters, together with its order and a 24-hour-valid PDF download URL. This makes the tool's core purpose clear and implicitly distinguishes it from list/search tools, though it never explicitly names a sibling.

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 implies the tool is for retrieving a single letter when its IDs are available, but it does not explicitly say when to use this tool instead of letter_list, letter_search, or letter_preview. It provides no when-not-to-use guidance or alternative routing.

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

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

Annotations already indicate readOnlyHint and non-destructive behavior. The description adds one useful behavioral detail—the preview URL is only valid for 24 hours—which is beyond the schema. However, it does not describe return shape, pagination, or other response behavior, so it provides only modest extra transparency.

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 short, front-loaded with the primary action, and includes the key detail about URL validity. The bilingual repetition is intentional and not filler for a German/English tool surface.

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 list tool with no required parameters and no output schema, the description gives enough to understand what is returned: letterheads with preview URLs. It could mention whether the list is complete or how the optional reasoning parameter is used, but those are minor gaps given the low 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 description coverage is 0%, and the description does not explain the only parameter, 'reasoning'. Since the parameter is optional and named in a self-explanatory way, the impact is limited, but the description still does not compensate for the lack of schema documentation.

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

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

The description uses a specific verb and resource: it states it lists the letterheads stored in the partner profile. It also mentions the distinguishing detail of a short-lived preview URL, which separates it from related letter/design list tools.

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 context is clear: use this tool to retrieve letterheads already saved in the partner profile, with preview URLs. It does not explicitly name alternatives or exclusions, but the scope is obvious enough from the description and the sibling-tool names.

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 are minimal (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description carries the burden. It discloses that PNG is printed while PDF is only filed with rendered=false, that fileUrl is preferred over base64 due to context/color concerns, and the 20MB limit. This adds meaningful behavioral context beyond annotations. It doesn't mention side effects like overwriting existing letterheads, but for this tool the key behaviors are covered.

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?

About 5 sentences covering the essential behavior, source selection, rendering limitations, and sibling routing. The bilingual structure is somewhat redundant, but each sentence adds information. The description is longer than ideal but not bloated; the front-loaded functional statement is first.

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 7-parameter upload with no output schema, the description explains the critical decisions: source priority, PNG vs PDF, exactly-one constraint, and when to use letter_design_save. The 'reasoning' parameter is undocumented and width/height semantics are thin, but the description covers the high-stakes aspects of the tool's behavior.

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 86% (6 of 7 parameters described). The description adds semantics beyond the schema by explaining the source selection logic ('genau eine von beiden'), the PNG/PDF rendering difference, and why fileUrl is preferred. However, widthMm/heightMm/displayName are only described as 'optional' in both schema and description without further guidance, and the 'reasoning' parameter is completely undocumented. Still, the core parameter semantics are substantially enriched.

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

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

The description states a specific verb ('Lädt ... hoch und speichert'), a resource ('Briefkopf'), and target ('Partnerprofil'), and distinguishes from letter_design_save and blocks. It clearly explains what this tool does and what it does not do. The sibling differentiation is explicit with 'dann letter_design_save' and 'der Brieftext bleibt den blocks vorbehalten.'

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 explicitly states the source preference (fileUrl bevorzugt), the mutual exclusivity ('genau eine von beiden'), and when to use letter_design_save for rebuilding letters. It gives clear context for what belongs here versus the blocks. This is explicit when-to-use guidance with alternatives named.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds the scope 'des Partners' and the filtering dimensions, but it does not disclose pagination behavior, ordering, or return format; with the annotations doing the heavy lifting on safety, 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?

The description is a compact bilingual sentence pair, front-loaded with the core action and containing no filler. The EN repetition is mildly redundant but serves clarity for multilingual agents, so it remains appropriately concise.

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 7 parameters, no output schema, and a closely related sibling (letter_search), the description is under-specified. It omits pagination/limit/offset semantics, return shape, and any guidance for choosing between letter_list and letter_search, leaving a substantial gap for correct invocation.

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 0%, so the description must compensate. It adds meaning by mapping filter concepts to parameters: recipient name (recipientNameContains), subject (subjectContains), status (statusFilter), and time (since). However, it does not explain limit, offset, or reasoning, which remain ambiguous despite the low schema 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?

The description clearly states a specific action ('Listet'/'Lists') and a specific resource ('Briefe des Partners'/'partner's letters'), and it names the main filter dimensions (recipient name, subject, status, time). It does not explicitly distinguish itself from the sibling tool letter_search, which likely overlaps in function, so it is clear but not fully differentiated.

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 explains what the tool does and mentions optional filters, but it gives no guidance on when to choose letter_list over letter_search or letter_get. No exclusion criteria or alternative routing is provided, leaving the agent to infer usage 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 convey read-only and non-destructive behavior. The description adds relevant context beyond those annotations: the links are time-limited, they expire, and renewal applies only to the interactive letter view. It does not describe the return format, but for a read-only helper this is a minor gap.

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

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

The description is compact and front-loaded: scope, action, then trigger condition. The English translation is a deliberate duplication that improves accessibility without adding unnecessary fluff.

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 one-parameter, read-only, non-destructive helper, the description covers the main facts: what it does, when to use it, and its scope. It does not specify the exact return shape of the renewed URLs, but the tool name and verb make the outcome reasonably clear.

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

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

The schema has one required parameter, letterId, with no description and 0% schema description coverage. The description never explicitly explains that letterId identifies the letter whose page link URLs should be renewed; this must be inferred from the tool name and the word 'Briefseiten'.

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 ('renews the time-limited image links'), a specific resource ('letter pages in the interactive letter view'), and an explicit scope boundary ('Nur fuer die interaktive Brief-Ansicht'). This distinguishes it from sibling page-URL tools for approvals and templates.

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

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

It provides an explicit trigger condition ('when the old ones have expired') and an explicit when-not constraint ('only for the interactive letter view'). An agent can confidently decide when to call this tool and when to look at other view-specific tools.

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

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

Annotations already declare readOnlyHint/destructiveHint=false, so the safety profile is covered; the description adds real behavioral context on top: the preview is free of charge, the stored letter is not modified, an unsaved design creates no account entry and applies only to this preview, and it enumerates what comes back (PNGs, PDF link, page count, cost, designRender with documentMode/chrome/bodyStartMm). 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?

The content is largely duplicated verbatim in German and English, roughly doubling length. The most critical instruction (forms need documentMode 'form') is buried mid-paragraph rather than front-loaded, and workflow advice about template_save/template_release is appended after the 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?

No output schema exists, and the description compensates by naming the return artifacts and the designRender fields. It also covers the rebuild/verify loop and the form special case, which are important given 13 parameters and nested objects. A few parameter behaviors remain undocumented, but the description is largely complete.

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

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

Schema description coverage is 77%, so the schema already documents most parameters (pages, resolution, reference, styleDefs, etc.). The description adds the mutual-exclusion rule (content OR blocks, never both), the letterId-vs-inline choice, and the form-mode design usage. It does not clarify several remaining parameters, so it is adequate rather than rich.

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: render a letter/draft (and form preview) as images, returning inline PNGs, PDF link, page count, cost and designRender. An agent can tell what it does. However, it never explicitly distinguishes itself from the close siblings letter_design_preview and template_preview, so sibling differentiation is missing.

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 usage context: supply letterId or inline content OR blocks, and for standalone forms always preview first with documentMode 'form'. It also names the follow-up tools (template_save, template_release) once the layout matches. No explicit when-not or comparison to the sibling preview tools, so it falls short of a 5.

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

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

Annotations only declare a non-destructive write, so the description carries most of the burden and delivers: checks and pricing run immediately, cost is reserved, a real OAuth connection creates an approval first, approval is what actually creates the schedule, and the send later flows through the same send pipeline. This is real behavioral context, though reversibility of the reservation is not addressed.

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 first sentence is well front-loaded, but the content is then duplicated wholesale in German and English, and several sentences address the UI/chat presentation flow ('kurze Bestätigung', 'PDF-Link und Brieftext gehören in reine Textansichten') rather than how to invoke the tool. Much of the text does not earn its place.

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

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

For a 22-parameter mutation tool with no output schema, the description gives a solid operational narrative (pricing, reservation, approval gating) but leaves the majority of parameters undocumented and never explains the returned cost/approval artifacts. Adequate at the workflow level, incomplete at the call-construction 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 description coverage is only 45%, so the description should compensate — but it only restates the mode enum values (fixed/relative/cron) that the schema already documents. Roughly a dozen parameters (color, express, auditTag, reasoning, presetName, templateId, signatureId, deliveryType, mandantennummer, senderAddressId, senderProfileId, includeSignature) are explained in neither the schema nor the description.

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

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

The opening sentence states a specific verb and resource ('Schedules an existing draft for a later time') plus the three timing modes, which clearly contrasts with an immediate-send tool. It stops short of naming any sibling (e.g. order_send, schedule_list_or_cancel), so differentiation must be inferred from the verb alone.

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

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

The description walks through the scheduling/approval workflow, which implies when this tool is appropriate, but it never states when NOT to use it or which alternative to reach for (immediate send vs. listing/cancelling). Usage is inferable rather than 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 and destructiveHint=false, so the safety profile is covered. The description adds useful scope information (which fields are searched) but does not disclose other behavioral traits such as result ordering, matching semantics, or response structure beyond the schema defaults.

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 one concise sentence in German plus its English translation, with no filler. The key search behavior and scope are front-loaded before any schema details.

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

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

For a read-only search tool with 5 parameters, the description plus schema covers the search scope, required/optional parameters, and pagination. Because there is no output schema, a small gap remains around what the returned matches look like, but this is unlikely to block correct invocation.

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 schema coverage at 60%, the description becomes important for the undocumented 'query' parameter, and it delivers by specifying that the query applies to subject, recipient name, and letter content. It does not explain the 'reasoning' parameter, but the other three parameters already have schema descriptions, so the overall semantic gap is small.

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

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

The description uses a specific verb ('Durchsucht' / 'searches') and resource ('Briefe des Partners' / 'partner's letters') and names the exact searchable fields: subject, recipient name, and letter content. This clearly differentiates the tool from sibling list/retrieval tools like letter_list and letter_get, which do not perform full-text content 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?

The description implies that this is the tool to use for full-text search over letter fields, but it does not explicitly state when to prefer it over alternatives such as letter_list or letter_get, nor does it give exclusions. No alternative tool is named, so the agent must infer the selection from the word 'Freitext'.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds transparency by enumerating exactly what the tool returns (addresses, category, monthly budget, retention period, letter count), which is valuable because there is no output schema.

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 a single clear sentence, but the English sentence fully duplicates the German sentence without adding information. This repetition costs tokens without benefit, though the field list is dense and relevant.

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 tool with no output schema and three undocumented parameters, the description covers the return fields but leaves critical invocation details unaddressed: how to identify the Mandant, whether mandantId or mandantennummer is preferred, and what the optional reasoning parameter is for. It also does not distinguish when to use this versus list/search siblings.

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 0%, and the description does not explain the meaning or usage of mandantId, mandantennummer, or reasoning. The parameter names are somewhat self-explanatory, but the description adds no input guidance, leaving ambiguity especially because no parameters are marked required.

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 the operation ('Liefert' / 'Returns') and the resource ('einen Mandanten'), and lists the specific data fields returned. It is distinguishable from sibling tools like mandant_list and mandant_search by its singular framing, though it does not explicitly contrast itself with them.

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 provides no guidance on when to use this tool rather than alternatives such as mandant_list or mandant_search. It also fails to state whether callers should supply mandantId or mandantennummer, or when this single-record getter is appropriate.

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 disclose readOnlyHint=true and destructiveHint=false, so the description does not need to repeat that this is a safe read. It adds the partner-scoped dataset and optional filtering behavior, but it does not mention pagination, ordering, or edge-case 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 bilingual sentence with no filler. The verb and resource are front-loaded, and the English equivalent is compact and useful rather than redundant.

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

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

For a simple read-only list operation, the description conveys the core purpose and main filter options. However, with seven parameters and no output schema, it omits the since filter, pagination behavior, the reasoning parameter's purpose, and any description of the return shape.

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 43%, with limit, since, and offset documented in the schema. The description adds meaning for otherwise undocumented filter parameters by mapping 'Suchbegriff' to searchQuery, 'Kategorie' to kategorieFilter, and 'Tag' to tagFilter. However, the reasoning parameter remains completely unexplained.

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 clear verb ('Listet') and resource ('Mandanten des Partners'), plus optional filters by search term, category, or tag. It does not explicitly differentiate from the sibling mandant_search, so the agent must infer the list-versus-search boundary.

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?

Provides no guidance on when to use this tool instead of alternatives such as mandant_search or mandant_get. The description restates the operation and optional filters, but it never says when this is the right choice or when it is not.

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 useful behavioral detail beyond those annotations: each result identifies which column matched the query, helping the agent interpret hits. It does not cover pagination behavior, but limit and offset are documented in the schema.

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 content is well ordered, with the main search behavior first and follow-up actions after. However, the full German text is duplicated in English, which doubles the length without adding new information. It is still readable and front-loaded, but not as tight as it could be.

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 clarify the return shape; it partially does by saying the matching column is named per hit and that a mandantennummer is available for next steps. It lacks explicit guidance on exact result fields, pagination behavior beyond schema basics, and how this tool relates to sibling search/list tools such as mandant_list or address_search_company.

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

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

Schema description coverage is 60%, and the key parameter 'query' has no schema-level description. The description compensates by explaining that query can match Mandantennummer, Name, Tags, or Sachbearbeiter. The remaining parameters (limit, offset, since) are already described in the schema, though 'reasoning' remains unexplained.

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

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

The description states a specific verb ('Sucht') and resource ('Mandanten') and enumerates the search criteria: client number, name, tags, or case handler. It also notes that each hit names the matching column, which makes the tool's behavior concrete and distinct from generic list or get tools like mandant_list and mandant_get.

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 implies when to use this tool—when you need to locate a Mandant by partial search criteria—and provides clear next-step routing by naming document_create, mandant_get, and letter_create_draft as follow-ups. It does not explicitly state exclusions or compare itself with alternatives like address_search_company, 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.

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

Beyond the readOnly/openWorld/destructive annotations, the description discloses what the tool actually inspects (partner token, end-to-end chain), the setup categories it reports (sender profile, AVV, balance, sandbox, approval, letterhead), and that checkRender additionally probes composer + rasterizer. That is substantive behavioral context, not annotation restatement.

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 German/English duplication roughly doubles the length without adding distinct information for the agent, and the humanSummary guidance is repeated twice. The core facts are front-loaded, but the bilingual mirror does not earn its place as concision.

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

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

With no output schema, the description usefully characterizes the return shape: per-step humanSummary (de, en), nextTool, fixUrl, messageDe/messageEn, and a setup section listing unmet prerequisites. That is unusually complete for a health-check tool, though the exact shape of a failing probe response (e.g. bad token) is not sketched.

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 50%; checkRender is already documented in the schema and the description largely repeats it ('additionally checks whether rendering works'), while it adds the practical trigger for setting it true. The other parameter (reasoning) is undocumented in both schema and description, so the description does not fully 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?

It states a specific verb+resource: verifies the partner token and the whole processing chain, and reports which send prerequisites are met. It is clearly distinguishable from siblings like wallet_balance or sender_profile_validate, though it never names a sibling explicitly. The 'call it before building a template' framing helps an agent place it, but there is no direct routing statement against setup_status_app.

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?

Explicit invocation timing is given: 'Call it before building a template you will need to look at,' plus the checkRender:true trigger condition for probing the render path. It gives clear when-to-use context but no when-not / alternative-tool guidance (e.g. versus setup_status_app or setup_fix_link).

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

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

With destructiveHint=true and readOnlyHint=false already declared, the description still adds substantial value: it discloses the side effect (refund to wallet rather than card), the closed-loop nature, the rejection behavior when printing, and the 10-minute grace window. These are behavioral traits beyond what annotations 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?

Front-loads the core effect (cancellation plus wallet credit) before drilling into the two modes, which is good structure. The bilingual duplication inflates length, but the German/English mirroring is functionally justified and each 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 destructive mutation tool with no output schema, the description covers the essential behavioral consequences, the two invocation modes, and the failure case, so an agent has enough to invoke it correctly. Minor gaps remain: no auth/permission note and no mention of the undocumented 'reasoning' field.

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%, just under the high-coverage baseline, and the description supplements it by clarifying that orderId and approvalId are alternative triggers with different semantics and windows. It does not mention the 'reasoning' parameter nor add format detail beyond the schema, keeping it short of 5.

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 (cancels a letter/order) and immediately discloses the financial outcome (amount credited to the wallet, closed loop). It also cleanly separates the two operational modes (orderId vs approvalId), so an agent can tell this apart from siblings like order_status or order_send 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 conditions for each path: orderId cancels an existing order within the cancellation window, approvalId stops a chat-approved send inside its 10-minute grace window. It also states a when-not case (already printing is cleanly rejected). It lacks explicit routing to alternative sibling tools, so it stops short of a full 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 carry readOnlyHint/closed-world/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: the returned evidence set, the 90-day validity window of the URL, the GoBD archive provenance, and the condition under which no receipt exists yet. It does not describe failure behavior when the letter has not yet been handed in.

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

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

Front-loaded with the outcome and the returned fields, and the bilingual duplication is justified given the German tool name and title. It is somewhat verbose with the German and English saying the same thing, but no sentence is purely 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 no output schema, the description usefully enumerates what is returned (PDF download URL, postmark, provider, GoBD record) and the 90-day validity. It is close to complete for a read-only retrieval tool; the only meaningful gap is the unexplained reasoning parameter.

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 0% for two parameters, so the description must compensate. "zu einem versendeten Auftrag" only weakly implies that orderId identifies a shipped order, and the second parameter (reasoning) is never mentioned at all. The undocumented parameters are left entirely to guesswork.

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 (retrieve) and a specific resource (Einlieferungsbeleg / proof of posting), and explicitly distinguishes it from the sibling order_status by naming which sibling covers tracking number and delivery status. An agent can tell it apart from order_status without opening either schema.

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

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

Gives an explicit precondition ("sobald der Brief eingeliefert ist und der Versanddienstleister einen Beleg ausstellt") and routes the adjacent need elsewhere ("Sendungsnummer und Zustellstatus ... liefert order_status"). This is explicit when-it-applies plus a named alternative.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the mutation profile is covered. The description adds high-value context beyond that: the required OAuth scope, the human-in-the-loop fallback, and the invariant that price stays unchanged. It could go further on failure behavior, but it meaningfully enriches the annotation picture.

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 action and its precondition are front-loaded and each German sentence mirrors its English counterpart, so there is no filler within a language. The full bilingual duplication doubles the length, which is defensible for i18n but not maximally concise.

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

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

For a destructive mutation with no output schema, the description covers the essential operational facts: precondition, fallback flow (including the returned link), and the price invariant. Minor gaps remain on per-parameter meaning and error outcomes, but the agent has enough to invoke it 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 description coverage is only 25%, so the description should compensate for undocumented parameters, yet it never explains orderId, reasoning, or clientOrderId. Only 'recipient' carries a schema description (inline fields vs { addressId }), which the description merely echoes. The gap remains unaddressed.

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 ('Korrigiert die Empfängeradresse eines Briefs') scoped to a precise state ('im Status awaiting_partner_fix') and the follow-on action ('reicht ihn erneut ein'). This cleanly distinguishes it from siblings like order_send (new send) and address_upsert.

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

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

Gives an explicit precondition for use ('nur erlaubt, wenn die OAuth-Verbindung approval:self_approve trägt') and an explicit fallback path for when it is not ('muss der Mensch den zurückgegebenen Link öffnen und im angemeldeten Portal entscheiden'). The agent knows both when to call it and what to do instead.

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

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

Annotations already declare destructiveHint=true and openWorld=false, but the description adds much more: real OAuth sends enter the approval queue, wallets reserve funds at submit (INSUFFICIENT_FUNDS if uncovered), PRICE_CHANGED abort behavior, the six-gate pipeline, and the critical caveat that a dryRun's returned letterId is a rehearsal handle that yields NOT_FOUND in letter_get/letter_preview.

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

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

The core purpose is front-loaded, but the text is very long and the entire German block is duplicated verbatim in English, including the full blocks JSON example. Much of the routing guidance earns its place, but the doubling and repetition push it well past what is needed even for a 40-param 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 destructive, 40-parameter tool with no output schema, the description covers approval/queue flow, cost reservation, error codes, idempotency, and which sibling to call at each stage. It stops short of explaining what a successful response returns beyond pointing to order_status, 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?

With 40 parameters and only 53% schema description coverage, the description must compensate, and it does add real meaning for the content/blocks exclusivity, letterId, and dryRun semantics, plus it points to frankki://blocks-guide. However many parameters (express, subject, scheduledAt, reasoning, senderAddressId, presetName, etc.) are left undocumented in both places.

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 ('Versendet einen Brief physisch per Post') plus the internal pipeline it runs (Pflichtangaben, Empfängeradresse, AVV, Limits, finale PDF, Preisberechnung). It is clearly distinguishable from order_send_batch, letter_create_draft, and letter_preview, which it names directly.

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

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

Explicitly routes between alternatives: use letterId or inline content/blocks, preview via letter_create_draft/letter_preview first, poll with order_status, cancel with order_cancel, fix with order_fix_resubmit, price a planned letter with shipping_quote, and use dryRun for a free rehearsal. It also states when self-approval is required and when to ask the human about Einschreiben.

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 destructiveHint=true and readOnlyHint=false, and the description richly confirms and extends this: the batch becomes one queued approval, rejection refunds the entire reservation, and autocompletion requires the explicit approval:self_approve grant. This discloses consequences (charges, refunds, approval gating) well beyond what the annotations 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?

Front-loads the core action before the approval guidance, and each sentence carries operational meaning. However, the German and English text are verbatim duplicates, which roughly doubles length without adding 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 batch mutation with no output schema, the description supplies the key return artifact (approvalUrl), the approval lifecycle, refund behavior, and the authorization requirement. Minor gaps remain around per-item failure reporting and the exact shape of counted/costed results, but the essentials are covered.

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 parameters like clientOrderId, dryRun, stopOnError, designId and priceVersion are already fully documented in the schema. The description adds no per-parameter syntax or format detail beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource with scope: submitting multiple letters as one batch, each item checked and priced separately. The batch framing clearly differentiates it from the sibling order_send (single-letter) without needing to name 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?

Gives concrete operational context: always hand the human the approvalUrl, only an OAuth connection with approval:self_approve may self-approve, and dryRun is a free rehearsal. It does not explicitly route between this tool and order_send or approval_submit, so a sibling-selection rule is left to inference.

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 annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds valuable behavioral context: tracking numbers appear only for registered mail, tracking history is chronological German tracking, and the response includes delivery estimate and cancellation availability. It also explains the awaiting_partner_fix state. 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?

The German description is well-structured and front-loaded with core behavior before conditional routing. However, the entire text is repeated verbatim in English, doubling the length without adding new information and reducing conciseness.

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 compensates well by enumerating the returned fields and status-dependent next steps. The main gap is the unexplained reasoning parameter; otherwise an agent has sufficient context to invoke the tool and interpret the result.

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

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

The schema has 0% description coverage and the description does not explain the orderId or reasoning parameters. While orderId is inferable from its name and UUID format, the optional reasoning field is entirely opaque, leaving the agent unsure what to pass or why.

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

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

The description uses a concrete verb ('Liefert'/'Returns') and names the exact resource: the current status of an order. It also enumerates the specific payload fields (German chronological tracking history, tracking number for registered mail, estimated delivery, cancellation availability), which clearly distinguishes it from mutation siblings like order_send or order_cancel.

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 provides explicit conditional routing: on status awaiting_partner_fix, call order_fix_resubmit; while cancellable is true, order_cancel can still stop the send. This gives an agent clear when-to-use and when-to-hand-off guidance beyond simply invoking the tool.

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

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

Annotations only signal non-readonly, non-destructive mutation, so the description carries the behavioral burden and delivers meaningfully. It discloses that the name is unique per partner (implying duplicate-name semantics), that limits are stored unmodified as a note, and critically, that the saved limits are not enforced — saving the agent from a wrong mental model. It does not specify whether a duplicate name overwrites or errors, which would have made this 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?

The description is efficiently structured: the core verb-object is front-loaded in the first sentence, followed by two short sentences that add uniqueness and non-enforcement semantics. Being bilingual (German/English) doubles length, but both versions are complete and every sentence earns its place. No filler or repetition of schema data.

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 a complex nested-object parameter and no output schema, the description covers purpose, uniqueness, and the non-enforcement nuance well. However, it omits what happens on duplicate name (overwrite vs. error), any return-value expectations, and any mention of the reasoning parameter. These are notable gaps for an agent deciding how to invoke and interpret the call.

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

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

Schema coverage is 67%, with name and preset documented but reasoning having no description at all. The description adds genuine semantic value for the preset parameter — clarifying that limits within it are stored as-is and serve only as a note — which is beyond the schema text. However, it does not cover the undocumented reasoning parameter, so it only partially compensates 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?

The description states a specific verb and resource: 'Saves a named preset (configuration bundle) in the partner profile.' It goes beyond a bare statement by defining what the bundle contains and clarifying a key semantic boundary — that limits inside the preset are stored as notes and not enforced, which differentiates it from limit-setting or enforcement tools among the siblings. It does not explicitly name a sibling tool, but the functional scoping is strong enough to avoid confusion with template_save, letter_design_save, or brand_kit_save.

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 conveys implied usage context: it tells the agent this tool persists a configuration bundle and that enforcement happens 'exclusively on the account and sub-wallet limits set in the web app.' This indirectly warns the agent not to expect limit enforcement from this tool, but it never states explicit when-to-use or when-not-to-use conditions, nor does it name an alternative tool. The guidance is inferable rather than direct.

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, so the safety profile is covered. The description adds important behavioral context beyond annotations: the prices are examples for a one-page black-and-white standard letter within Germany, and the real price depends on additional factors. This sets correct expectations about the nature of the returned 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?

The description is well-structured: it states the purpose, gives trigger keywords, then provides the caveat and the alternative tool. The only redundancy is the full bilingual repetition (German and English versions of the same content), which is acceptable for accessibility but slightly reduces conciseness. Every sentence earns its place in terms of content.

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

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

For a simple read-only pricing tool with no business parameters, the description is complete. It explains what data is returned (tier thresholds and example prices), the exact assumptions (one-page B&W standard domestic letter), and routes to the relevant sibling tool for real quotes. The absence of an output schema is mitigated by a clear textual description of the return concept.

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

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

The schema has only one optional 'reasoning' parameter with no description, but it is a generic meta-parameter rather than a business input. The description effectively covers the tool's domain semantics by explaining what data is returned, so no additional parameter guidance is necessary. The lack of a business parameter list is compensated by the description's clarity about scope.

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

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

The description uses a specific verb ('Returns FrankKi's volume tiers') and resource, clearly stating what the tool provides: bulk discount tiers with the monthly quantity thresholds and example per-letter prices. It also distinguishes itself from shipping_quote by explicitly stating the tool gives example prices only, not real quotes.

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 explicitly tells the agent when to use the tool: 'Use this when someone asks about bulk discounts, volume pricing or enterprise pricing.' It also indicates when not to use it by directing real price calculations to shipping_quote, making the decision boundary unambiguous.

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 the scope of returned data, but does not disclose any behavioral traits such as aggregation behavior, latency, or auth requirements. It adds some value beyond annotations without contradicting them.

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 a single front-loaded sentence that conveys the tool's scope and contents efficiently. The bilingual repetition adds length but serves multilingual users; it remains appropriately sized and well structured.

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 explaining return values, and it lists the major categories (address, signature, letterhead, presets, wallet, pricing). It does not detail the reasoning parameter, but since the tool is callable with zero parameters and returns a summary, the coverage is sufficient for an agent to use it 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?

There is one optional parameter, 'reasoning', with zero schema description coverage (0%). The description does not explain the parameter's purpose or format. Since the schema gives no help and the description does not compensate, parameter semantics are weakly documented.

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

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

The description opens with a specific verb and resource ('Liefert das Partnerprofil im Überblick') and enumerates the exact contents (sender address, signature, letterhead, presets, wallet summary, pricing model). This clearly distinguishes it from sibling tools like sender_profile_get or wallet_balance, which return narrower data.

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 implies the tool is for getting a consolidated profile overview, but it does not explicitly state when to prefer it over individual sibling tools or when not to use it. It provides context (overview vs detail) without naming alternatives or exclusions.

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

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

Annotations already state destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds one useful behavioral detail: cancellation releases the reserved amount. However, it does not discuss irreversibility, permissions, or what happens when no matching scheduled send exists, so the addition is modest.

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 short bilingual sentences with no wasted words. It front-loads the main action and the cancellation side effect, and it avoids repeating schema-level parameter details.

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

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

For a dual-mode tool with no required top-level parameters and no output schema, the description is minimal: it does not state that action is practically required, describe list versus cancel responses, or clarify that cancel is the destructive branch. The schema compensates for some of this, so the description is adequate but has 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?

The input schema already describes action, dryRun, scheduleId, and statusFilter with 80% coverage. The tool description adds little parameter-level meaning beyond connecting cancellation to the release of the reserved amount. With high schema coverage, a baseline of 3 is appropriate.

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

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

The description uses specific verbs ('listet auf', 'bricht ab') and a clear resource ('geplanten Sendungen des Partners'), and adds a meaningful side effect ('reservierte Summe wird freigegeben'). It clearly distinguishes the list and cancel behaviors, so an agent can tell what this tool does without relying on the name alone.

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

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

The description provides no guidance on when to choose this tool over sibling tools such as letter_schedule or order_cancel, and it does not mention exclusions, prerequisites, or alternative tools. The intended use is only implied by the name and action enum.

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 well covered. The description adds useful return-content expectations but does not mention error cases, authorization requirements, or other behavioral aspects. There is 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?

The description is two short sentences, front-loaded in German with a direct English equivalent. There is no filler or unnecessary repetition beyond the bilingual translation, which is appropriate. It is concise and easily scannable.

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 getter with read-only annotations and a required ID, the description is adequate at a high level but incomplete: it omits parameter semantics, especially for reasoning, and gives no guidance on when to use this tool over sender_profile_list or sender_profile_validate. It also lacks output structure, though the listed fields partially compensate for the missing output schema.

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 0%, so the description needed to explain both parameters, but it mentions neither profileId nor reasoning. profileId can be inferred as the target profile identifier, but reasoning is left entirely undefined. The description therefore adds no parameter meaning beyond the schema.

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

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

The description clearly uses an action verb ('Liefert/Returns'), names the resource ('ein Absenderprofil/sender profile'), and specifies scope ('ein einzelnes/single'), which distinguishes it from sender_profile_list. It also lists the key returned content: mandatory details, bank account, and disclaimer.

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 explicit when-to-use or when-not-to-use guidance is provided. The word 'single' and the required profileId parameter imply this tool is for retrieving one profile by ID, but the description does not direct agents away from sender_profile_list or sender_profile_upsert. Usage context is only inferred.

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, covering the safety profile. The description adds useful behavioral context about what the result includes (legal form, mandatory-details completeness) and the scope ('all profiles'). However, it does not mention ordering, pagination, empty results, or any partner-identification prerequisite.

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 short and front-loaded with the verb and object. The bilingual duplication adds a little length but is compact and useful for language coverage. Every key point fits in two concise statements.

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

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

This is a simple read-only listing tool, and the annotations cover side-effect safety. However, the undocumented 'reasoning' parameter and the lack of any guidance about sibling tools leave gaps that an agent must resolve by trial or external knowledge.

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 0%, and the only parameter, 'reasoning', is left entirely unexplained in both the schema and the description. The description does not compensate for this gap, so an agent cannot know what value to pass or whether the parameter affects the listing behavior.

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

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

The description states a specific verb ('listet/lists') and a clear resource ('alle Absenderprofile des Partners / all of the partner's sender profiles'). It further distinguishes the tool by specifying the returned attributes: legal form and completeness of mandatory details. This separates it cleanly from siblings like sender_profile_get or sender_profile_upsert.

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 the scope ('all profiles of the partner') but provides no guidance on when to choose this tool instead of sender_profile_get, sender_profile_validate, or other list tools. No alternatives or exclusion conditions are mentioned, so the agent must infer usage purely from the name.

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