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

Beyond the annotations, the description discloses the real-world side effect that approved invoices are paid automatically on the due date — critical context given destructiveHint=false and idempotentHint=false. It does not say whether an approval can be revoked, what happens on an already-approved invoice, or which permissions/connection state are required.

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

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

Three short sentences, each earning its place: purpose, consequence, and mode distinction, in that order. Nothing is padded or repeated.

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 an output schema handling return values and annotations covering the safety profile, the description supplies the essential missing piece — that approval moves money — plus the preview/commit split. Missing only secondary details such as prerequisites and reversibility, which keep it short of full completeness.

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

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

Schema coverage is 67% and the schema already spells out confirm's two modes and company's optionality, so the description's "preview" remark largely restates it. The undocumented invoice_id is self-evident from the required-parameter list; the description adds little beyond the schema 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 and resource ("Approve ... a supplier invoice") and anchors it to a concrete UI action ("as the Godkänn button does"), which removes ambiguity about the effect. It also adds the downstream consequence (payment by Wint on the due date). No sibling is named, but no sibling offers an approve action, so differentiation is implicit rather than 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?

"Without confirm it only returns a preview" establishes the two-step workflow and tells the agent which mode is the default. It does not state prerequisites (connection via connect_wint, invoice state) or when a different tool should be chosen instead, so the guidance is clear but not exhaustive.

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

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

Adds genuine value beyond the annotations by disclosing the preview/submit split and warning that submission changes the company's bookkeeping and cannot be undone from this tool. The 'destructiveHint: false' annotation is consistent since the action is additive; the 'from here' qualifier reasonably reconciles reversibility. It stops short of mentioning auth/connection requirements despite openWorldHint=true.

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

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

Two tight sentences, zero filler, with the mode-switching behavior front-loaded right after the purpose statement. Every clause carries information the agent needs.

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

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

For a 12-parameter mutation tool with an output schema and near-complete parameter documentation, the description covers the essential safety story. The remaining gap is guidance on mutually exclusive input methods for supplying the file and any connection/auth preconditions.

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

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

Schema description coverage is 92%, so the parameters are already well documented, including confirm's preview-vs-submit semantics. The description reinforces confirm but adds nothing new for the 11 other parameters, notably the three alternative document sources (file_url, file_base64, upload_ids), which is exactly where prose help would matter.

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 ('attach a receipt, invoice or other document') and narrows scope to payments that Wint flagged as missing a document, which naturally pairs with list_missing_documents. It does not explicitly name the nearest siblings (upload_document, upload_other_document, upload_supplier_invoice) to say how it differs from 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 clearly splits the two operational modes: no confirm = preview, confirm=true = actual submission to Wint. It gives a clear condition for the write path but never states when to prefer this tool over sibling upload tools, nor what prerequisites (Wint connection, BankID) must be in place.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior. The description adds that the tool surfaces login status and a QR code, but it does not disclose polling behavior, rate limits, QR expiry, or session lifecycle details that would matter for an open-world login flow.

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 short sentence with no wasted words. It is appropriately sized, though the fragment style ('Login panel only:') is a bit terse and does not front-load the action as clearly as a complete sentence would.

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

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

With an output schema and rich annotations, the description does not need to explain return values or safety profile. However, for a polling tool that has a sibling 'bankid_login_start', the description is incomplete about when and how to use this tool in the overall login flow.

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

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

The tool has zero parameters, so there is nothing for parameter semantics to document. The baseline score of 4 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 clearly states the tool provides current login status and a QR code, which combined with the name 'poll' gives a specific resource and implied action. However, it does not distinguish this from the sibling 'bankid_login_start' or explicitly say it polls an ongoing login session.

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 'Login panel only' gives a UI scope but does not explain when to call this tool versus 'bankid_login_start', how often to poll, or what conditions indicate completion. No when-to-use or when-not-to-use guidance is provided.

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=false, destructiveHint=false, and openWorldHint=true, so the agent knows this initiates an external, non-destructive flow. The description adds the mode semantics but omits the operationally important trait: that this only opens a session and must be followed by polling, plus any expiry/timeout 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 sentence with the scope constraint front-loaded and the two enum meanings packed in with zero filler. Nothing could be removed without losing 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?

An output schema exists, so return values need no explanation, and the sole parameter is fully covered. The remaining gap is the interaction lifecycle — that this pairs with bankid_login_poll — which an agent must infer from sibling names.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning, and it does: 'qr' is explained as scanning from another device and 'app' as this device, which is meaning the bare enum cannot convey. It does not restate the default of 'qr', but that is minor.

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 ('start a BankID login') and scopes it with 'Login panel only', which together with the sibling name bankid_login_poll makes the start-vs-poll split readable. It stops short of naming the sibling explicitly, so it's clear but not maximally 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?

'Login panel only' implies the context where this applies, and the start/poll naming suggests a follow-up, but the description never says 'call bankid_login_poll afterwards' or when not to use this tool. Usage is left to inference from the name pair.

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 this as read-only, non-destructive, and closed-world. The description adds useful behavioral context by clarifying that the panel handles login and that invoking this tool does not itself initiate BankID authentication.

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 tight sentences with the primary purpose front-loaded. Every sentence adds relevant information without repetition.

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

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

For a zero-parameter, read-only UI action with an output schema and annotations, the description covers what the panel is and the key caveat about not starting BankID. It could optionally mention sequencing with bankid_login_start or bankid_login_poll, but nothing essential is missing.

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

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

The tool has zero parameters, so parameter semantics are not a major concern and the baseline is 4. The description correctly does not add unnecessary parameter detail.

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

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

The description states a specific action and resource: showing the BankID login panel, including its live QR code or device button. It also distinguishes the tool from starting authentication itself, which differentiates it from the bankid_login_start 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?

It gives clear context for using the tool: display the panel so the login happens there. It also states an important exclusion, that this call does not start BankID by itself, though it does not explicitly name bankid_login_start or bankid_login_poll as alternatives.

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, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond them: without confirm it only returns a preview, i.e. it is a dry-run switch. It stops short of saying what a confirmed call actually produces or whether re-running creates duplicates, despite idempotentHint=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?

Three short sentences, front-loaded with the purpose, followed by the exclusion and the preview caveat — no filler. The parenthetical about Wint paying you back is slightly chatty but does real explanatory work, and the embedded quote of a Swedish UI label is a little noisy.

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 15-parameter, open-world mutation with only 3 required fields and 40% schema coverage; the description covers the purpose, one alternative, and one flag, but leaves the attachment mechanism, field requirements, and post-confirm effects unexplained. An output schema exists, so return values need not be described, but the invocation surface is under-specified for a tool of this size.

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% schema description coverage across 15 parameters, the description needs to compensate, but it only touches confirm (the preview behavior). It says nothing about the three required fields (amount, purchase_date, category), the mutually-overlapping attachment options (file_url / file_base64 / upload_ids / file_name), currency default, supplier_name, or how payment_method relates to get_receipt_options.

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 (create/send in) and resource (receipt), and anchors it to the Wint UI action "Lägg till dokument → Kvitto," which pins down exactly what record type results. It separates itself from update_receipt but not from the other upload_* siblings (upload_document, upload_other_document), so an agent still has to infer the family boundaries.

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 triggering condition (something paid with your own money, reimbursed by Wint) and an explicit exclusion with the alternative named: Wint card purchases already have a draft, so use update_receipt instead. This is exactly the when/when-not/alternative pattern an agent needs to route correctly.

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

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

Annotations only declare readOnlyHint=false, openWorldHint=false, destructiveHint=false; the description adds genuinely new behavioral context by disclosing the side effect that subsequent Wint calls require a fresh BankID login. It does not clarify that only session state (not data) is destroyed, which would be useful given the word 'Delete' alongside destructiveHint=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?

Two short sentences, zero filler, with the action front-loaded and the consequence immediately after. Nothing could be cut without losing 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 no-argument session-teardown tool with annotations and an output schema, the description covers what is deleted and the follow-on effect. An agent has everything needed to call 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The absence of arguments is consistent with the empty schema.

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

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

States a specific verb ('Delete') and a specific resource ('the stored Wint session'), so the agent knows exactly what is removed. It is distinguishable from connect_wint by being its inverse, though it never names the 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?

The consequence sentence ('The next Wint call needs a new BankID login') implies when this is appropriate — logging out or forcing re-authentication — but there is no explicit 'use this when...' or 'do not use when...' guidance, and no alternative tool is 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, idempotentHint and non-destructive, so safety is covered. The description adds real behavioral context by specifying that only *active* accounts are returned (implying inactive accounts are filtered out), which the annotations do not convey. It says nothing about ordering, pagination or company-scoping 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 short fragment with zero filler, and the key qualifier ('active') and domain synonym ('kontoplan') are front-loaded. It is arguably too terse rather than padded.

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

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

For a simple read-only lookup with two optional, fully documented parameters, an output schema and complete safety annotations, this is nearly sufficient. The only missing piece an agent might want is how this list relates to other finance-reporting tools.

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

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

Schema description coverage is 100%: 'query' (filter on account name) and 'company' (id or name, omittable with one company) are fully documented in the schema. The description adds no parameter meaning 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?

Names the specific resource ('Chart of accounts (kontoplan)') and its contents ('active account numbers and names'), so an agent knows exactly what comes back. It does not differentiate from nearby siblings such as get_financial_report or get_transactions, which is the only clarity gap.

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

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

There is no guidance on when to call this versus alternatives, nor any stated prerequisites. The agent must infer usage purely from the resource name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered without description help. The description adds one genuinely non-obvious fact — that the data originates from a Wint import — but says nothing about freshness, why openWorld applies, or what the 'bookkeeping done until' date signifies (period close? lock date?).

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

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

A single short sentence with no filler, and the primary subject (balances) is front-loaded. The trailing clause 'and the date bookkeeping is done until' is grammatically broken and slightly muddies rather than sharpens the focus.

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?

An output schema exists, so return values needn't be spelled out, and annotations carry the safety profile. Still, for a tool whose description is the only prose, the ambiguous fragment about a bookkeeping date leaves an agent unsure whether this returns a balance list, a single date, or both.

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

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

Schema description coverage is 100% and the single 'company' parameter is documented as optional when only one company exists, so the schema does the work. The description adds no meaning about scoping by company or what happens when several companies exist, so the baseline 3 applies.

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

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

The description names a specific resource (bank account balances imported by Wint) plus an auxiliary datum (the bookkeeping cutoff date), so the agent can tell it is a read of bank balance data rather than transactions or invoices. However it is a noun phrase with no verb and no differentiation from close siblings like get_accounts or get_financial_report, which an agent must guess between.

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

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

There is no statement of when to use this tool versus get_accounts, get_financial_report, or get_transactions, and no prerequisites (e.g. that Wint must be connected via connect_wint). Usage must be inferred entirely from the name.

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

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

Annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds important domain behavior beyond annotations: the Swedish sign convention that income/liabilities are negative credit and costs/assets positive debit, which is critical for interpreting results correctly.

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

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

Two tightly written sentences with no wasted words. The report types are front-loaded, and the sign-convention note follows immediately as essential context.

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?

Because an output schema exists, the description need not explain return values, and annotations cover safety. It completes the key domain context with report definitions and sign conventions, but it leaves implicit how this tool relates to sibling financial-data tools.

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

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

Schema coverage is 75%, so the schema already documents most parameters, including company optionality and end_month inclusivity. The description adds meaning to the report enum by mapping result/balance to resultatrapport/profit and loss and balansrapport, and clarifies that the period is whole months, though it does not mention the optional company parameter.

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

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

The description names the specific resource and both report variants: resultatrapport/profit and loss and balansrapport, with account rows over whole months. It is more specific than the tool title, but it does not explicitly distinguish this tool from siblings such as get_transactions or get_accounts.

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 defines what the report contains but gives no explicit guidance on when to use it versus alternatives, nor any when-not-to-use conditions. 'Over whole months' implies month-level reporting, but that is not framed as usage guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety and repeatability are covered. The description adds that the response includes full details plus attachment names, which is useful payload context, but says nothing about permissions, company scoping, or error 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?

It is a single short sentence with zero padding, but it is under-specified rather than concise — the brevity comes at the cost of a verb, scope, and any routing signal.

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?

An output schema exists, so return values needn't be spelled out. Still, for a tool with two parameters where one is undocumented in the schema, the description should at minimum confirm it fetches a single receipt by id and note the company scoping; neither is present.

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

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

Schema coverage is only 50%: `company` carries a description ("may be omitted with one company") while `receipt_id` is a bare integer. The description mentions neither parameter and gives no hint that the receipt is identified by an integer id or how company scoping interacts with it, so it does not compensate for the 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 sentence names the resource (a single receipt) and hints at payload contents ("all its details and attachment names"), but there is no verb and no explicit contrast with the sibling get_receipts (plural). An agent can infer retrieval-by-id from the name, but the description itself does not do that work.

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 when-to-use, when-not, or alternative is stated. The closest sibling, get_receipts, is never mentioned, so the agent must guess whether to fetch one or list many. Only the singular/plural naming difference implies 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?

The annotations provide a strong safety profile (readOnlyHint=true, destructiveHint=false), making the description's general claim of 'getting options' consistent with behavior. The description does not add new behavioral constraints beyond this implied read-only nature.

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, dense sentence that completely defines the tool's utility and its specific domain without using filler.

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

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

It thoroughly explains the business value and the scope of the options returned, which is essential given the large number of similar-named receipt tools in the sibling list.

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 100% schema description coverage and a clear schema, the baseline for parameter semantics is met. The description does not add logic that is missing from the structured data.

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 lists three specific sets of data retrieved (categories, payment methods, approval rights). Crucially, it ties these categories to specific sibling tools (update_receipt / create_receipt), allowing the agent to distinguish this tool's purpose and scope 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 implies usage by explicitly linking its output to the requirements of the update_receipt and create_receipt workflows. The optional 'company' parameter provides the necessary context for targeted usage.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint. The description adds the useful ordering detail 'newest first', which is not in annotations, but says nothing about pagination, how the limit interacts with that ordering, or session/auth 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 description is a single fragment with no filler and puts the ordering constraint up front. It is economical but also under-specified rather than fully structured, lacking a verb and any usage context.

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?

Structured data is rich: an output schema exists, annotations cover safety, and most parameters are documented. The main remaining gap is sibling differentiation and scope, but the description is minimally sufficient to call the tool 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 75%, with company, date_from, and date_to documented in the schema; only limit lacks a schema description but has clear default/min/max constraints. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states the resource ('Receipts (kvitton)') and an ordering rule ('newest first'), which implies a list operation. However, it uses no verb and does not distinguish this tool from the singular sibling get_receipt or from get_supplier_invoices.

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

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

There is no when-to-use guidance, no named alternative such as get_receipt for a single receipt, and no prerequisites such as needing connect_wint. The agent must infer selection from the plural name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the safety profile is covered. The description adds only "with all its details," which is a vague hint at completeness and says nothing about scoping, error behavior when the invoice is not found, or company resolution.

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

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

A single short sentence with no filler and the resource front-loaded. It is efficient, though its brevity borders on under-specification rather than tight writing.

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?

An output schema exists so return values need not be explained, but the description still leaves the required invoice_id semantics and multi-company scoping unaddressed. For a two-parameter fetch tool it should say at minimum what identifier to supply and when company is needed.

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%: company is documented in the schema, but invoice_id carries no description anywhere. The description does not explain the invoice_id format, its source, or how the optional company parameter affects lookup when multiple companies exist, leaving the gap uncompensated.

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?

"One supplier invoice with all its details" implies a singular fetch of a supplier invoice, which is distinguishable from the plural get_supplier_invoices only by the word "One." It never states the retrieval verb or explicitly contrasts with the list sibling, so an agent must infer the difference from 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?

There is no guidance on when to use this versus get_supplier_invoices, list-type siblings, or approve_supplier_invoice. No prerequisites (e.g., whether an invoice must exist or be uploaded first) are mentioned.

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 this as a read-only, idempotent, non-destructive open-world read, so the safety profile is covered. The description contributes only the 'newest first' ordering; it says nothing about pagination, the 50-item default, the 200 cap, or what omitting company does when multiple companies exist.

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

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

A single short sentence with the key attribute (ordering) front-loaded and no filler. It is efficient, though it errs toward under-specification rather than saying anything wasteful.

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 an output schema present and rich annotations, the description needn't explain return values, but for a two-parameter list tool where one parameter is undocumented and multi-company behavior is ambiguous, the description leaves material gaps an agent would need filled.

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%: company is documented in the schema, but limit has no description at all, and the description does not compensate by explaining what limit counts or how ordering interacts with it. The description adds no parameter meaning beyond what the schema already shows for company.

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

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

The description names the resource (supplier invoices) and adds the Swedish domain term plus a sort order, so the agent knows what it gets back. However, it supplies no verb (only the name implies 'get') and does not distinguish this list tool from the sibling get_supplier_invoice, which fetches a single invoice.

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

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

There is no statement of when to use this list tool rather than get_supplier_invoice, search_wint, or list_missing_documents, and no prerequisites or exclusions are given. 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.

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior: results are returned newest-first and amounts use debit-positive/credit-negative signs — exactly the kind of domain detail an agent cannot get from annotations or 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?

Two short sentences, front-loaded with the resource and ordering, with the amount convention packaged compactly. Nothing is wasted and no filler.

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

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

With an output schema and rich annotations present, the description does not need to explain return shape or safety. It covers ordering and amount signs well, but leaves a small gap around sibling selection and default-limit behavior, so it is not fully complete for a 7-parameter retrieval 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 86%, so parameters like text, company, date ranges and BAS account range are already documented. The description adds no parameter-level meaning (e.g. how text matching works or whether limit truncates silently), so baseline 3 applies.

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

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

States a specific resource ('Ledger transactions (verifikationsrader)') with an ordering guarantee ('newest first'), plus the amount sign convention. However it never distinguishes this from close siblings like get_voucher, get_accounts, or get_financial_report, so an agent must infer why to pick this one.

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

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

There is no when-to-use or when-not-use guidance, and no named alternative. The description implies this is a listing tool for ledger entries, but nothing tells the agent whether to reach for get_transactions, get_voucher, or get_bank_balances for a given question.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that the result is a single voucher including its transactions, but provides little further behavioral context such as error cases or scope limitations.

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 brief sentences, front-loaded with the core purpose and followed by the key input dependency. There is no redundant or filler 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?

For a simple read tool with rich annotations and an output schema, the description covers what it returns and where the required id comes from. The omission of any mention of the optional company parameter is acceptable because the schema documents it clearly.

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%, and the description compensates for the undocumented required voucher_id by explaining its source in get_transactions. The company parameter is handled by the schema description, so the combined semantics are adequate.

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

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

The description clearly identifies the resource ('One voucher') and adds that transactions are included, which distinguishes it from the sibling get_transactions. It stops short of using an explicit retrieval verb, but the intent is unambiguous.

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

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

It gives a concrete prerequisite: voucher_id comes from get_transactions. That tells the agent when this tool is applicable and how to obtain the required input, though it does not state exclusions or contrast with other sibling 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?

The annotations already disclose that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful scope by saying results are limited to companies the current Wint user can access, and it mentions returned identifiers, but it does not explain authentication requirements, pagination, or other behavioral details beyond what annotations and the output schema provide.

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 compact phrase with no wasted text. It front-loads the resource and scope, then notes the return fields. For a zero-parameter list tool, this is 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 an output schema present, the description does not need to explain return values in detail, and with rich annotations it does not need to restate safety properties. It gives the essential scope and return hints. It could be slightly more complete by mentioning the connected-user prerequisite, but the core information is present.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics for the description to clarify, and the schema is trivially complete for a no-argument list operation.

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 resource and scope: companies accessible to the current Wint user. It also names the returned identifiers. It does not explicitly use a verb like 'list', but the title and name supply that, and no sibling tool covers the same company-listing purpose.

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 'this Wint user can access' implies the tool is used after authenticating a Wint user and is scoped to that user's permissions. There is no explicit when-to-use statement, prerequisite note, or comparison to alternatives, but the usage is reasonably implied by the description.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral value beyond them by explaining that each result carries a missing_document_id intended as the input to attach_missing_document, tying this read to a specific write workflow. It says nothing about result volume or whether the list is exhaustive.

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 sentences, no filler, and the resource definition is front-loaded ahead of the cross-tool hint. Nothing is repeated from the schema or annotations.

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?

An output schema exists, so return-value explanation is unnecessary, and the annotations carry the safety profile. For a read-only single-parameter listing tool, the description plus schema gives an agent everything needed to call it and to chain into attach_missing_document.

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

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

Schema coverage is 100% for the single company parameter, including the note that it may be omitted when only one company exists, so the schema does the work. The description contributes no additional meaning about how company scoping affects the result set, which is the correct baseline-3 outcome here.

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 identifies the exact resource and its filter condition: payments flagged by Wint as missing a receipt or invoice. It is specific enough that an agent knows what comes back, though the verb is only implied by the tool name rather than stated, and no other sibling (e.g. get_receipts) is explicitly contrasted.

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

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

Usage is implied rather than stated — the agent can infer this is the discovery step before attach_missing_document, which is named explicitly. There is no statement of when to prefer this over get_receipts or get_supplier_invoices, and no prerequisites (e.g. Wint connection required) are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description does add genuinely behavioral context beyond them — that only open, non-snoozed items are returned — which is a meaningful filter the schema does not express. It is silent on pagination behavior and result ordering, so it adds value but not deeply.

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

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

A single front-loaded sentence that establishes the scope constraint ('open, not snoozed') before listing representative examples. The trailing 'and more' is mild filler but the enumeration is doing real work by hinting at the types parameter values.

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?

An output schema exists, so return-shape explanation is unnecessary. For a zero-required-parameter aggregate list tool, the description covers scope and content adequately. It could go further by explaining how to act on returned to-dos (which siblings consume which type), but nothing critical to invocation is missing.

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

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

Schema description coverage is 67%, with the types parameter well documented including example values, and company described as id-or-name with the single-company omission rule. The description contributes nothing about limit, types, or company, so it neither compensates for the uncovered limit parameter nor adds meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly identifies the resource — open, non-snoozed to-dos in Wint — and enriches it with concrete examples (missing documents, supplier invoices, receipts, accountant messages). An agent understands this is an aggregate inbox feed rather than a single-entity getter, though the description never explicitly contrasts itself with siblings like list_missing_documents or get_supplier_invoices, which return overlapping subsets.

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

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

Usage is only implied: an agent can infer this is the broad 'everything outstanding' entry point versus the type-specific sibling tools, but nothing states when to prefer this over list_missing_documents or get_receipts. No prerequisites, no mention of whether it requires a connected Wint session (connect_wint/wint_status exist as siblings).

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds the genuinely useful behavioral fact that results are capped to the last hour and that each item carries an upload_id, which enables chaining to upload_stage. It says nothing about ordering or truncation behavior, keeping it short of 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?

A single front-loaded sentence that conveys resource, source channel, time window and a key returned field with no wasted words.

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

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

For a zero-parameter read tool with an output schema, the description is nearly sufficient: the time-window constraint is the one behavior an agent could not learn elsewhere. It leaves the concept of 'upload panel' undefined, which is the remaining ambiguity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The mention of upload_id pertains to the result shape rather than input semantics.

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

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

Names the resource (files uploaded), the scope (through the upload panel, last hour) and one returned field (upload_id), which is concrete enough to distinguish it from a general document listing. It lacks an explicit verb like 'list' and does not name a sibling it differs from, so it falls short of a 5.

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

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

Aside from the 'last hour' scope hint, it offers no guidance on when to call this versus list_missing_documents or upload_stage, nor any prerequisite (e.g. requiring a connected session via connect_wint). The agent must 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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety behavior is covered. The description adds scope (which entity types) but does not clarify matching behavior, result limits, or whether all entity types are always searched.

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 efficient sentence that front-loads the action and scope with no wasted words.

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

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

For a simple two-parameter search tool with an output schema and rich annotations, the description is largely sufficient. The remaining gaps are usage routing and result behavior, which are minor given the structured metadata.

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%: company is documented in the schema, while query is undocumented there. The description supplies query semantics ('by name or number'), which partially compensates, but it says nothing about the company parameter and its interaction with the optional company filter.

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 (search) and enumerates the resources searched: suppliers, customers, employees, articles, invoices, receipts. It is meaningfully distinct from single-record get_* tools and list_* tools, though it does not explicitly name siblings.

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

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

The phrase 'by name or number' implies when to use this over listing tools, but it gives no explicit when/when-not guidance or alternative routing. An agent must infer that this is for lookup-based queries across entity types.

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 say readOnly=false, destructive=false, idempotent=false, openWorld=true; the description adds the crucial piece the annotations cannot convey — that without confirm the call only returns a preview and nothing is applied. It does not disclose partial-update semantics (what happens to fields left null) or any permission requirements, which keeps it below a 5.

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

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

Two sentences, front-loaded with the verb and resource, with the preview caveat placed last where it is most actionable. No redundant restatement of the title or schema.

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

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

With 17 parameters, an output schema, and full annotations, the description covers the main risk (accidental submission) and a concrete workflow. The remaining gap is that it never says whether unspecified fields are left untouched or cleared, which matters for a 17-param partial update.

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 76% and the schema already documents the tricky parameters (confirm, submit, purpose, remove_attachment_ids). The description only references category, purpose, and the receipt file, adding workflow ordering rather than new parameter meaning, 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 ('Edit a receipt') plus the optional submit action, which separates it from create_receipt in the sibling list. It stops short of explicitly naming create_receipt or get_receipt as the alternative, but the resource and operation are 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?

Gives a concrete usage scenario ('finish a Wint card receipt draft: set category and purpose, add the receipt file, then submit') and states the preview-only behavior without confirm, which effectively encodes the two-step call pattern. It does not state when to prefer create_receipt over this tool, so no explicit exclusion.

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, and the description productively explains *why* a tool called 'upload_document' is read-only: nothing is transmitted to Wint until attach_missing_document runs. That deferred-commitment semantics plus the 10 MB / file-type limits are real behavioral context the annotations cannot express. Return shape is covered by the output schema, so no penalty there.

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

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

Three short sentences, front-loaded with the action and its constraints, then the output artifact, then the most surprising fact (nothing is sent yet). No sentence is redundant or padded.

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

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

With zero parameters, an output schema and full annotations, the description supplies everything needed to invoke it correctly and to interpret the upload_id. The only real gap is sibling differentiation inside a set of five upload-named tools, which the description does not resolve.

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

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

The tool takes zero parameters, so the baseline is 4; the schema fully closes the object with additionalProperties=false. The description correctly implies the file and its constraints come from an interactive panel rather than from arguments, which prevents the agent from inventing inputs.

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

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

States a specific action (open a file-picker panel), the accepted resource types (receipt or invoice, PDF or image), and a hard constraint (max 10 MB), which is far more informative than the bare name 'upload_document'. It partly disambiguates from the family of upload siblings by scoping inputs to receipts/invoices and by naming attach_missing_document, but it never says how it differs from upload_supplier_invoice, upload_other_document or upload_stage.

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 explicit: this is the first step of a two-step flow whose second step is attach_missing_document, with the upload_id as the handoff key. What it omits is any exclusion rule against the three sibling upload tools, so an agent facing a generic upload request still has to guess.

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 a non-read-only, non-idempotent, open-world write with destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior the annotations cannot express: without confirm it only returns a preview, meaning the 'write' is not actually performed on the first call. It stops short of saying what confirm=true does externally (documents appear in Wint) or whether repeats create duplicates.

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 sentences, no filler, and the identity of the tool is front-loaded before the confirm/preview caveat. The embedded Swedish UI string is slightly noisy for an agent but carries real disambiguation value.

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?

An output schema exists, so return-value explanation is unnecessary, and the preview semantics are captured. Still, for an 8-parameter upload tool with only 38% schema coverage, the description leaves the file-input permutations and company/booking_date handling entirely to the schema, which is the weakest link here.

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 38% across 8 parameters, so the description must compensate and does not. It never explains the mutually exclusive file-source options (file_url, file_base64, upload_ids, file_name) or how company and booking_date interact with the document, leaving the most error-prone part of the call undocumented.

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 ('Send') and resource ('any other bookkeeping document') and grounds it in the concrete Wint UI path 'Lägg till dokument → Övrigt', which makes the scope identifiable. The word 'other' plus the examples (contract, statement, letter) imply a catch-all category distinct from receipts/invoices, though it never names the sibling tools doing those jobs.

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

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

The examples give a usable sense of when this applies, and the preview-on-no-confirm rule tells the agent about a two-step invocation pattern. However, with siblings like upload_document, upload_supplier_invoice, upload_stage, and attach_missing_document present, the description never states which one to pick for which file type — the differentiation is implied by 'other' 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 this is a non-destructive, non-open-world write, so the safety profile is covered. The description adds genuine behavioral context beyond that: only one file is held and retention is capped at one hour, implying an ephemeral, single-slot store. It stops short of saying what happens at expiry, whether a new upload replaces the held file, or whether the stage must be explicitly consumed.

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

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

One short sentence with no filler, and the scoping constraint is front-loaded. But brevity here is under-specification rather than economy: the sentence spends its words on panel scoping and TTL while omitting the action itself.

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?

An output schema exists, so return values need not be explained, but the definition is still thin for a mutating tool with three undocumented parameters. It should state that data_base64 is base64-encoded file content, note any size ceilings, and describe the lifecycle of the staged file (consumed vs. overwritten vs. expired).

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 all three parameters (file_name, data_base64, content_type) are undocumented and the description compensates for none of them. There is no mention of base64 encoding expectations, size limits, or default content-type behavior for the nullable field. Only the single-file constraint loosely hints at how repeated uploads behave.

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 conveys that this stages a single file server-side for up to an hour, but never states the action plainly ('upload a file to a temporary staging area') and the verb is left implicit. 'Upload panel only' distinguishes it somewhat from siblings like upload_document, but not enough to tell an agent exactly what the tool produces or why staging exists.

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?

'Upload panel only' is an implied usage context and a soft exclusion, hinting it belongs to an interactive panel rather than programmatic document uploads. However, no sibling is named as the alternative (upload_document, upload_supplier_invoice, upload_other_document), and there is no guidance on what to do with the staged file afterwards or when to prefer those 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 declare openWorldHint=true, non-idempotent, non-destructive, but say nothing about what the commit actually does. The description supplies that: Wint parses the invoice, it enters an approval queue, and an unconfirmed call is a safe dry-run preview. It omits duplicate handling and what a preview returns, but the core side-effect story is clearly disclosed.

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

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

Two short sentences, front-loaded with the action and immediately followed by the preview/commit distinction. No filler.

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

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

An output schema exists so return values needn't be described, but for a six-parameter upload tool with three mutually alternative file-source inputs and zero required parameters, the description leaves the agent guessing which combination is valid. That is a substantial gap for the tool's core invocation question.

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 17% and six parameters are optional, yet the description only adds meaning for confirm. The critical ambiguity - file_url vs file_base64 vs upload_ids vs file_name as alternative ways to supply the file - is left entirely undocumented in both schema and 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?

States a specific verb and resource (send a supplier invoice file to Wint) and anchors it to the corresponding UI action, which makes the intent unambiguous. It doesn't explicitly contrast itself with the neighbouring upload_document / upload_other_document tools, so it stops short of a 5.

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

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

The confirm gate is explained ("without confirm it only returns a preview"), which is genuine when-to-use guidance. But there is no explicit routing between this tool and upload_document, upload_other_document, or upload_stage, even though all four appear as siblings, leaving the main selection question 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 establish readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description still contributes a genuinely useful trait not in the annotations: 'Makes no Wint call,' meaning it reads local state without hitting the external service, which tells the agent it is safe and cheap to poll. It stops short of saying what statuses can come back, but the output schema covers 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?

Two short sentences with no filler, and the primary fact (what is reported) comes first while the operational caveat follows. Slightly clipped to the point of being fragmentary, but every clause 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 zero-parameter local status check with a full output schema and strong annotations, little more is needed. The one residual ambiguity is whose login attempt is meant (the bankid login flow implied by bankid_login_start/poll), which an agent can resolve from 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?

The tool takes zero parameters, so the baseline is 4 by rule. There is nothing for the description to compensate for, and it correctly does not waste words on nonexistent inputs.

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

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

The description names the specific state being reported (whether a session is stored, plus the latest login attempt's status), which is concrete rather than a restatement of the name. It does not explicitly contrast itself with connect_wint or bankid_login_poll, so sibling differentiation relies on the reader inferring it, but the purpose is unambiguous.

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

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

Usage is only implied: an agent can infer this is the cheap pre-flight check before calling connect_wint or the bankid login tools. There is no explicit 'use this before X' or 'use Y instead' statement, and no exclusion conditions are given. Adequate but leaves routing to inference.

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