Kvickd

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

Goes well beyond annotations: discloses the authorization requirement (kräver behörigheten reconcile), the side effect (raden sparas), and what it deliberately does NOT do (attesten ändras inte, done by a human in the app). It also describes the return payload, which matters since there is no output schema.

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

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

Front-loads the core action and row-preservation behavior, then layers usage, return values, side effects, and permissions in a tight sequence. Each sentence carries distinct value with 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?

For a 7-param mutation with no output schema, the description covers purpose, sibling routing, return contents (rader, avstämt belopp, differens), side effects, and permissions. Nothing an agent needs to call it correctly 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 all seven parameters are already documented in the schema (formats, units, examples, sourcing via list_companies/get_open_reconciliations). The description adds no parameter-level meaning beyond that, so the 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?

States a specific verb (lägger till) and resource (manuell specifikationsrad på en avstämning/bilaga), plus the key constraint that existing rows are preserved. It explicitly names and distinguishes itself from the sibling set_bilaga_spec, so an agent can tell them apart without opening the schema.

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

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

Explicitly states when to use it (lägga till en enstaka post, e.g. the whole closing balance to zero out the difference) and names the alternative set_bilaga_spec for the opposite case (ersätta eller tömma alla rader på en gång). Both the when and the when-not are covered.

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

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

Goes well beyond the annotations by disclosing side effects: the balance sheet is rolled forward automatically, the income statement restarts at 0, and prior-year result is moved from 2099 to 2091 on the new year's first day only if the year-end closing is already booked, otherwise at prior-year lock. It does not cover permissions/auth requirements or how the 'no gaps' rule surfaces as an error.

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 the two modes before the carry-forward mechanics, so the key routing information comes first. The single dense sentence about the 2099/2091 transfer and the trailing 'Scope book. Argument: ...' clause add length, with the argument recap being partly redundant with the schema.

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

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

For a 2-parameter mutation tool with no output schema, the description covers what it does, when each mode applies, and the accounting side effects. Missing pieces are the return value and any authorization/ownership prerequisites on orgnr, but the essential decision-making 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?

Schema coverage is 50%: orgnr is documented in the schema, but year is not. The description compensates by clarifying that year is the end year of the fiscal year (slutår, e.g. 2027), which is genuinely non-obvious for a fiscal-year span. It also restates the required argument pair, though that duplicates the schema.

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

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

States a specific verb+resource ('Lägg till ett räkenskapsår') and immediately enumerates the only two supported modes: the year after the latest (new year) or the year before the earliest (start bookkeeping in an earlier year without a SIE file). This distinguishes it clearly from siblings like list_fiscal_years, lock_fiscal_year, and transfer_prior_year_result.

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

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

Gives explicit conditions for the two modes of use and the hard constraint 'Inga luckor' (no gaps), which tells the agent when the call will fail. It does not name alternative tools (e.g. import_sie for bulk historical years), so the when-not guidance is implied rather than explicit.

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

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

Annotations already declare write (readOnlyHint=false), non-destructive and non-idempotent. Beyond those, the description adds two useful facts: the permission required and the persistence effect ('becomes context for future agents'). It still omits whether repeated calls accumulate instructions or how text is retained, so it exceeds the annotation baseline only modestly.

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

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

Short and front-loaded with the purpose before the examples and prerequisites. The trailing 'Argument: text' is largely redundant with the schema, but overall there is little waste.

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 single-param write tool with no output schema, the description covers purpose, examples, persistence and auth. It leaves open whether instructions accumulate, whether they can be overwritten, and what the response is, so it is adequate but leaves gaps.

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

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

One parameter with 0% schema description coverage, so the description must compensate. It gives content hints via examples (posting rule, exception) but the closing 'Argument: text' merely restates the schema property name without explaining format, length, or constraints.

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: 'Spara en instruktion till koncernens LLM-kontext' (save an instruction to the group's LLM context), plus concrete examples (a posting rule or an exception). The purpose is clear and distinct; it does not explicitly differentiate from siblings, but no sibling appears to serve this function.

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 clear when-to-use rationale ('så vi vet om det här framgent') with illustrative examples and names the required permission 'manage_documents'. It does not state when NOT to use it or name alternatives, which keeps it short of a 5.

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

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

Annotations declare a write operation (readOnlyHint=false) that is non-idempotent and non-destructive. The description adds real business context beyond that: a 24-hour-per-day validation cap, the immediate-attestation workflow via approve=true versus a pending state, and the payroll scope. It stops short of covering auth requirements or duplicate/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?

A single dense paragraph that front-loads the action, then the behavioral rules (24h cap, approve), then the argument list. Every clause carries information; the trailing argument list is a bit list-like but still earns its place given the low schema coverage.

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

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

For an 8-parameter write tool with no output schema, the description covers the action, a validation rule, the approval workflow, and all parameter formats. It omits error/duplicate handling and where employee_id originates, but is otherwise complete enough to invoke correctly.

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

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

Schema description coverage is only 13%, so the description must compensate, and it does: it lists all eight arguments, adds the work_date format (YYYY-MM-DD), an example for hours (7.5), and enumerates the kind values (arbete|overtid|ob|sjuk|semester|vab|ledig) that appear nowhere as schema enums. It does not explain employee_id or project sourcing beyond a brief gloss.

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: add a time entry for an employee (e.g. from a time slip). This clearly distinguishes it from list_time_entries, delete_time_entry and review_time_entries, though it does not name those siblings 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?

Provides an era-of-use hint ('t.ex. från en tidlapp') and explains the approve=true vs pending-attestation behavior, which effectively guides the caller. However, it names no alternatives and gives no explicit when-not-to-use guidance, so usage is implied rather than spelled out.

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

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

Beyond the annotations (which only declare non-readonly, non-idempotent, non-destructive), the description discloses the persistent side effect (file saved among the company's underlag), the pool behavior when voucher_id is omitted, the required 'upload' permission, and the return payload. This is exactly the behavioral context annotations cannot carry.

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

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

Purpose first, then routing rules, then return values, side effects and the permission requirement — every sentence carries distinct information with no filler, despite the length the content is front-loaded and scannable.

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

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

There is no output schema, but the description enumerates the return fields (id, filename, filetype, size, voucher-id or null), states the side effect, links all four sibling alternatives and the permission prerequisite. An agent has everything needed to select and invoke it correctly.

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

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

With 100% schema coverage the schema already documents all four parameters, so the baseline is 3. The description still adds meaning beyond the schema by tying content_base64 to the 'small file' constraint and explaining that omitting voucher_id routes the file into the underlag pool for later linking with attach_underlag.

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 ('Laddar upp en liten fil ... som underlag och kopplar den valfritt till ett verifikat') with the distinguishing scope condition (small, base64-encoded, optionally linked to a voucher). An agent can tell it apart from attach_underlag, create_underlag_upload and upload_underlag without opening any schema.

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

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

Explicit when-to-use ('Använd när filen inte redan finns i Kvickd och är liten nog att skicka base64-kodad') followed by three named alternatives with the exact condition that selects each: existing file -> attach_underlag, large file -> create_underlag_upload, reconciliation -> upload_underlag. Nothing is left to inference.

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

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

Annotations only give generic hints (readOnlyHint=false, idempotentHint=false); the description adds real behavior: it discloses that the operation posts ('KODEN postar'), that it zeroes VAT accounts against the accounting account, that scope 'book' is required, and that a booking cap (0 = unlimited) can block it. This is meaningful disclosure beyond the structured fields, though reversibility/undo is not addressed.

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

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

Compact and front-loaded: purpose first, then mechanism, then constraints, then arguments. No filler sentences, though the trailing 'Argument:' list partly duplicates the schema.

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

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

For an irreversible-looking posting tool with no output schema, the description covers scope, cost/cap guard, what gets posted, and the argument set. Missing only failure/state preconditions and whether the approval can be undone, which is a modest gap.

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

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

Schema coverage is only 33% - only orgnr is documented (with a list_companies hint). The description compensates partially by explaining that key is a 'periodnyckel' and year is optional, which the schema does not say. That is useful but shallow, leaving formats and how to obtain the period key unstated.

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 pair ('Godkänn och bokför') and resource ('momsavräkningen för en period') and even describes the mechanism ('nolla momskontona mot redovisningskontot'), which separates it from read-only siblings like get_vat_return and list_vat_periods. It stops short of explicitly naming those siblings, so not 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?

Context is implied (a period-based VAT reconciliation that must be booked) and two hard prerequisites are given: scope 'book' and a booking cap that must not be exceeded. However, it never states when to choose this over get_vat_return or list_vat_periods, nor what state a period must be in before approval.

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 substantial behavior beyond annotations: it posts into the general ledger as a normal voucher, the code validates double-entry bookkeeping, it requires the 'book' permission, and a booking cap on the key applies. These auth/side-effect details go well past the readOnly/destructive/idempotent hints.

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?

Dense but front-loaded with the core action first, then validation/auth/cap caveats. The trailing 'Argument: orgnr, draft_id' is redundant with the required-parameters schema, a minor waste.

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

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

No output schema, but the description covers the mutation's side effects, permission requirement, validation, and usage guard, which is most of what an agent needs. The undocumented draft_id semantics are the remaining gap.

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

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

Schema coverage is only 50% (draft_id has no description) and the description merely lists 'orgnr, draft_id' without explaining either. It adds no meaning over the schema and does not compensate for the undocumented draft_id, which the agent must supply from context.

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 precise compound action ('Godkänn och bokför ett väntande verifikatförslag') with verb+resource, and the '(draft)' qualifier plus sibling context makes it clearly distinct from reject_voucher_draft and edit_voucher_draft. An agent can distinguish it without opening the schema.

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

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

Provides an explicit guard condition: only act when the user has instructed approval. That is a clear when-to-use constraint and implicitly steers away from reject/edit siblings. It stops short of naming those alternatives explicitly, hence 4.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description still adds substantial extra context: the state side effect (posten flyttas från väntande till hanterade), the required permission (manage_documents), and the returned payload with new status 'filed'. These go well beyond what the annotations disclose.

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

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

Front-loads the action and its effect, then usage/exclusions, then return, side effect, and permission requirement. Every sentence carries information an agent needs; no filler or 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 3-parameter mutation with no output schema, the description supplies the missing pieces: the return value shape, the state transition, and the authorization requirement. Combined with complete schema coverage and informative annotations, nothing essential is left unstated.

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%, with orgnr, inbox_id, and category all documented, including examples and the list_companies/list_inbox lookup hints. The description reinforces that a category is stored with the attachments but adds no syntax or format detail beyond the schema, so 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?

States a specific verb and resource ('Arkiverar en post i inkorgen') plus the concrete effects (bilagorna sparas i dokumentarkivet, posten markeras som hanterad). It explicitly distinguishes itself from close siblings create_supplier_invoice and attach_underlag, so an agent can route correctly without opening schemas.

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

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

Gives explicit when-to-use ('avtal, policyer, protokoll och liknande som ska sparas') and names two alternatives together with the conditions that select them ('ska en leverantörsfaktura registreras, använd create_supplier_invoice'; 'ska ett kvitto kopplas till ett verifikat, använd attach_underlag'). This is textbook routing 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?

Goes well beyond the annotations: it discloses that it works on already-booked vouchers, that the side effect is only an attachment (bookkeeping itself is unchanged), that the book permission is required, and what is returned. None of this is derivable from the readOnly/destructive/idempotent hints alone.

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

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

Front-loads the core action, then groups use-cases, alternatives, return, side effect, and permission into tight sentences. Every sentence carries information an agent needs; there is 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?

Although there is no output schema, the description states the return shape (voucher id and attached underlag), the permission requirement, and the mutation boundary. For a 4-parameter mutation tool this covers everything needed to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: it maps document_ids to inbox/uploaded documents and underlag_ids to the underlagspool, and points to list_available_underlag for retrieval. It stops short of noting that at least one of the two optional arrays is presumably required for a meaningful call.

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 existing underlag to a verifikat) and immediately distinguishes itself from siblings add_voucher_underlag and create_underlag_upload for new uploads. The agent can tell what this does and what it does not without opening any schema.

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

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

Explicitly names when to use it (existing documents, including on already-booked vouchers), which two parameter paths apply, how to get the ids (list_available_underlag), and redirects to add_voucher_underlag/create_underlag_upload when a new file must be uploaded. Nothing is left to inference.

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

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

Beyond the annotations (readOnly=false, idempotent=false, destructive=false), it discloses real behavioral traits: the voucher posts immediately, a booking cap must not be exceeded, the book permission is required, ROT/RUT invoices split across 1510/1513, and it returns the invoice with voucher number and status. This is the kind of context annotations cannot carry.

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

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

Front-loaded with the core action and accounting effect, and every sentence carries operational content (alternatives, ROT/RUT, side effects, permission). It is dense and fairly long, but nothing is 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?

For a posting/mutation tool with no output schema, the description covers return value ('returnerar fakturan med verifikatnummer och status'), side effects, prerequisites, and auth. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so both params (orgnr, invoice_id) are already documented with format and retrieval hints. The description adds no syntax or meaning beyond the schema for the parameters themselves, 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?

States a specific verb and resource ('Bokför en kundfaktura') and pins the precondition that it was created by create_customer_invoice. It elaborates the exact accounting outcome (D 1510 / K intäkt / K moms 2610-2630), which makes it unmistakable from neighbors like book_voucher or create_voucher.

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

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

Explicitly says to use this for customer-ledger invoices 'istället för book_voucher eller create_voucher', naming the alternatives and the reason (correct status, payable via register_customer_payment). It also flags the ROT/RUT special case and its completeness prerequisite (husarbete.missing).

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

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

Goes well beyond the annotations (which only say non-read-only, non-idempotent, non-destructive): it discloses a side effect (voucher is posted directly), a hard constraint (a configured bokföringstak must not be exceeded), an authorization requirement (permission 'book'), and the return content (voucher number and status).

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?

Dense but front-loaded: purpose first, then alternatives, then side effects, then currency handling. Every sentence carries information, though the single unbroken paragraph could be trimmed or structured slightly for faster scanning.

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

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

For a mutation tool with no output schema and no annotations beyond safety flags, the description covers the essential gaps: it describes what is returned (voucher number and status), the posting side effect, the booking-limit constraint, and the permission requirement.

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% with rich per-parameter descriptions and examples, so the baseline is 3. The description adds meaningful semantics for fx_rate/total_sek_ore: they must reflect a rate the user actually supplied and must never be guessed, which is decision-guiding context the schema does not state.

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 (book a supplier invoice) and immediately scopes it: an invoice already registered via create_supplier_invoice. It names the sibling tools it is not (book_voucher, create_voucher), so an agent can distinguish it without opening any schema.

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

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

Explicit when-to-use: invoices in leverantörsreskontran, already created by create_supplier_invoice. Explicit alternatives and the reason to prefer this one (correct status, payable via register_supplier_payment), which routes the agent correctly among many booking 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?

Goes well beyond the annotations: discloses the immediate posting side effect ('verifikatet postas direkt'), the validation rules enforced server-side (debit=kredit, minimum two rows, period not locked, booking ceiling), the required 'book' permission, and currency-handling behavior. This is strong behavioral disclosure for a non-idempotent mutation. Slightly short of 5 only because it does not describe whether/book the operation can be reversed or what happens on partial failure.

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

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

Front-loaded with purpose, then alternatives, return values, side effects, validation, currency guidance and permission in a logical order. Dense but each block earns its place; the currency paragraph is long but necessary given the ambiguity of the parameters.

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-param mutation with no output schema, it supplies the return shape (id, serie, nummer), the safety/authorization profile and validation constraints. Remaining gaps are the undocumented scalar params (orgnr, series, text), but the high-risk currency path and the required basis are fully covered.

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

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

Schema coverage is only 8% across 12 params, so the description must carry the burden. It explains the most ambiguous parameters well (basis as mandatory source reference, currency, foreign_amount_minor, fx_rate, total_sek_ore with the 'never guess the rate' rule), but leaves orgnr, series, text, lines, finding_ref and proposal_id entirely undocumented. Partial compensation for a large coverage gap.

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

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

States a specific verb and resource ('Bokför ett verifikat i huvudboken') plus the defining constraint (debet-/kreditrader and a mandatory källhänvisning/basis). It explicitly distinguishes itself from sibling tools create_voucher and propose_voucher by name, so an agent can route correctly without opening a schema.

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

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

Gives an explicit trigger ('Använd när verifikatet bygger på något du har läst i Kvickd... och ska kunna spåras dit') and names two alternatives with the conditions that select them: create_voucher for signed amounts with attachments, propose_voucher when a human must review first. When/when-not/alternatives are all present.

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

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

Annotations only give the generic safety profile (readOnly=false, destructive=false, idempotent=false). The description adds real context beyond that: it never locks the period (a human does), it requires scope book, and it discloses that for proposal-backed steps the code — not the LLM — writes the voucher. Consistent with annotations, no contradiction.

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 verb and resource, then mode rules, then the locking/scope caveats, then the argument summary. Dense but each sentence carries distinct information; 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?

For a non-idempotent mutation with no output schema, the description covers the posting model, scope requirement, and all arguments, which is close to sufficient. It omits error/reversal behavior and the resulting voucher reference, and the unexplained action values leave a small gap.

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

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

Schema coverage is only 25% (just orgnr), so the description must compensate, and it does list step's allowed values (periodiseringar|dispositioner|aktuell_skatt|arets_resultat) plus the journal element shape ({account, debit_ore, credit_ore, text?}). However it repeatedly references action='book'/'manual', a parameter absent from the schema, which risks leading an agent to pass a nonexistent argument.

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 ('Bokför ett årsavslutssteg') and immediately clarifies the division of labor between code and LLM. It is distinguishable from siblings like skip_year_end_step, undo_year_end_step and create_proposal by scope, though it never names those alternatives.

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?

Clear conditional routing: action='book' when a proposal exists (the code posts the balanced voucher, LLM only picks the step), action='manual' when the user supplies their own journal. This tells an agent exactly which branch to take, but stops short of naming sibling tools (undo/skip) or stating prerequisites like checklist state.

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 bar is low; the description adds real value by specifying the calculation content (skatt + arbetsgivaravgift) and the non-posting behavior that matches readOnlyHint. It does not describe output format or the effect on subsequent run_payroll, keeping it below 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?

Front-loaded with purpose before the dense argument list, and every clause (types, formats, enum values, sign conventions) earns its place given the sparse schema. The parameter enumeration is run-on but justified by the low schema coverage.

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 6-param, low-schema-coverage tool with no output schema, the description is thorough on inputs and behavior. It stops short of explaining return values or how the result feeds run_payroll, which is the main remaining gap.

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

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

With only 17% schema coverage, the description carries the load and does so well: it documents orgnr, year, month, pay_date (YYYY-MM-DD format), and the full nested entries shape (employee_id, gross_cash_ore, benefit_ore, extra_tax_ore, components). It uniquely supplies the kind enum (LON|SEMESTER|OVERTID|...) absent from the schema and explains extra_tax_ore sign semantics (+extra skatt / −jämkning).

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 ('Förhandsberäkna en lönekörning') and the exact scope (skatt + arbetsgivaravgift), and the crucial negation 'UTAN att bokföra' separates it from the booking sibling run_payroll. An agent can distinguish this preview-calculation tool from run_payroll without opening either schema.

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

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

'UTAN att bokföra' clearly signals the preview-only context (use this to compute, not to post), which distinguishes it from run_payroll. However, no alternative sibling is named explicitly and there is no explicit when/when-not statement, so 4 rather than 5.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=true, so the safety profile is covered. The description adds real value beyond them by disclosing the precondition (invoice must be unpaid) and the actual effect (the bokföringsverifikat is reversed), which the annotations do not convey.

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

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

Very tight and front-loaded: the action and its effect come first, scope second. The trailing 'Argument: orgnr, invoice_id' is redundant with the schema's required fields and is the only wasted fragment.

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

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

For a destructive, idempotent mutation with no output schema and annotations covering safety, the description supplies the two things an agent actually needs: the precondition and the accounting consequence. Nothing critical 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 coverage is 50%: orgnr is fully documented in the schema including a hint to use list_companies, while invoice_id has no schema description at all. The description only restates 'Argument: orgnr, invoice_id' without adding format, lookup, or type meaning, so it does not compensate for the undocumented 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?

States a specific verb and resource ('Makulera en kundfaktura') and adds the behavioral distinguishing detail that it applies to unpaid invoices and reverses the accounting voucher, which separates it in spirit from credit_customer_invoice. It never names a sibling explicitly, so it stops short of the top band.

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 parenthetical 'obetald' gives an implied precondition and 'Scope book' hints at the operating scope, so an agent can infer when this applies. However, there is no explicit when-to-use versus credit_customer_invoice or cancel_supplier_invoice, and no stated exclusions for paid invoices.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds value the annotations cannot: that the reversal posting is performed by the code itself when the invoice was already booked, plus the required auth scope (book). That is meaningful side-effect and permission disclosure.

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, front-loaded clauses; the core action leads and the prerequisite trails. The 'KODEN postar återföringen' emphasis is a little cryptic in phrasing but carries real information, so there is little waste.

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 2-parameter mutation tool with no output schema and full annotation coverage, the description supplies the pieces an agent still needs: the reversal semantics, the auth scope, and the argument set. Return values need not be described. Minor gap: it does not clarify preconditions such as payment status.

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

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

Schema description coverage is 50% – orgnr is well documented in the schema, but invoice_id has no description anywhere. The description merely restates the argument names ('Argument: orgnr, invoice_id') and adds no format, range, or lookup guidance, so it fails to compensate for the undocumented invoice_id.

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 ('Makulera en leverantörsfaktura') and immediately scopes the behavior to reversing an existing booking, which cleanly separates it from sibling cancel_customer_invoice and the various reverse_* tools. It does not name a sibling explicitly, 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?

Gives a conditional trigger ('återför bokföringen om den redan bokförts') and a hard prerequisite ('Kräver scope book'), which is real usage context. However, it never says when to prefer this over alternatives such as reverse_supplier_payment or reverse_voucher, so the routing guidance is only implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, but the description adds real context beyond them: 'Sparar inget' confirms nothing is persisted, 'Kräver behörigheten statutory' discloses an authorization prerequisite, and it sketches the return contents (INK2 underlag and INK2R). No behavioral gaps of consequence remain.

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 core purpose, then the alternative-tool routing, then the default and return/auth notes. Dense but every clause carries information; slightly long, with a few parenthetical examples that could be trimmed.

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?

Despite having no output schema, the description covers return values, persistence, required permission, the alternative tool, and the default invocation semantics — everything an agent needs to call this five-parameter computation 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?

With 100% schema description coverage the baseline is 3, but the description adds meaning the schema does not: it explains that omitting the optional adjustment parameters falls back to computing on the bokslut as-is, and characterizes user_inputs/balance_sheet/income_statement as the årsredovisningsguide adjustment mechanism.

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?

Specific verb and resource ('Räknar fram bolagets skatt och INK2') plus a precise scope qualifier: it computes tax *with* the adjustments from the årsredovisningsguide. It names the sibling it is not (read_tax) so an agent can route between them without opening either schema.

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

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

Explicit when-to-use ('Använd för att pröva hur justeringar påverkar skatten'), explicit when-not and the alternative ('för skatteberäkningen härledd direkt ur bokslutet utan justeringar, använd read_tax'), and a default-case rule ('Utan något annat argument än orgnr räknas skatten på bokslutet som det är'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so safety is covered structurally. The description goes beyond that by disclosing the chart-of-accounts seeding side effect and concrete validation constraints on the first fiscal year (max 18 months, end must be the last day of the end month, omission yields nearest year-end), which is genuinely useful behavioral context.

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

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

Front-loaded with purpose and side effect, then the argument list; every clause carries information (enums, month mapping, date rules) rather than filler. The single long argument sentence is dense but not 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 9-parameter creation tool with no output schema and thin structured coverage, the description covers purpose, side effect, parameter meaning and key constraints. It omits behavior on duplicate orgnr, error conditions, and what the caller gets back, which are minor given the tool's scope.

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 11%, so the description must compensate and largely does: it enumerates vat_period values (manad|kvartal|ar), accounting_method values (faktura|kontant), decodes fiscal_year_end_month numerically (12=jan-dec, 11=dec-nov), and explains first_fy_start/first_fy_end with an example and constraints. It leaves name, city and fiscal_year itself unexplained, so it stops short of full compensation.

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 ('Lägg till ett bolag i koncernen') and immediately discloses a consequential side effect ('seedar BAS-kontoplanen') and the scope ('Scope book'). An agent can distinguish this from get_company, update_company, search_company and list_companies without opening the schema.

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

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

The purpose makes the usage context inferable (onboard a new group company), but there is no explicit when-to-use/when-not statement, no mention of prerequisites, and no pointer to alternatives such as update_company for later edits. Usage is implied rather than guided.

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

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

With annotations already declaring readOnlyHint=false and destructiveHint=false, the description adds important behavioral context: the invoice is created as a draft, is not booked until booked, and how VAT is posted to rate-specific accounts. It does not cover permissions or idempotency in detail, but the draft/booking distinction is valuable beyond the annotations.

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

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

The description is long and dense, but front-loads the core draft/creation purpose and then organizes the remaining detail by topic. For a 25-parameter tool it earns most of its length, though the prose could be slightly more scannable.

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

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

Given 25 parameters, low schema description coverage, and no output schema, the description is unusually complete: it covers creation semantics, key parameter behavior, ROT/RUT handling, and even relevant output fields for husarbete. It is not exhaustively detailed for every simple parameter, but it provides enough context to invoke 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 only 4%, so the description must carry parameter meaning, and it does: it describes the lines array shape, milli-units (×1000), account fallback rules, VAT account mapping, and the husarbete object structure. It also lists all argument names and explains critical optional fields, adding substantial semantics beyond the sparse schema.

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

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

The description states a specific verb and resource: 'Skapa en kundfaktura', and clarifies it is a draft that is not booked until booked. It also distinguishes the tool from update_customer_invoice and hints at book_customer_invoice, so an agent can tell it apart from sibling invoice tools.

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

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

It clearly establishes the creation context and notes that later changes go through update_customer_invoice. It implies the booking step is separate but does not explicitly state when-not to use this tool versus alternatives such as create_supplier_invoice or credit_customer_invoice.

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, idempotentHint=false and destructiveHint=false, and the description goes further by disclosing the required 'book' authorization and the side effect of book_acquisition=true (D tillgångskonto / K funding_account, default 1930). It still does not say what happens on duplicate registration or what the call returns, which keeps it below 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?

Purpose and the two key constraints are front-loaded before the parameter list, and there is no filler. The long semicolon-delimited argument block is dense but each clause carries information; minor cost in readability only.

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 16-parameter, 8-required mutation with no output schema and near-zero schema documentation, the description covers purpose, permission, validation constraint, posting behavior and every parameter. Only the response/idempotency behavior is left implicit, which annotations partly cover.

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 6%, so the description carries the load — and it does, enumerating all 16 arguments, giving account roles (gl_account = tillgångskonto, funding_account default 1930), date formats (YYYY-MM-DD for acquired and depreciation_start), asset_type values (EQUIPMENT|BUILDING|LAND|OTHER, which the schema does not enumerate), and the import meaning of opening_accumulated_ore.

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 ('Registrera en anläggningstillgång') plus the accounting regime it applies (K2, linjär helavskrivning), which lets an agent distinguish it from update_fixed_asset, dispose_fixed_asset and list_fixed_assets. It does not name those siblings explicitly, 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?

Provides real prerequisites — the 'book' permission requirement and the rule that useful_life_months ≥ 1 except for LAND — but never states when to choose this over update_fixed_asset or how it relates to a later post_depreciation. Usage context is implied rather than explicitly routed.

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 substantial context beyond annotations: proposed_journal must balance (debit=credit in öre, min two rows) and basis must contain a source id or the proposal is rejected; it returns proposal_id/status; nothing is booked (side effect); and it requires the 'reconcile' permission. Annotations only carry the generic readOnly/destructive/idempotent flags, so this is real added value.

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

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

Front-loaded with purpose, then usage/alternative, then validation constraints, return values, side effects, and required permission. Every sentence carries distinct information with 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?

No output schema exists, but the description states return values (proposal_id, status) and core side effects and permission requirements. Given the 11-param tool with 9% schema coverage, more per-parameter guidance would help, but the task-critical behavioral 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?

Schema coverage is only 9%, so the description must carry the burden. It meaningfully explains proposed_journal (balance rule, min two rows, öre unit) and basis (source id required) and references finding_ref, but leaves many required params (year, month, account, bilaga_type, reasoning) and optional ones (model, confidence) undifferentiated. Partial compensation only.

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+scope: proposes an adjusting entry (justerande post) for a reconciliation/bilaga on a given account and month. It explicitly names the sibling it is not (propose_voucher) so an agent can distinguish the two without opening schemas.

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 when ('when a reconciliation shows a discrepancy that needs correcting') and an explicit when-not with the alternative named ('for a regular voucher a human should approve, use propose_voucher'). Routing is fully determined.

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 write, and the description adds genuinely non-obvious behavior: one ärende is created per buyer and nothing is actually transmitted to Skatteverket (the file must be exported and submitted by the user). This corrects a likely agent misassumption and stays consistent with openWorldHint=false, adding value beyond the annotations.

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

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

Dense but front-loaded: the core action, constraints, side effects and follow-up are stated in order with no filler. It is on the longer side and packs several ideas per sentence, but every clause carries actionable 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 mutation with no output schema and a multi-step tax workflow, it covers purpose, constraints, side effects and the required next-step tool well enough to invoke correctly. Only minor gaps remain, such as auth/prerequisite state and the concrete invoice_ids format.

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

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

Schema description coverage is only 25%, so the description must compensate. It enumerates the arguments, supplies the ROT|RUT value set for type (which the schema lacks entirely, 0 enums), caps name at 16 characters, and constrains invoice_ids via the same-year/all-paid/max-100-buyers rules; only invoice_ids' concrete format remains 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?

States a specific verb and resource: creates a Skatteverket ROT/RUT payout request for paid invoices. It clearly distinguishes itself from siblings such as list_rot_rut, get_rot_rut_request_file, mark_rot_rut_request_submitted and delete_rot_rut_request by naming the actual action and the follow-up file step.

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

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

Gives concrete usage conditions: only for paid invoices, ROT and RUT requested separately, all invoices paid the same year, max 100 buyers per request, and points to list_rot_rut (att_begara) as the prerequisite selector. It also routes the agent to get_rot_rut_request_file for the next step, though it does not spell out explicit when-not conditions against the mark/delete 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?

Goes well beyond the annotations: it discloses that nothing is booked yet, that non-SEK amounts are converted to SEK while the original amount and rate are stored, that the agent must never guess an FX rate, and that elicitation-capable clients get the rate question inline while others receive an error carrying the question. That is rich side-effect and failure-mode disclosure.

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

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

The purpose and the not-booked caveat are correctly front-loaded, but the block is dense and ends with a bare re-listing of every argument that duplicates the schema. Capitalized emphasis and the packed currency paragraph cost readability.

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 16-parameter mutation tool with no output schema and near-zero schema documentation, the description covers modes, currency conversion, booking lifecycle, document linkage, and elicitation fallback. It does not address duplicate handling or error conditions for malformed lines, which leaves a small gap.

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

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

Schema description coverage is only 6%, so the description must compensate, and it largely does: it defines the lines element shape {account, net_ore, vat_rate, description}, explains that VAT is computed per line and the total derived from lines + rounding_ore, and gives the semantics of currency/fx_rate/total_sek_ore. The leftover gaps are the unexplained fields (ocr, due_date, supplier_id), which appear only in the trailing argument list.

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 (registrera en leverantörsfaktura) and immediately scopes it against the sibling book_supplier_invoice by noting it is not booked until then. An agent can distinguish this from create_voucher, book_supplier_invoice, and update_supplier_invoice without opening the schema.

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

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

Explicitly says when the invoice becomes a ledger event (only via book_supplier_invoice), offers two mutually exclusive input modes (line mode vs single-line total_ore+vat_ore+expense_account), and routes to list_available_underlag for document_id. Non-SEK handling is spelled out with a when-to-use branch.

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

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

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds substantial context beyond them: the exact return payload (URL, expiry, max size), the required permission ('upload'), and the crucial side effect that nothing is persisted until the PUT, after which a document_id exists that can be linked via attach_underlag.

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

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

Front-loaded with purpose, then routing guidance, return shape, side effect, and permission requirement. Every sentence carries distinct information; 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?

With no output schema and only three simple parameters, the description supplies the missing pieces an agent needs: the asynchronous two-step workflow, the return values, the permission prerequisite, and the downstream attach_underlag link.

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 name, orgnr and content_type are already documented in the schema with examples. The description adds no field-level syntax or format detail beyond that, 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?

States a specific verb and resource ('Skapar en kortlivad uppladdningslänk för en stor fil') plus the reason (avoid base64 through the model) and a concrete example. It clearly distinguishes itself from add_voucher_underlag and upload_underlag by naming both as the small-file path.

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

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

Explicit when-to-use ('Använd när filen är för stor för ett vanligt verktygsanrop') and when-not ('små filer laddas upp direkt med add_voucher_underlag ... eller upload_underlag'), with named alternatives and their targets. Nothing is left to inference.

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

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

Goes well beyond the annotations: it discloses the side effect that the voucher is posted immediately, the validation constraints (sum must be 0, at least two rows, booking ceiling must not be exceeded), the required 'book' permission, and non-obvious FX handling rules (never guess the rate, ask the user). Annotations only supply the generic write/non-idempotent profile, so this added context is genuinely valuable.

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

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

Front-loads purpose, usage, and sibling routing before the denser validation and FX paragraphs, which is the right order. The FX guidance is long, but every sentence carries non-recoverable domain information, so it is dense 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 complex financial mutation with 11 parameters, no enum constraints, and no output schema, the description supplies validation rules, permission requirements, FX workflow, and even the return shape (id, serie, nummer). An agent has what it needs to call this correctly without external documentation.

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 9% (just orgnr), so the description has to compensate, and it does for the hard parts: the debet/kredit sign convention for rows, the role of document_ids/underlag_ids, and the currency/foreign_amount_minor/fx_rate/total_sek_ore interplay. It leaves date, text, and series semantics unexplained, so it is helpful but not complete across all 11 parameters.

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 ('Bokför ett verifikat i huvudboken') plus the amount-sign convention (debet positivt, kredit negativt) that defines its behavior. It explicitly distinguishes itself from book_voucher and propose_voucher, so an agent can place it against siblings without opening any schema.

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

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

Gives concrete when-to-use cases (fristående bokningar, skatteberäkningens poster after approval, kvitton/fakturor linked via document_ids or underlag_ids) and explicit when-not routing ('använd book_voucher' for basis references, 'propose_voucher' if a human must review first). The selection logic between the three siblings is handed to the agent directly.

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 it is a non-read-only, non-destructive, non-idempotent write. The description adds genuine context beyond that: the result is a draft (utkast), amounts are negative, accounting is reversed at booking time, and the required scope is "reconcile". These are non-obvious behavioral traits the annotations cannot express.

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?

Dense but front-loaded: the core action leads, followed by behavioral note, lines behavior, scope, and argument list. Every clause carries information, though the argument enumeration at the end partially duplicates the schema.

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

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

For a mutation tool with no output schema and sparse schema descriptions, the description covers the important ground: draft state, sign convention, booking reversal, scope, and the lines structure for partial crediting. Minor gaps remain around invoice_id/invoice_date semantics and any permission prerequisites.

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 20% (only orgnr is documented), so the description must carry the load, and it does: it enumerates the arguments (orgnr, invoice_id, invoice_number required; invoice_date, lines optional) and spells out the lines item shape ({description, quantity_milli?, unit_price_ore, vat_rate, account?}). The remaining gap is that invoice_id vs invoice_number semantics are not distinguished.

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 ("Skapa en kreditfaktura för en kundfaktura") that clearly separates it from siblings like create_customer_invoice, cancel_customer_invoice, and book_customer_invoice. The parenthetical adds scope (draft, negative amounts, reversed posting) so the agent knows exactly what operation this is.

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

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

The description explains that omitting lines credits the whole original while supplying lines performs partial crediting, which is useful usage guidance. However, it never states when to choose this tool over alternatives such as cancel_customer_invoice or reverse_customer_payment, so routing is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely new behavioral detail the annotations cannot carry: which invoice states are excluded (ej bokförda, makulerade, betalda) and the sort order. The closing 'Läser bara, ändrar inget' is redundant with the annotations but not harmful.

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 dense sentences: purpose, routing, exclusions/return shape. Front-loaded with the core purpose and no filler, though the final read-only sentence is redundant padding given the 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?

There is no output schema, and the description compensates by enumerating the returned fields (namn, utestående och förfallet belopp i öre, antal fakturor), the ordering, and the total. Combined with the exclusions, an agent knows both what it gets and what is omitted.

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 a single parameter at 100% schema coverage, the schema already documents orgnr format and where to obtain it (list_companies). The description adds no parameter-level 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?

States a specific verb+resource ('Visar utestående kundfordringar per kund') and immediately narrows scope with what is measured (obetalt vs förfallet). It explicitly distinguishes itself from the sibling list_customer_invoices, so an agent can separate the two without opening either schema.

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

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

Gives an explicit when-to-use ('Använd för frågor som vilka kunder som är skyldiga bolaget pengar') and names the alternative for the adjacent case ('för fakturorna i detalj, använd list_customer_invoices'). Nothing is left for the agent to infer about routing.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description goes further: irreversibility ('kan inte återställas'), the specific business rule blocking deletion (documents tied to invoices or inbox items return an error), the required permission (manage_documents), and the response shape (ok: 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?

Front-loads the destructive action and trigger condition, then layers in alternatives, error rule, and permission. Every sentence carries actionable content, though the description is on the longer side for a single-parameter tool.

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

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

For a destructive mutation with annotations but no output schema, the description covers trigger, alternatives, reversibility, failure conditions, permissions, and the return value. Nothing an agent needs to invoke it correctly 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?

Only one parameter and schema coverage is 100%; the schema already documents doc_id type, example value, and the list_documents retrieval hint. The description repeats that hint rather than adding new syntax or format detail, 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 verb and resource ('Raderar ett dokument ur bolagets dokumentarkiv permanent') and immediately distinguishes itself from siblings by naming edit_document and list_documents. An agent can identify the tool's scope without opening the schema.

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

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

Explicit trigger condition ('Använd bara när användaren uttryckligen vill ta bort dokumentet'), named alternatives for the non-delete cases ('använd edit_document'), and a prerequisite ('hitta doc_id med list_documents'). Exclusions are also spelled out.

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 supply generic destructiveHint/idempotentHint flags; the description adds the substance behind them — that the default path destroys nothing but actively preserves history, that hard=true is a true erase, and that a precondition (no payroll runs) gates it. It also names the required auth scope (payroll). This is exactly the extra context annotations cannot convey.

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

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

Four short sentences, front-loaded with the core soft/hard distinction and the constraint before the trailing argument list. The final 'Argument: orgnr, employee_id; valfritt hard' clause is largely redundant with the schema, costing it a point.

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

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

For a mutation tool with no output schema, the description covers purpose, the two behavior modes, the gating precondition, and auth scope. It leaves open what a blocked hard delete actually returns (error vs. silent fallback to soft) and whether a confirmation payload exists.

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 33% (hard has no description, employee_id has none). The description compensates for the most important gap by defining what hard toggles — false/absent = deactivate, true = permanent delete with a guard. It does not explain employee_id format, but the one semantically ambiguous parameter is fully covered.

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 (delete/deactivate an employee) and goes further by naming the two operating modes, soft (utan hard) and hard. It is unmistakable what the tool does, though it never references a sibling tool to differentiate itself (upsert_employee, list_employees) — not that a direct alternative really exists for deletion.

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 real conditional rule: omit hard to deactivate while preserving history, set hard=true to fully delete but only when the employee has no payroll runs. This is clear when-to-use guidance. It falls short of a 5 only because it names no alternative tool or fallback path when hard deletion is blocked.

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

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

Annotations declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so safety is covered. The description adds the permission requirement ('book'), which is valuable behavioral context not present in annotations. However, it doesn't specify whether deletion is permanent or what happens to related records, leaving some transparency gaps.

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

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

Two concise sentences, front-loaded with purpose, then permission, then argument list. No redundancy or 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 destructive, idempotent mutation tool with no output schema, the description covers the core action and permission but lacks details on permanence, side effects, and how to obtain asset_id. It's minimally complete but misses contextual richness that would help an agent 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?

Schema coverage is 50%; orgnr has a full schema description, but asset_id does not. The description lists the parameters but adds no meaning beyond the names. Baseline 3 is appropriate given partial schema coverage and no additional parameter context.

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: 'Ta bort en anläggningstillgång ur registret' (remove a fixed asset from the register). Distinguishes itself from create_fixed_asset, update_fixed_asset, dispose_fixed_asset, and get_fixed_asset by naming the exact operation.

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

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

The description implies usage through the permission requirement ('Kräver behörigheten book') but does not explicitly say when to use this tool versus dispose_fixed_asset, which is a close sibling with different semantics. No exclusions or prerequisites beyond the permission are stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true. The description adds real behavioral value beyond them: the precondition that makes deletion legal (no payout registered) and the downstream consequence that the invoices become selectable for a new request. It does not state the failure mode when a payout exists or whether the deletion is reversible.

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

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

Three short sentences with the purpose and precondition front-loaded; nothing is buried. The trailing 'Argument: orgnr, request_id' restates what the schema already shows and is the one mildly wasteful element.

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

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

For a destructive, no-output-schema tool whose annotations cover the safety profile, the description supplies the key missing pieces: eligibility condition and post-deletion effect. It stops short of describing error behavior when the precondition fails, which an agent would need to handle gracefully.

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%: orgnr is well documented with a format example and a pointer to list_companies, but request_id has no description at all. The description merely lists 'Argument: orgnr, request_id', adding no format, source, or meaning beyond the schema, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Ta bort en ROT/RUT-begäran') plus the eligibility condition that separates it from siblings like register_rot_rut_payout or reverse_rot_rut_payout. It does not name those siblings explicitly, so the differentiation is implicit rather than spelled out.

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

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

Gives an explicit precondition: the request must have no registered payout, which is the condition that selects this tool over the payout/reversal tools. It does not say what to do when a payout does exist (e.g. reverse first), so the routing guidance is incomplete but clear context is present.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety profile is covered. The description adds the meaningful business constraint that only entries outside a booked payroll run are deletable, which is behavioral context the annotations do not convey. It does not describe error behavior or return content.

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, action front-loaded, no filler. The trailing "Argument: orgnr, entry_id" is redundant with the required-parameters list, but the whole thing stays tight.

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?

A destructive, non-read-only mutation with no output schema should ideally say what is returned or what happens on success/failure. It covers the deletion precondition but leaves the post-condition and the undocumented entry_id unexplained, making it only minimally adequate.

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%: orgnr is well documented in the schema with format and a sourcing hint, but entry_id has no description anywhere, and the description merely re-lists both argument names without adding semantics. With a bare required integer parameter, the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ("Ta bort en tidpost" = delete a time entry) and adds a qualifying precondition (entries not part of a booked payroll run), which distinguishes it from list_time_entries/review_time_entries and other delete_* tools. Clear enough for selection, though it doesn't name a sibling alternative.

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 clause "som inte ingår i en bokförd lönekörning" gives an explicit eligibility condition for when deletion is allowed, which is real usage guidance. It stops short of naming what to do when the entry IS in a booked run (no alternative tool cited).

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

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

Beyond the annotations (readOnly false, destructive false, non-idempotent), the description discloses the side effects (writes off acquisition value and accumulated depreciation, computes gain/loss, the asset stops depreciating), the auth requirement ('book' permission), and the book=false escape hatch that registers the disposal without creating a voucher. That is substantial behavioral context the schema does not carry.

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

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

Purpose is front-loaded, then prerequisites, then the argument list — appropriate ordering. It is a dense, run-on string, and the argument enumeration is list-like, but for a 9-parameter accounting tool nearly every clause earns its place.

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

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

For a complex, non-idempotent mutation with 11% schema coverage and no output schema, the description covers purpose, side effects, mandatory ordering, required permission, and all parameter meanings/defaults. Nothing an agent needs to call it correctly 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 coverage is only 11%, so the description must compensate and it does: it enumerates every argument, gives the date format (YYYY-MM-DD), explains proceeds_ore semantics (0 = retirement), and assigns the roles/defaults of proceeds_account (1930), gain_account (3973), loss_account (7973) and book (true, false = register without voucher). Most parameters gain meaning not present in the schema.

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

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

The description names a specific verb+resource ('Sälj eller utrangera en anläggningstillgång') and defines the accounting action precisely: writing off acquisition value and accumulated depreciation and reporting gain/loss against book value. This is unmistakably an accounting disposal, clearly distinguishable from the nearby delete_fixed_asset / update_fixed_asset 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?

It gives a real workflow condition: book depreciation up to and including the disposal month FIRST to get the correct result, and it states the required 'book' permission. It does not explicitly contrast with delete_fixed_asset or spell out when-not to use it, so it stops short of the 5 tier.

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

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing a hard precondition (postcode and city must be known, otherwise an error naming the missing fields), the return payload shape, the ISO 8859-1 encoding Skatteverket requires, and that the tax follows previously saved choices. 'Sparar och skickar inget' also reinforces the read-only annotation.

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 its output, then routing, prerequisite, return format, and non-effects. Six short sentences each carry distinct information, though the tax/encoding asides edge slightly toward over-coverage for a single tool.

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

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

For a no-output-schema tool, the description explains the returned content (file text plus applicable year) and the encoding needed to use it. Combined with the explicit error behavior, an agent has everything required to call it and handle failures 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 100%: both 'year' (with its end-of-fiscal-year convention and default) and 'orgnr' (format and how to obtain it via list_companies) are fully documented in the schema. The description adds the postcode/postort precondition, which is a data requirement rather than a parameter, 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: produces INK2 as SRU files (INFO.SRU/BLANKETTER.SRU) for a fiscal year, populated from the year-end accounts. It explicitly names the sibling it is not (read_tax) so an agent can distinguish them without opening either schema.

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

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

Gives an explicit when ('Använd när användaren själv ska lämna in inkomstdeklarationen hos Skatteverket') and an explicit alternative with its own condition ('för själva skatteberäkningen, använd read_tax'). Nothing is left to inference.

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

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

Goes well beyond the annotations: it discloses the destructive-replacement semantics ('det sparade utkastet ersätts med payload'), a non-obvious partial-retention rule (INK2 postnummer/postort retained from the previous draft), the return ('ok och när utkastet sparades') and an auth requirement ('Kräver behörigheten statutory'). These are exactly the behaviors an agent must know before calling a whole-document overwrite.

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?

Everything is front-loaded — save scope first, usage rule second, return/side effects/permission after — and each clause carries distinct information. It is dense as a single paragraph, but there is little that could be cut without losing a decision-relevant fact.

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

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

No output schema exists, yet the description covers the return value ('ok och när utkastet sparades'), the overwrite/replacement behavior, the partial-retention exception, the required permission, and the companion read/write siblings. Nothing an agent needs to invoke this correctly 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 coverage is 100% so the baseline is 3; the description adds real meaning on top by clarifying that payload is the entire draft (not a patch) written as a full replacement, and that only the INK2 address fields survive from the prior draft. It does not add formatting detail beyond the schema, so it stops short of 5.

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

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

Specific verb+resource+scope: 'Sparar hela utkastet till årsredovisningen för ett räkenskapsår' (saves the whole annual report draft for a fiscal year), and it enumerates the contents (resultat- och balansräkning, noter, förvaltningsberättelse, undertecknare). It explicitly distinguishes itself from siblings read_annual_report_draft and set_arsredovisning_inputs, so an agent can route without opening any schema.

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

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

Gives an explicit when: 'Använd bara när du har hela utkastet'. Gives an explicit when-not plus the alternative: 'för att ändra enstaka uppgifter, använd set_arsredovisning_inputs, som skriver en delmängd och returnerar vad som återstår'. The selection rule is fully spelled out.

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, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: PATCH-style semantics ('Bara angivna fält ändras'), the required OAuth scope (manage_documents), and the explicit limitation that visibility/sharing fields are out of reach for this tool.

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

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

Front-loaded with the action and the partial-update rule, followed by the non-editable fields and scope. The trailing 'Argument:' list is somewhat redundant formatting, but with 0% schema coverage it earns its place by restating required vs optional fields.

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 4-parameter mutation tool with annotations covering safety and no output schema, the description covers purpose, partial-update semantics, scope, and an important non-capability. Minor omissions remain (behavior on unknown doc_id, whether an empty companies list clears links), but nothing essential to a correct call 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 coverage is 0%, so the description must carry the burden, and it names all four parameters while adding meaning the schema lacks: doc_id is required, name/category/companies are optional, and companies takes a list of organisation numbers. It does not constrain the category value space or name length, so it compensates well but not completely.

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 (edit a document's metadata) and immediately scopes it to name, category and linked companies, which separates it from delete_document, list_documents and upload_underlag. It also pre-empts a likely mistake by stating that visibility/LLM-sharing are NOT editable here, which no sibling could clarify.

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

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

Gives explicit context: use this for metadata edits, and 'Synlighet och LLM-delning ... sätts bara i Kvickd-appen, inte via MCP' tells the agent when this tool cannot be used. It stops short of naming a sibling alternative (e.g. delete_document) for adjacent operations, so it is strong context rather than full when/when-not routing.

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

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

Annotations already disclose the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds two genuinely new facts beyond them: the 'reconcile' permission requirement and the state precondition that only pending drafts can be edited before approval. It still omits whether omitted arguments leave existing values intact or clear them – the key behavioral question for an idempotent edit.

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

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

Front-loads purpose, then permission, then argument list – a sensible order with no filler. Dense but every clause carries information; the argument enumeration is compact 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 7-parameter mutation tool with no output schema and sparse annotations, the definition supplies the essentials: purpose, permission gate, editable state, and parameter shapes. It falls short on partial-vs-full update semantics and any note about the result of the edit, but the core 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 description coverage is only 14% (just orgnr), so the description carries most of the burden. It names all arguments, gives a date format (YYYY-MM-DD) and, importantly, expands the otherwise-empty 'lines' array into [{account, debit_ore, credit_ore, text?}] – a real add over the schema. series, text and note are still named without explaining their effect.

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 a specific verb and resource (Ändra ett verifikatförslag / edit voucher draft) plus a scope constraint (väntande, innan det godkänns – pending, before approval) that cleanly separates it from approve_voucher_draft, reject_voucher_draft and book_voucher. It does not name a sibling explicitly, but the 'pending, pre-approval' scope makes the distinction inferable.

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?

States a precondition (requires the 'reconcile' permission) and an implicit usage window (only pending drafts, before approval). It gives no explicit guidance on when to pick this over siblings such as create_voucher or list_voucher_drafts, and no exclusions, so usage is only implied.

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

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, so the safety profile is covered. The description adds genuinely useful behavior the annotations lack: the return is a base64-encoded file (content_base64 + filename + media_type), and which date parameters each report kind consumes. It stops short of any error/permission or size-limit context.

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

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

Front-loaded with purpose, then usage, then parameter rules, then return shape — a sensible order with little filler. Minor dings for the garbled phrase ('kvickds riktiga') and the cryptic fragment 'Scope view' that costs clarity without earning its place.

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

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

With no output schema, the description properly discloses the base64/filename/media_type return shape, and it covers the required parameters and report-kind semantics. Remaining gaps are the opaque 'Scope view' note and any prerequisite about how orgnr is obtained beyond the schema's own hint.

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 17% (orgnr alone), so the description must carry the load and does: it enumerates the six kind values, specifies the accepted format values (pdf/xlsx), and maps start+end vs balansdag to specific kinds with the YYYY-MM-DD convention. This is exactly the compensation expected for a low-coverage, no-enum 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 (generera) and resource (rapport som fil i pdf/xlsx), and distinguishes the tool from siblings like get_balance_sheet/get_income_statement by emphasizing it returns a downloadable/shareable file rather than data. The explicit 'instead of building your own PDF' line further separates it from any do-it-yourself path.

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 clear when-to-use directive ('Använd det här i stället för att bygga en egen PDF') and routes date semantics per report kind. However it never explicitly excludes sibling report/data tools (get_trial_balance, get_vat_return, generate_ixbrl), leaving the agent to infer when a file export beats a data call.

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

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

Goes well beyond the annotations by disclosing the return format (XHTML as text), the absence of side effects ('Sparar och skickar inget'), that submission is the user's responsibility, and the required 'statutory' permission. These are exactly the behavioral facts annotations cannot convey for a generation tool.

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

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

Dense but front-loaded: purpose first, then when-to-use, then parameter provenance, return format, side effects, and permission. Every sentence earns its place and none is redundant with the structured fields.

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

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

For a complex generation tool with a nested object parameter and no output schema, the description supplies the missing return format, prerequisites, permission requirement, and side-effect profile. 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it instructs the agent to send all data in user_inputs (e.g. payload.user_inputs from read_annual_report_draft) and warns that the stored draft is not auto-populated. That nuance is not derivable from the schema text alone.

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

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

States a specific verb (genererar) and resource (årsredovisningen K2 as an iXBRL file for Bolagsverket), and grounds it in the annual report guide's data. This clearly distinguishes it from sibling readers like read_annual_report and read_annual_report_draft.

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

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

Explicitly names the trigger condition (get_arsredovisning_status shows everything ready) and the alternative/error path (incomplete data yields an error naming what is missing). It names the sibling to consult and the source of inputs, leaving nothing to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the mutation/safety profile is covered. The description adds real behavioural context beyond that: a document is created in the archive under the category Leverantörsfaktura, it becomes visible via list_documents/list_policies, and it is readable/downloadable. It does not clarify idempotency semantics on repeat calls, which the annotation asserts but the description leaves unexplained.

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 dense sentence-complex with the primary action front-loaded, followed by destination, discoverability and scope notes in descending importance. Every clause carries information; the trailing "Argument: orgnr, invoice_id" is the only piece that does not earn its place.

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

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

For a side-effect tool with no output schema, the description does enough: it says what artifact is produced, where it is stored, how it can be found afterwards, and what scope is expected. The main missing piece is any statement about the return value or about what happens if the same invoice_id is generated twice despite idempotentHint=true.

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%: orgnr is well documented in the schema (format, example, how to find it via list_companies) while invoice_id has no description at all. The description only restates the parameter names ("Argument: orgnr, invoice_id") and therefore adds nothing, leaving the undocumented invoice_id uncompensated. Baseline 3 is appropriate at this coverage level.

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

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

The description names a specific verb and resource ("Generera en leverantörsfaktura som PDF") and states the destination ("spara den i dokumentarkivet"). It also indirectly separates itself from the listing siblings by naming list_documents/list_policies as the place the result appears. It does not explicitly contrast with create_supplier_invoice or get_supplier_invoice, so it stops short of full sibling differentiation.

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

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

There is an implicit trigger (when you need a PDF of an existing supplier invoice) and a directive about the resulting document's scope ("scope upload (inte view)"), which is useful operational guidance. However, there is no explicit when-to-use/when-not statement and no named alternative (e.g. versus create_supplier_invoice or get_supplier_invoice), so usage is only implied.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructively-inert behavior, so safety is covered. The description adds substantial value beyond that: the return shape (per section plus flat list, blocking items first), the meaning of the returned fields (kind=question, kind=toggle, suggested_value, complete), the Nej/Ja toggle semantics including toggle_field/confirm_field, and the whole-kronor constraint. It does not cover auth or pagination, 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?

It is front-loaded with the purpose, but a large fraction of the text is a workflow protocol for a different tool (set_arsredovisning_inputs) rather than what this status call does or returns. The per-section enumeration and toggle mechanics are useful, yet the block is long and mixes read semantics with downstream write instructions.

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

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

There is no output schema, so the description must explain the return payload, and it does: section grouping, flat list, blocking-first ordering, complete flag, and the kind/suggested_value fields an agent will act on. Combined with the 2-parameter schema it is largely sufficient, with the year-parameter ambiguity the main remaining hole.

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

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

Schema description coverage is 50%: orgnr is documented in the schema (10 digits, optional hyphen, sourced from list_companies) while year carries no schema description. The description only adds "Argument: orgnr, year", doing nothing to disambiguate whether year is a calendar year, fiscal year, or a fiscal-year id, which is the one real ambiguity here. Baseline 3 for partial schema coverage.

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

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

The description names a specific verb and resource: it returns the open items ("öppna poster") for the annual report and exactly what remains before iXBRL generation, structured per section plus a flat blocking-first list. That is far more precise than a tautology. It does not name or contrast itself against close siblings like read_annual_report_draft, read_statutory_status or get_year_end_checklist, so an agent must infer the boundary.

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

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

It gives an explicit operating procedure: iterate items with the user as "approve or change", item by item, wait for confirmation before writing via set_arsredovisning_inputs, propose where suggested_value exists and ask where kind=question. It also states the termination condition (generation is released only when complete==true). When-to-use and the handoff to alternatives are fully spelled out.

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 closed-world, so the safety profile is covered; the closing 'Läser bara, ändrar inget' is largely redundant with readOnlyHint. The description does add real behavioral value beyond the annotations by disclosing the return contents (subtotals, calculated result, balance check) and that amounts are in öre, which matters because there is no output schema.

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

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

A single dense paragraph that is front-loaded with purpose, then routing, then return contents, then safety. Every clause is relevant, though the final read-only sentence repeats what the annotations already say and could be trimmed.

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

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

With no output schema, the description compensates by naming the returned sections, subtotals, calculated result and balance check, plus the currency unit. Combined with the sibling routing and the fully documented two-parameter schema, an agent has everything needed to call this 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 coverage is 100% and both parameters are fully documented in the schema, including format and a hint to fetch orgnr via list_companies, so the baseline is 3. The description adds only the framing that balansdag is the date the balances apply to, which the schema already states.

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

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

The description states a specific verb and resource (shows the balance sheet as of a date, per K2) and explicitly distinguishes itself from the two closest siblings, get_trial_balance and get_income_statement. An agent can select this tool without opening any schema.

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

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

It gives an explicit use condition (questions about assets, liabilities and equity) and names the alternatives with the condition that selects each: get_trial_balance for per-account balances, get_income_statement for the income statement. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the default period is scoped from fiscal-year start to today, and the label/data are aligned with reconciliation and trial balance.

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 dense sentences: the first states what data is returned, the second covers arguments and default scoping. It is front-loaded and has little waste, though some Swedish domain terms make it less immediately accessible.

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

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

For a read-only aggregate detail tool with no output schema, the description covers the returned domains and the optional period behavior. It lacks sibling comparison guidance, but otherwise gives an agent enough to call it correctly given the annotations.

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 33%, with year and month undocumented in the schema. The description compensates by naming year and month as optional period arguments and explaining what happens when no period is supplied, adding meaningful semantics beyond the bare defaults.

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: full company detail for an organisation number, and enumerates the included areas (income statement/balance sheet, bank reconciliation, subledger tie-outs, VAT, findings). It does not explicitly differentiate itself from sibling tools like get_overview or get_balance_sheet, 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?

It explains the required argument and the default period scoping when year/month are omitted, which implies usage context. However, it does not say when to use this aggregate tool versus narrower siblings such as get_reconciliation or get_vat_return, leaving selection guidance to inference.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered; the description's 'Läser bara, ändrar inget' largely restates that. It does add genuinely useful context by enumerating the returned fields (customer, invoice number, dates, rows, amounts in öre, remaining balance, status, voucher number), which the annotations cannot convey.

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

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

Front-loads purpose, then usage routing, then return shape in a tight paragraph with no filler. The return-field sentence is somewhat run-on but every element is informative.

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

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

With no output schema present, the description compensates by listing the return payload in detail, and usage/prerequisites are fully covered. An agent has everything needed to call and interpret this 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 coverage is 100% and both parameters (orgnr, invoice_id) are fully documented in Swedish with formats and how to obtain them. The description adds no parameter syntax or meaning beyond the schema, 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 ('Hämtar en kundfaktura med alla uppgifter') and explicitly distinguishes itself from two named siblings (list_customer_invoices, customer_outstanding). An agent can differentiate it from the other invoice tools without opening schemas.

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 trigger ('Använd när du har fakturans id och behöver detaljer') plus named alternatives with their selecting conditions (list for finding/listing, customer_outstanding for unpaid per customer). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so the safety profile is covered; the closing "Läser bara, ändrar inget" largely restates that. However, the detailed enumeration of what the response contains (avskrivningsplan, ackumulerade avskrivningar, bokfört värde, avyttring) is genuine behavioral context not available anywhere else, which lifts it above baseline.

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

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

Front-loaded with purpose, then usage routing, then return contents, then a read-only note. The return-value enumeration is long but each field is informative for a tool with no output schema; there is little 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 no output schema, the description compensates by spelling out the returned fields, which is the right call. Safety/idempotency are carried by annotations and parameters by the schema, so the remaining coverage gap is only pagination/edge-case behavior, which is minor for a single-resource getter.

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 both parameters are fully documented there, including formats (10-digit orgnr, integer id) and where to fetch them. The description only implies the asset_id requirement, adding nothing the schema does not already state. Baseline 3 per the rule for high coverage.

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

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

States a specific verb and resource ("Hämtar en anläggningstillgång") and disambiguates from the nearest siblings. An agent can distinguish this from list_fixed_assets and preview_depreciation purely from the description.

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

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

Explicit trigger ("Använd när du har tillgångens id") plus named alternatives with the condition that selects each (list_fixed_assets for all assets, preview_depreciation for the next depreciation). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the 'Läser bara, ändrar inget' sentence is partly redundant. The description earns credit, however, by disclosing the return shape (columns datum, verifikat, text, debet, kredit, saldo) and the amount unit (öre), which no annotation or output schema provides.

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 sentences, front-loaded with purpose then routing then return format; every sentence carries information. The column enumeration is a slight expansion but is justified given there is no output 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 no output schema, the description correctly compensates by describing the returned columns and units, and it covers scope plus sibling routing. Minor gaps remain (e.g., behavior for large date ranges), but nothing essential to calling it correctly 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 schema already documents orgnr, start, end and the optional account filter with formats and examples. The description only implies period/account scoping and adds no syntax or semantics beyond the schema, 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 ('Visar huvudboken för en period') plus the exact content it exposes (transaktionerna per konto med ingående, löpande och utgående saldo). It distinguishes itself from list_vouchers, get_voucher and get_trial_balance, so an agent can separate it from siblings without opening any schema.

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

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

Gives an explicit use case ('följa ett kontos rörelser') and names the alternatives with the condition that selects each: whole vouchers via list_vouchers/get_voucher, balances only via get_trial_balance. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: return structure (groups of accounts), unit and sign convention (belopp i öre, intäkter positiva, kostnader negativa) and the computed result.

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 sentences, front-loaded with purpose, then routing, then return semantics. No filler; each sentence adds a fact the agent needs. The closing 'Läser bara, ändrar inget' is brief and reinforces the safety profile.

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

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

No output schema exists, so the description must describe the return — it does so concretely (account groups, amounts in öre with sign convention, calculated profit). All three required parameters are documented in the schema, and the sibling routing is handled. Nothing needed to call the tool correctly 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% — every parameter has a format example and a hint (orgnr hämtas med list_companies). The description adds nothing about the parameters, so the schema carries the full load and 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?

Specific verb (Visar), resource (resultaträkningen), scope (en period) and presentation standard (K2 med alla konton). It also names the two sibling tools it is not (get_balance_sheet, read_annual_report), so an agent can disambiguate without reading any schema.

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

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

Explicitly states when to use it (frågor om intäkter, kostnader och resultat) and routes the agent to specific alternatives for adjacent cases: get_balance_sheet for the balance sheet and read_annual_report for annual-report figures with comparison years.

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 cover the safety profile (readOnly, idempotent, non-destructive), so 'Läser bara, ändrar inget' is largely redundant. Against that lower bar the description still adds real value: the öre currency convention, the tax_lines/current_tax_lines distinction after refunds, what suggested_voucher contains and that it must be reviewed before booking, and that include_raw pulls in the source's untouched response.

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 dense paragraph, but the purpose and the routing rule are front-loaded and every subsequent sentence carries domain payload (field inventories per record type, currency semantics, voucher-review caveat). It is long, yet with no output schema almost nothing here reads as 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?

There is no output schema and no nested objects, so the description rightly carries the full burden of describing return shape, and it does so per record type (order, payout, charge) plus the suggested_voucher structure and sign convention. An agent has enough to call it and interpret the result 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 100%, including how to obtain orgnr and record_id, so the schema does the heavy lifting and a baseline 3 applies. The description restates include_raw ('Med include_raw följer källans oförändrade svar med') without adding parameter-level syntax or format detail beyond the schema.

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

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

States a specific verb and resource ('Hämtar en post från en koppling') and then enumerates the concrete record kinds it returns (Shopify-order, Stripe-betalning, utbetalning). It also explicitly disambiguates from the sibling list_integration_data, so an agent can pick between them without opening either schema.

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

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

'Använd innan du bokför posten' gives the precise point in the workflow where this tool belongs, and 'för att hitta poster, använd list_integration_data' names the alternative plus the condition that selects it. Nothing about when-to-use is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description's 'Läser bara, ändrar inget' largely restates that. It adds genuine value by disclosing the return content since there is no output schema, but adds no behavioral detail like rate limits or scope beyond the month.

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 purpose, then alternative routing, then return details, then a read-only note. Slightly long but each sentence carries distinct information; 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 no output schema, the description compensates by enumerating returned aggregates and per-bilaga fields. Combined with the routing guidance and full param coverage, 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?

Schema description coverage is 100%, so year, month and orgnr are fully documented in the schema. The description only implies month scoping and adds no syntax or format detail beyond what the schema provides, 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 ('visar vad som återstår att stämma av för en månad: alla avstämningar som inte är attesterade') and explicitly contrasts itself with the sibling get_reconciliation. An agent can distinguish it from the full-detail tool without opening the schema.

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

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

Explicitly gives when to use it ('för frågor som hur mycket är inte avstämt') and names the alternative with its selecting condition ('för full detalj per bilaga ... använd get_reconciliation'). No inference required.

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=false, so "Läser bara, ändrar inget" largely restates what is known. However, with no output schema, the description adds real behavioral value by describing the return content (monthly revenue/profit values and a list of upcoming deadlines).

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 purpose, followed by alternatives, then return shape, then safety. Every clause carries information and there is 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?

For a single-parameter read tool with no output schema, the description covers purpose, alternatives, return contents and read-only behavior. Nothing needed to call it correctly 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 coverage is 100% and the single orgnr parameter is fully documented in the schema, including format and how to obtain it (list_companies). The description only implies company scoping via "för ett bolag" and adds no syntax or format detail, 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 ("Visar") and resource ("översikt för ett bolag") and enumerates the exact contents: monthly revenue and profit plus deadlines for VAT, INK2 and annual report. It also names the sibling tools it is not (read_checklist, read_statutory_status), so an agent can distinguish it without opening other schemas.

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

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

Explicitly says when to use it ("Använd för en snabb lägesbild") and routes the agent to the correct alternatives with the condition that selects them: read_checklist for remaining work, read_statutory_status for submission status. This is exactly the when/when-not/alternatives structure.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavior beyond them: the output structure (components, entry_ids, absence, notes), the side effect of marking hours paid when fed downstream, and the explicit guardrail 'Räkna aldrig om beloppen själv'.

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 core scope before diving into output structure and workflow, and every sentence carries actionable content. It is dense and slightly long, but nothing is redundant.

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

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

With no output schema, the description carries the return-value burden and does so by naming components, entry_ids, absence, and notes. Combined with the workflow guidance, an agent has everything needed to call and act on this tool.

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

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

Schema coverage is 50%: orgnr is documented in the schema, but through has no schema description. The description compensates by specifying through's format (YYYY-MM-DD) and default (today), adding meaning the schema omits.

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: approved but not-yet-paid hours per employee up to a date (attesterade, ännu inte utbetalda timmar per anställd t.o.m. ett datum). This precisely distinguishes it from siblings like get_time_reporting, list_time_entries, and get_payslip by scoping to the payroll-preparation view.

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

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

Gives clear downstream routing: send components and time_entry_ids = entry_ids to calc_payroll/run_payroll to mark hours as paid, and flags that absence and notes must be handled manually. Strong context, though it does not explicitly contrast against the other time/payroll query tools an agent might pick.

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?

Annotationerna anger readOnlyHint=true, idempotentHint=true, openWorldHint=false och destructiveHint=false, så beskrivningen behöver inte upprepa detta. Beskrivningen nämner 'utskrivbar HTML' (utdataformat) och scope view (auktorisering), vilket är användbart. Men den saknar information om storlek, begränsningar eller vad som händer om line_id inte finns, vilket är relevant för en läsoperation med okända returvärden.

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?

Två meningar som är front-loadade med syftet och därefter nödvändig kontext (scope, argumenthänvisning). Ingen utfyllnad.

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?

För en enkel läsoperation med två parametrar och tydliga annotationer är beskrivningen tillräcklig. Den nämner utdataformat och scope. Ett litet gap är avsaknaden av information om vad som händer om line_id är ogiltigt, men annotations täcker säkerhetsprofilen.

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-täckningen är 50% och beskrivningen fyller delvis gapet: den nämner att line_id kommer från en lönekörnings rader (se list_payroll_runs) och att orgnr är relaterat till företaget. Baslinjen är 3, men den tillför extra vägledning för line_id som inte finns i schemat.

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?

Står ett specifikt verb och resurs ('Hämta lönebeskedet för en lönerad') och anger utdataformatet (utskrivbar HTML). Skiljer sig från syskonen genom att vara den enda lönebeskeds-hämtaren, även om 'line_id från en lönekörnings rader' kräver kännedom om list_payroll_runs.

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?

Användningskontexten är underförstådd – du hämtar ett lönebesked när du behöver det. Den hänvisar till list_payroll_runs för att hitta line_id, vilket är en användbar ledtråd, men det finns ingen explicit när/when-not eller alternativ.

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

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

Annotations declare readOnlyHint/idempotentHint/destructiveHint=false, and the description reinforces with 'Läser bara, ändrar inget'. It adds real behavioral value beyond annotations by disclosing that the figures are computed at call time ('Räknas fram vid anropet') and by listing what each item contains. Not a 5 because pagination/limits on 'alla avstämningar' are unaddressed.

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

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

Front-loaded with purpose and alternatives, and the detailed return-field enumeration is informative rather than padding. It is longer than average but each clause carries content; the return-value list could arguably be trimmed.

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

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

With no output schema, the description usefully compensates by enumerating returned fields (typ, konto, saldo, avstämt belopp, differens i öre, status, specifikationsrader, underlag, poster, attester). Combined with full parameter docs and annotations, an agent has what it needs; only aggregation scope/pagination is unspecified.

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 year, month and orgnr are already fully documented (including the org-number format and the 'fetch via list_companies' pointer). The description adds no parameter-level syntax or constraints beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource ('Hämtar alla avstämningar (bilagor) för en månad med full detalj') and enumerates the domains covered (bank, kund-/leverantörsreskontra, moms, skattekonto, anläggningar). It also names the siblings it is not (get_open_reconciliations, list_findings), so an agent can differentiate it without opening any schema.

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

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

Explicit routing: use this when working with a reconciliation, use get_open_reconciliations for only what remains, and list_findings for deviations with correction proposals. This is a textbook when-to-use plus alternatives statement.

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 cover readOnly, idempotent, non-destructive, and closed-world behavior. The description adds genuine context beyond that: the output is a version-6 XML file, the operation transmits nothing to the tax authority, and it requires the "view" scope. Those details help an agent set expectations.

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?

Purpose and workflow are front-loaded and the total length is modest. The trailing 'Argument: orgnr, request_id' list is pure redundancy with the schema, and the 'Scope view.' fragment is terse to the point of being cryptic, but neither derails the definition.

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

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

For a read-only file-fetch with full annotations and no output schema, the description conveys what the file is, its schema version, and the human workflow around it. The gap is request_id semantics, which are absent from both description and schema.

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

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

Schema coverage is only 50%, and request_id has no description anywhere. The description merely restates the argument names ('Argument: orgnr, request_id'), adding nothing beyond the schema and doing nothing to compensate for the undocumented request_id.

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

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

The description states a specific verb and resource — fetching a ROT/RUT request rendered as Skatteverket's XML file (schema version 6) — which clearly separates it from create_rot_rut_request, list_rot_rut, and the payout siblings. It does not name any sibling explicitly, so it stops short of the top score.

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 explains the downstream workflow: the user imports the file into Skatteverket's e-service and signs there, and Kvickd sends nothing. That implies when the tool is appropriate, but it gives no explicit when-to-use/when-not guidance or comparisons against siblings like list_rot_rut or mark_rot_rut_request_submitted.

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, and the closing line 'Läser bara, ändrar inget' largely restates that. However, the description adds real value beyond annotations by enumerating what the payload contains (supplier, OCR, dates, lines with account/VAT, remaining balance in öre, voucher number), which tells the agent the response is a full accounting detail. Minor redundancy with readOnlyHint keeps it from 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?

Three sentences, front-loaded with purpose, then usage/alternative, then payload. The return-field enumeration is long but earns its place since no output schema exists. No filler sentences.

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

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

With no output schema, the description compensates by listing the key returned fields, and annotations already carry the safety profile. Purpose, alternative routing, safety and return content are all covered, so an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100% and both parameters are documented with formats and example values plus how to obtain them (list_companies, list_supplier_invoices). The description alludes to 'fakturans id' but adds no syntax or meaning beyond the schema, 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 ('Hämtar en leverantörsfaktura med alla uppgifter') and explicitly distinguishes itself from the sibling list_supplier_invoices. An agent can tell it apart from the list tool without opening either schema.

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

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

Gives the exact selection condition ('Använd när du har fakturans id och behöver detaljer') and names the alternative with its condition ('för att hitta fakturor eller se flera, använd list_supplier_invoices'). Nothing is left to inference.

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