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

The description discloses far more than the sparse annotations (all false hints): the request itself processes nothing, DATANORM uploads get auto-checked but prices are never applied, receipts are only stored, images can be attached to an order, the link requires a Meistron login to work, and files cannot be passed through chat as text or Base64 — with the rationale that character fidelity matters. These are exactly the behavioral traits that would otherwise cause an agent to promise the user the wrong outcome.

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 longer than average (four paragraphs), but every sentence earns its place: purpose first, then post-upload behavior, then the chat constraint with justification, then the direct action commands (show the link, require login, check with datei_stand). The rationale sentence about character loss is slightly verbose but helps an agent explain the constraint to a user. Front-loaded structure is excellent.

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 5 parameters, a two-phase idempotency protocol, and differentiated post-upload behavior, the description plus 100%-covered schema form a complete picture: the returned link is mentioned, the login prerequisite is stated, the follow-up tool is named, and per-file-type outcomes are specified. The behavior that only images appear in the order's photos is documented in both schema and description. No critical gap remains 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 100%, so the baseline of 3 applies. The schema already documents the zweck enum values, the lieferant_id requirement for datanorm (including the lieferanten_auflisten pointer), the two-phase idempotency_key protocol, and the gehoert_zu_auftrag caveat about no file view existing yet. The description's mention of 'Preisdateien von Lieferanten (DATANORM), PDFs, Belege und Fotos' reinforces the enum mapping but adds no new per-parameter 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 first sentence states a specific verb+resource+outcome: 'Fordert eine Datei vom Menschen an und gibt einen Link zurück, über den er sie in Meistron hochlädt.' It lists the exact file types (DATANORM, PDFs, Belege, Fotos) and clearly differentiates from the sibling datei_stand by describing request-vs-check roles in one workflow.

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 when to use the tool (needing a file from a human, with the chat-upload path explicitly ruled out) and names datei_stand as the follow-up step. It also explains what the tool does NOT do — it does not apply prices or articles, which prevents misuse. It never explicitly names an alternative tool for a given condition, but the workflow and exclusions are concrete enough that an agent can route correctly.

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