Upload Other Document

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.