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

Adds real context beyond the annotations: the output is a proposal pending approval, not a committed posting, and it is computed server-side from live Fortnox data across all pages. This explains why readOnlyHint=true despite "Bokför" in the title — an important non-obvious clarification. Minor tension: "over all pages" sits awkwardly with the per-call "max 10/20 filer" cap in the schema.

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

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

Front-loaded with the action and outcome, followed by a concrete example question. The trailing sentence about Fortnox data provenance and "over all pages" reads as boilerplate that partially repeats what the annotations and schema already imply.

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 and annotations cover safety, so the return shape needs no explanation. However, for a 4-param tool with a steg control that can reach actual booking, the description should say where the proposal goes for approval and how it relates to the propose_* and execute_* siblings; that routing 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 100%, so the four parameters (max, steg, filer, kontering) are already documented upstream. The description adds nothing about them — notably it never explains that steg can push the flow as far as bokfor, which materially changes what "prepare" means.

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 chain: supplier invoices in the inbox are interpreted, matched and coded ("tolkade, matchade och konterade") into a ready-to-approve proposal. That distinguishes it from single-invoice siblings like propose_bookkeep_supplier_invoice, though the batch scope is only implied by "i ett svep" rather than stated as an explicit contrast.

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 example question ("Bokför leverantörsfakturorna som ligger i inkorgen") anchors the trigger scenario well. But no alternatives are named — an agent cannot tell from this text whether to use get_inbox/list_unprocessed_inbox first, or when to prefer propose_bookkeep_supplier_invoice for a single invoice.

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