More AI - ChatGPT & Claude MCP (Fortnox)

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered; the description usefully adds that the output is a link a person opens, i.e. the side effect happens outside the tool. It does not state link lifetime, single-use behaviour, or what happens if the company is already connected, which is the remaining gap.

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 positive case before the exclusion, which is the right order. The long parenthetical of Swedish synonyms is dense but each item earns its place as a disambiguation cue; the emphatic capitalization is slightly noisy but not wasteful.

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

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

For a zero-parameter, read-only link generator with no output schema, the description is nearly complete: it covers what is returned conceptually, who consumes it, and which sibling handles the adjacent task. Only link expiry and already-connected edge cases are 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?

Zero parameters, so the baseline is 4; the description correctly implies no input is needed and none is offered by the schema. Nothing further is required, though it could note that the target connection is inferred from context rather than passed in.

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: get a link that connects an additional, not-yet-connected Fortnox company to the current connection. The scope qualifier ('ANOTHER, NOT YET CONNECTED') separates it from get_connected_company and list_connected_companies without requiring the schemas to be opened.

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 ('only for adding a company') and an explicit when-not (not the page for seeing or managing the existing connection), then names the alternative to use instead: connection_url in the connected company's details. Even the Swedish user phrasings ('min anslutning', 'bjud in') are mapped, which removes ambiguity for a Swedish-titled tool.

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 burden is covered. The description adds real context beyond that: results are computed server-side from live Fortnox data and span all pages, telling the agent there is no pagination to manage and the figures are current.

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 compact sentences: scope first, an example question second, provenance last. Each sentence earns its place, and the resource name is front-loaded; only the somewhat telegraphic middle clause costs 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?

With full schema coverage, an output schema present, and rich annotations, everything an agent needs is covered; the description supplies the one thing structured fields cannot — what business question the tool answers and that data is live across all pages.

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 period, fromdate, todate and stort_belopp (including the 10,000 kr default). The description adds nothing further about these parameters, which is acceptable given the schema quality but is the baseline rather than added value.

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

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

The description names the resource (periodiseringar/accruals) and spells out the three things checked: planned accruals, whether they are booked, and large invoices on advance-payment accounts that lack one. This is a specific check rather than a restatement of the name, though the compressed Swedish phrasing makes it slightly harder to parse at a glance.

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 embedded example question ("Har vi periodiserat det som ska periodiseras? Bokförs periodiseringarna?") implies the user intent this tool answers, which is genuine usage signal. However, no alternatives or exclusions are named, so an agent must infer when this beats check_vat, get_month_end_review, or get_year_end_package.

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 the tool is read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond that: results are computed server-side from live Fortnox data and cover all pages, which tells the agent the output reflects current data rather than a cached or truncated sample.

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 compact and front-loaded: it identifies the area first, then lists the checks, then gives a concrete example question, then notes the data source and pagination behavior. There is 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?

Given that annotations cover safety, the schema fully documents both optional parameters, and an output schema exists, the description provides enough context for correct invocation: what is checked, why it matters, the live Fortnox source, and all-pages coverage. No essential selection or behavioral information 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 meaning of todate and financialyear is already documented in the schema. The description adds no parameter-specific guidance, which is acceptable given the schema coverage, but it does not compensate with extra examples or constraints beyond the schema baseline.

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

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

The description names the specific domain (Anläggningar/fixed assets) and states three concrete checks: unbooked depreciations, fixed-asset register vs. bookkeeping, and large purchases that were expensed. This clearly distinguishes it from sibling check_* tools such as check_accruals, check_vat, or check_opening_balances.

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

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

The example question ('Har vi bokfört alla avskrivningar? Stämmer anläggningsregistret med bokföringen?') gives a clear usage scenario and implies the year-end/reconciliation context. It does not explicitly name when not to use it or route to alternatives, but the context is strong enough that an agent can recognize the relevant fixed-asset reconciliation case.

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 read-only and idempotent annotations, it discloses that results are computed server-side from live Fortnox data and searched over all pages. It also specifies the three places searched: ledger, inbox, and attached file. Output details are left to the 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?

The description is front-loaded with the core question and then adds the key scope and data-source details. It is information-dense and mostly waste-free, though the API documentation URL is arguably extraneous.

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 two-parameter read-only lookup with an output schema and full schema coverage, the description supplies the important context: what is checked, where it is checked, when to use it, and that data is live. It could more explicitly route agents away from nearby sibling tools, but 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 description coverage is 100%, so the input schema already documents both parameters thoroughly. The description mentions invoice-number lookup and gives example numbers, but adds no syntax or format details 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?

The description states a specific check: whether supplier invoices already exist in Fortnox by invoice number, covering the ledger, inbox, or attached files. It clearly frames the operation as a pre-upload/pre-registration existence check, which distinguishes it from sibling listing or duplicate-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 gives a clear usage context: run before anything is uploaded or registered. The example question reinforces the intended scenario. It does not explicitly name alternatives or exclusions, but the when-to-use guidance is strong.

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 the safe read-only, idempotent, closed-world profile, so the description's extra value is the statement that results are computed server-side from live Fortnox data and aggregated over all pages — telling the agent no pagination handling is needed. It does not disclose failure modes or what happens when the fiscal year cannot be resolved; return details are arguably covered by the 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?

Purpose is front-loaded in the first clause, followed by the example question and the data-source note — a sensible order. The text is dense and mixes Swedish with an English data-source sentence, but no sentence 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?

For a two-optional-parameter, read-only check with an output schema and full annotation coverage, the description supplies what the check verifies, the trigger question, and the data provenance. Remaining gaps (output shape, behavior on missing prior year) are offset by the output schema and 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 100% and both parameters (date, financialyear) are documented in the schema, so the schema carries the semantics. The description does not add syntax, default behavior, or precedence rules between date and financialyear, so the baseline 3 applies.

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

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

The description names a concrete verification task: whether this year's opening balances match last year's closing balances, whether last year's result is booked and appropriated, and comparison against prior-year key figures. That is far more specific than the title 'Årsskiftet'. It does not explicitly position itself against siblings like get_year_end_package or reconcile_ledgers, so it stops short of a 5.

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

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

The embedded example question ('Stämmer ingående balanserna med förra årets bokslut?') gives an agent a concrete trigger pattern for selecting this tool. There is no explicit when-not guidance or named alternative among the many sibling check_* tools, which keeps it at 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's job is to add beyond that. It does: it states the result is computed server-side from live Fortnox data over all pages, telling the agent data is fresh and complete rather than paginated. It says nothing about output shape, but an output schema exists.

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 detection rules are front-loaded, followed by an example question, then provenance. Dense but efficient. The Fortnox API URL is mild boilerplate, though it usefully signals the data source.

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 annotations covering safety, an output schema covering returns, and a fully-described schema, the description only needs purpose, trigger and data scope — all present. Minor gaps remain around what counts as 'before payment' beyond the fram default, but nothing essential to invoking it 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 three parameters (fram, dagar, stort_belopp) are already fully documented, including defaults and caps. The description conceptually maps to them (changed shortly before payment, large invoices) but adds no syntax or tuning guidance beyond the schema, making the baseline 3 appropriate.

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

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

The description names three concrete detection rules (suppliers changed shortly before a payment, underlag whose bankgiro differs from the register, new suppliers with large invoices), which is a specific verb-plus-resource statement rather than a restatement of the title 'Betaluppgifter'. This makes it clearly distinguishable from sibling tools like find_duplicate_supplier_invoices or get_payment_list.

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

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

The example question ('Har någon leverantör bytt bankgiro? ... innan vi betalar?') supplies a clear triggering scenario: a pre-payment control check. It stops short of explicit exclusions or naming which sibling to use instead (e.g. get_payment_list for the actual payment run), so it is clear context without routing rules.

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 behavior beyond that: the result is computed server-side from live Fortnox data and covers all pages, meaning the agent gets a complete reconciliation rather than a paginated slice. Minor gap: it does not say how months with no payroll activity are handled.

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 compact sentences lead with the check itself, followed by example questions and the data-provenance note. Nothing is padding, though the Fortnox API URL is marginally gratuitous for an agent that cannot call it.

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

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

With an output schema present, return values need not be explained, and all three optional parameters are fully described in-schema. The remaining shortfall is that the entire definition is Swedish-only, and there is no note on what happens when the period contains no booked payroll or on how the from/to defaults are derived when a fiscal year is ambiguous.

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 from/to/date defaults (previous month, first month of the fiscal year) and formats are already fully documented in the schema. The description only implies month-by-month scope via "månad för månad" and adds no syntax, range, or precedence details beyond what the schema states. Baseline 3 applies.

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

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

The description states a specific check with a specific object: whether employer contributions (arbetsgivaravgifter) and withheld tax match booked salaries month by month, plus whether the tax/contribution liabilities are paid. That is far more informative than the title alone. It does not, however, explicitly position itself against adjacent siblings such as check_vat or get_personnel_costs, so an agent must infer the boundary from domain wording.

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 embedded example questions ("Stämmer arbetsgivaravgifterna mot lönerna? Är personalskatten betald?") give concrete situations that should trigger this tool, which is real usage context rather than tautology. There are no explicit exclusions or named alternative tools for overlapping cases, so it falls short of full when/when-not guidance.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds meaningful context beyond them: results are computed server-side from live Fortnox data and span all pages, telling the agent the output is a derived, complete snapshot rather than a paginated raw list.

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 core definition, then a motivating example question, then provenance. Every element serves a purpose, though the full Fortnox API URL is slightly gratuitous filler.

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

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

With an output schema present, return values need no explanation, and annotations plus zero params keep the surface small. The remaining gap is that ROT/RUT domain jargon and the boundary against list_tax_reductions are left implicit, which slightly limits completeness for an unfamiliar agent.

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

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

The tool takes zero parameters, so there is nothing to document and the baseline is 4. No parameter information is needed or missing.

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 scope: cases where the customer has paid their share but the application to Skatteverket hasn't been sent, plus cases awaiting a decision. That is a clear, checkable state, not a tautology of the name. It does not explicitly distinguish itself from a sibling like list_tax_reductions, so it stops short of a 5.

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

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

The example question ('Har vi begärt ut all ROT och RUT från Skatteverket?') gives a concrete trigger scenario, which is useful implied guidance. However, there is no explicit when-not-to-use statement and no named alternative for overlapping tools such as list_tax_reductions, 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/closed-world, so the safety profile is covered. The description still adds meaningful behavioral context: it is computed server-side from live Fortnox data and runs across all pages, telling the agent results are fresh and paginated. It does not detail cost or rate limits, 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?

The core check is front-loaded in the first sentence, followed by an example and a short data-provenance note. The API URL reference is slightly extraneous but the overall length is justified and well-ordered.

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

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

With an output schema present, return values need not be explained. The description covers what is compared, that it looks for missing attachments, that data is live, and that all pages are included, giving the agent enough to call it correctly. Minor gaps remain around whether results are flagged vs. enumerated.

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 max, borjan, from_date, to_date and leverantor are all documented in the schema itself. The description adds no parameter-specific syntax or format guidance beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb (check/match) and resource (supplier invoices vs. their attachments) plus the exact fields compared: amount, VAT, due date, OCR and bankgiro, and which lack attachments. It is clearly distinguishable from list_supplier_invoices and find_duplicate_supplier_invoices, though it does not explicitly name the closest sibling, find_vouchers_without_attachments.

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?

An embedded example question ("Stämmer leverantörsfakturorna i september mot sina underlag? Saknas någon bilaga?") implies when the tool applies, which is helpful context. However, there is no explicit when-to-use/when-not guidance and no alternative tool is named for overlapping cases.

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 description adds genuinely non-obvious context: the result is computed server-side from live Fortnox data and traverses all pages, so the agent knows results are complete and not a partial page sample.

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 scope of the check is front-loaded, followed by a usage example and a provenance note; every clause contributes. The mixed Swedish/English phrasing and the dense enumeration make it slightly harder to scan than it could be.

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

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

An output schema exists, so return values need not be described, and both parameters are fully documented in the schema. The remaining gap is the missing relation to get_vat_return_boxes, which matters because that sibling is the natural next step after this check.

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 from/to already document their YYYY-MM format and default behavior. The description adds nothing about the period parameters, so this sits at the baseline where the schema carries the load.

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 concrete analysis (VAT check) and enumerates the four specific checks it performs: sales per VAT rate vs booked output VAT, reverse charge, un-cleared VAT accounts, and the EU threshold. That is far more specific than the title alone. It does not, however, state how it differs from the closely related sibling get_vat_return_boxes, 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?

The example question "Stämmer momsen inför deklarationen?" implies the pre-declaration reconciliation use case, which is useful. But there is no explicit when-to-use/when-not guidance and no routing to get_vat_return_boxes, the obvious alternative for producing the actual VAT return figures.

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 the description correctly spends its words on the trait not expressible in annotations: the file is never transmitted through the conversation and instead is surfaced as an openable link. That is a genuinely load-bearing detail for an agent deciding how to present results. It stops short of noting link lifetime, permission requirements, or what happens if a path/fileid combination is wrong.

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 compact sentences, no filler, and the behavioral payoff (link, not inline file) is placed early. The leading noun fragment is stylistically awkward as an opener but does not cost the reader much.

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

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

An output schema exists, so return values need not be explained, and all three parameters are documented in the schema. The remaining gap is routing: with downloads, reads, and archive listings all present as siblings, the description does not fully arm an agent to pick this tool without comparing schemas. Adequate but not complete.

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 baseline is 3. The endpoint template '{id}' loosely signals that id is the file identifier, but the description says nothing about the optional 'path' (show a folder) or 'fileid' (fileId from fileattachments) parameters or how they interact with id. Marginal value added over 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 identifies the resource (a file in the Fortnox archive) and, via the endpoint reference GET /3/archive/{id}, an unambiguous operation. It also distinguishes the output mode ('a link the person opens') from tools that return the file contents inline. The opening sentence is a noun fragment ('A file from the Fortnox archive') rather than a verb phrase, which weakens the framing slightly.

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

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

No statement of when to use this versus the obvious sibling read_archive_file, nor versus get_archive or list_archives, even though all four appear in the sibling list. The agent must infer from 'link the person opens' that this is the share-with-a-human path rather than the read-the-contents path.

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 description adds genuinely new behavior: the file never passes through the conversation and the caller receives a link, which changes how an agent must handle the result. It also cites the underlying API endpoint.

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

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

Three short sentences, each carrying distinct information (what it is, how it is delivered, where the API is documented). The opening fragment is terse rather than front-loaded with a verb, and the raw API link is mildly noisy, but 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?

An output schema exists, so return-value explanation is not required. However, for a tool sitting in a dense inbox cluster with several near-neighbors, the missing routing guidance and the unresolved 'folder' vs 'file' Id ambiguity leave gaps an agent must resolve by trial.

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 single Id parameter is documented, giving a baseline of 3. The endpoint template GET /3/inbox/{Id} mildly clarifies that Id is an inbox item identifier, but it does not resolve the schema's confusing 'identifies the folder' wording, so no extra credit is earned.

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

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

The description conveys the resource (a file from the Fortnox inbox) and the delivery mechanism (a link the person opens), but never states the verb explicitly and never distinguishes itself from close siblings such as read_inbox_file or get_inbox. An agent can infer it produces a download link rather than file content, but must guess at 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?

No when-to-use guidance and no mention of alternatives, despite the sibling list containing read_inbox_file, get_inbox, list_inboxes and list_unprocessed_inbox. The agent gets no rule for choosing download vs. read vs. list.

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 non-read-only, non-destructive, idempotent and closed-world behavior, so the safety profile is covered. The description adds the human-approval precondition, which is real context. However, it never says what switching actually changes (presumably the active company context for subsequent calls) or what happens if no approved proposal exists.

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

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

Two sentences, no waste, with the action stated first and the precondition second. Every sentence carries a distinct, load-bearing instruction.

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 two-parameter mutation with no output schema, the definition covers the action and the approval gate but leaves the token's provenance and the tool's post-call effect on session state unstated. Adequate to call correctly, incomplete to call confidently.

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

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

Schema description coverage is 0%, so the description must compensate for two bare parameters. It does link company_key to 'the company named in an approved proposal' and confirmation_token to the person's agreement, but it never says where the token originates (presumably propose_company_switch) or that company_key is a numeric identifier.

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 ('switch to the company') and ties the target to an approved proposal, which implicitly separates it from propose_company_switch. It stops short of naming that sibling explicitly, but an agent can distinguish the execution step from the proposal 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?

'Only call this after the person has agreed to that exact switch' gives an explicit precondition and implies the propose-then-execute flow. No exclusion of alternatives is spelled out, but the gating condition is unambiguous.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, and the description adds real value on top: it refuses expired or altered proposals and applies the change unchanged. It does not explain what a refusal looks like or what partial failure means in a batch.

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

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

Two sentences, no filler, with the instruction front-loaded and the constraint immediately after. 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 destructive, idempotent write tool the description covers preconditions and refusal behavior well, and annotations cover the safety profile, with no output schema to explain. However, the batch parameter's shape and limits and the outcome of a partially failed batch are left undocumented.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains the provenance of approval_token and idempotency_key ('from that proposal'), but says nothing about the third parameter, `batch`, which accepts either up to 25 token/key objects or a JSON string — a significant undocumented capability.

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 uses a specific verb and resource ('Send the exact change the person approved') and scopes it with 'It cannot start a new operation', which implicitly separates it from propose_fortnox_write. It never names a sibling, so the differentiation is inferred rather than explicit.

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

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

It clearly states the precondition (an already-approved proposal, using its approval_token and idempotency_key) and the exclusion (it cannot start a new operation). It stops short of naming propose_fortnox_write or resolve_fortnox_write as the alternatives for unapproved or stuck proposals.

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, non-destructive and closed-world, so the safety profile is covered. The description adds genuine context beyond them: results are computed server-side from live Fortnox data and aggregate over all pages, so the agent knows the output is fresh and complete rather than a paginated sample.

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 metric definition, followed by an example question and then data provenance — three compact, non-redundant sentences with nothing that repeats the schema or annotations.

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

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

An output schema exists and annotations are rich, so return values and safety need not be explained. The description covers what counts as a deviation and where the data comes from; the only omission is how the "usual" baseline is determined (methodology/threshold), which an agent might otherwise ask about.

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

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

Schema description coverage is 100% and the single parameter (dagar) is fully documented with default 60 and max 365 in the schema. The description adds nothing about the parameter, so the baseline 3 applies — the schema does the work.

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 gives a precise definition of the metric: new supplier invoices booked to a different account or with a different VAT rate than the supplier's usual. That is a specific resource plus a specific detection criterion, not a restatement of the name. It stops short of naming how it differs from the closest siblings (find_duplicate_supplier_invoices, get_deviations_vs_last_month).

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

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

Usage is implied through an example question ("Har någon leverantörsfaktura konterats annorlunda än vanligt?"), which tells the agent the kind of user intent that should route here. There is no explicit when-not-to-use guidance and no mention of the neighbouring deviation/duplicate tools that could be confused with it.

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 bar is lower; the description still adds real value by disclosing that results are computed server-side from live Fortnox data and aggregate over all pages, so the agent knows it is authoritative and already paginated. It omits any note about latency, rate limits, or result size.

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 scope statement is front-loaded, followed by the source/pagination note and one concrete example question. The long em-dash enumeration is dense but every clause carries information; nothing is padded.

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

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

With an output schema covering return values and full annotation coverage, the description supplies what is missing: what the tool computes (live data, all pages), what scopes exist, and a realistic trigger question. An agent has enough to call it correctly without guessing.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents kund, status, todate and fromdate precisely. The description mostly restates the status enum and the returned fields rather than adding format or edge-case meaning (e.g. how partial name matching behaves, or how dates interact with status).

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 (fetch customer invoices) and enumerates the scoping options: a customer or a status among obetalda/förfallna/ej_skickade/betalda/alla, with amount and due date returned. It does not, however, distinguish itself from close siblings such as list_invoices, check_invoices_exist, or find_supplier_invoices, so an agent must infer the boundary itself.

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

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

Usage is only implied through the example question ("Har Nordic betalat sina fakturor? Vilka kundfakturor är inte skickade?"), which usefully illustrates the receivables-collection scenario. There is no explicit statement of when to prefer this over list_invoices or get_receivables_aging, and no exclusions or prerequisites are given.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely useful behavior: results are computed server-side from live Fortnox data across all pages, so the agent knows there is no client-side pagination gap. It omits finer points such as whether unbooked invoices are included by default, which the filter schema partially covers.

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 compact paragraph, front-loaded with the definition, then the example question, then the computation note. The leading 'Dubblettkontroll:' repeats the title, costing a little space, but otherwise nothing is wasted.

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

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

With an output schema present, return values need no explanation, and annotations cover safety. The description supplies the matching logic, data source, and scan scope, which is what an agent needs. Only minor gaps remain, e.g. whether obokförda invoices are treated differently in duplicate detection.

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 parameters (filter, fromdate, hela_historiken) are already fully documented in the schema. The description adds no additional detail about parameter interaction or formats, so baseline 3 applies. The 'over all pages' note hints at the hela_historiken behavior but does not explain it directly.

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 operation and matching rule: supplier invoices sharing the same supplier+amount, or the same invoice number. This is clearly distinct from the sibling listing tools (list_supplier_invoices, find_supplier_invoices), which do not perform duplicate detection. An agent can pick this tool from the name plus definition 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 concrete example question ("Har vi registrerat någon leverantörsfaktura två gånger?") makes the intended scenario obvious. It does not name an alternative or state when not to use it, but the matching criteria define the usage well enough for correct selection.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: results are 'computed on the server from live Fortnox data' and span 'all pages', disclosing data freshness and pagination 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?

The scope and status list come first, followed by illustrative questions and a short provenance note; each part adds something. Mild redundancy with the title and the schema's status list keeps it from a 5.

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

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

With an output schema present, return values need not be explained, and annotations cover safety. The description completes the picture with source, freshness and full-pagination behavior; only the sibling disambiguation gap remains.

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 four parameters (status, fromdate, todate, leverantor) are already documented, including defaults. The description's mention of statuses and amounts/due date largely restates what the schema provides, 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+resource (retrieve supplier invoices) and enumerates the status buckets it covers, which makes it clearly distinct from find_customer_invoices. It does not differentiate itself from the very close sibling list_supplier_invoices, leaving an agent to guess between the two.

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?

Two example questions ('which invoices from Telia this year?', 'which supplier invoices await attest?') implicitly illustrate when to reach for it, and the status enumeration implies the filtering modes. There is no explicit guidance on when NOT to use it and no named alternative for plain listing (list_supplier_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 readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine context beyond that: results are computed server-side from live Fortnox data and cover all pages, so the agent knows it is a fresh, complete snapshot with no pagination follow-up needed.

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: concept definition first, then example question, then data-source note. Every sentence carries information. The mixed Swedish/technical phrasing is slightly terse for a non-Swedish reader but nothing is padded.

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

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

With rich annotations, an output schema, one optional documented parameter and 100% schema coverage, the description supplies what structured fields cannot: the business definition, an example phrasing, and data freshness/completeness. Adequate for correct invocation.

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

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

Schema coverage is 100% and the single optional parameter 'dagar' is fully documented in the schema itself, including its default of 0. The description never references it, so it adds no meaning beyond the schema; baseline 3 applies.

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

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

States a specific resource and condition: orders that have been delivered but not invoiced ('ordrar som levererats men inte fakturerats'). An agent can distinguish this from find_customer_invoices or list_orders. It does not explicitly name sibling tools it might be confused with, which keeps it at 4.

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 embedded example question ('Finns det levererade ordrar som vi glömt att fakturera?') gives the agent a concrete trigger for selecting this tool. There is no explicit when-not-to-use guidance or named alternative, so it stops short of 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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond that: it is computed server-side from live Fortnox data and scans all pages, so pagination is not a concern.

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 definition is front-loaded and brief: it names the condition, gives an example question, and notes live server-side computation. It is slightly redundant with the title and API URL citation, but not meaningfully bloated.

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?

The output schema exists and annotations cover the safety profile, so the description does not need to explain return structure. It supplies the key scope and computation context an agent needs to call the tool correctly.

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

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

Schema description coverage is 100%, so the three parameters are already documented by the schema. The description only implies period filtering through 'i perioden' and does not add syntax, defaults, or other semantics 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?

The description states a specific resource and condition: manual vouchers in a period that lack a linked file in Fortnox. This is precise enough to distinguish it from general voucher tools such as list_vouchers or get_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?

The example question implies the intended audit use case, but the description does not explicitly say when to use this versus list_vouchers, get_voucher, or check_supplier_invoice_attachments. Usage is therefore clear by implication but not fully 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?

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context by stating that results are computed server-side from live Fortnox data over all pages, which tells the agent about data freshness and pagination handling.

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 front-loaded with the essential purpose and stays reasonably short. The example question and API source note are useful, though the source link is somewhat less essential.

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 ledger tool with annotations, an output schema, and fully described parameters, the description covers the main behavior and data source. It could be strengthened by clarifying how it differs from similar sibling tools, but 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 description coverage is 100%, so the input schema already explains the four parameters in detail. The description reinforces that accounts and a period are involved, but adds no syntax or constraints 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?

Description clearly states that it returns voucher lines for one or more accounts over a period, including opening, running, and closing balances. It is specific about the resource and output but does not distinguish itself from similar siblings such as get_postings_by_account or get_balance_sheet.

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

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

The example question ('Visa alla verifikationsrader på konto 4010 i mars') gives a clear usage context. It does not provide explicit exclusions or name alternatives, but the example makes the intended use case understandable.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description's only added behavior is identifying the concrete REST endpoint (GET /3/archive/{id}), which helps an agent correlate it with Fortnox docs but reveals nothing about response shape, errors, or side effects.

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

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

Two short sentences, front-loaded with the action and followed by the endpoint reference; no filler. It is perhaps too terse for what it omits, but nothing present is wasted.

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

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

An output schema exists and annotations are rich, so return values and safety do not need describing. The remaining gap is differentiation from near-identical siblings, which the description leaves entirely unaddressed for a 3-parameter file-retrieval tool.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema and the baseline applies. The '/archive/{id}' fragment merely echoes the required id parameter without clarifying the roles of the optional path and fileid fields.

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 ('Retrieve a single file') and names the underlying endpoint, so its purpose is legible. However, siblings like read_archive_file, download_archive_file, and get_fortnox_document occupy nearly identical territory, and nothing in the text distinguishes this tool from them.

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

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

There is no 'when to use this vs. X' guidance at all. With three closely overlapping archive/file-retrieval siblings in the list, the absence of routing guidance forces the agent to guess between get_archive, read_archive_file, and download_archive_file.

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 fully covered by structured data. The description adds nothing behavioral beyond that – no not-found behavior, no auth/permission requirements, no rate-limit or payload 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?

Two short sentences with the purpose front-loaded and no filler. The API doc URL is arguably of limited value to an agent, but it costs little and adds traceability.

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 one-parameter read tool with a full output schema and rich annotations, the description supplies what is needed to invoke it correctly. Missing only edge-case behavior (unknown ArticleNumber) which is not covered anywhere else.

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 parameter is documented as 'identifies the article'. The description's {ArticleNumber} path reference adds mild confirmation that the value is the Fortnox article number used in the URL, but nothing about format or validation. Baseline 3 applies since the schema does the work.

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 ('Retrieve an article') plus the exact upstream endpoint GET /3/articles/{ArticleNumber}, so an agent knows it is a single-record fetch. It does not explicitly distinguish itself from the sibling list_articles, leaving the singular-vs-list split to inference.

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

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

Usage is only implied: the required ArticleNumber and the {ArticleNumber} path segment signal 'use this when you already have an identifier, otherwise use list_articles'. There is no explicit when-to-use/when-not statement or named alternative.

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, closed-world), and the description adds real context beyond them: the figures are computed server-side from live Fortnox data and aggregated over all result pages, so the agent knows results are fresh and not paginated. It does not describe caching or latency, which keeps 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?

The definition is front-loaded with the definition of the report and its time semantics, followed by an illustrative example. The trailing Fortnox API URL and 'over all pages' note are slightly cluttering but each clause still carries information.

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

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

With an output schema present, the description need not explain return values, and it does state the aggregation level (per account group) and the comparison logic. The only gap is the financialyear parameter, which is left entirely to the 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 100%, so both parameters are already fully documented in the schema (including the 'omitted = current balances' default and the YYYY-MM-DD format). The description restates the date/comparative behaviour but adds no syntax or formatting detail beyond it, and the financialyear parameter is never mentioned.

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

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

The description names the concrete resource (balance sheet) and its composition (assets, equity, liabilities broken down per account group), plus the time semantics (now, or a chosen date compared with the same date last year). That is enough to separate it from get_profit_and_loss or get_key_figures without opening the schema, though no sibling is named explicitly.

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

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

The example question ('Vad äger bolaget och vad är det skyldigt?') plus the date/prior-year framing implies when the tool is appropriate, but there is no explicit when-to-use/when-not guidance and no alternatives among the many overlapping reporting siblings (get_group_consolidation, get_year_end_package, get_management_report).

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 read-only, idempotent, closed-world behavior, so the description's added value is the disclosure that figures are computed server-side from live Fortnox data and aggregated over all pages. That tells the agent the output is current and complete, not a cached or truncated page. It stops short of explaining how partial periods or missing due dates are handled.

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

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

Three short sentences, front-loaded with the core definition before the example and the data-source note. The API URL is arguably noise for an agent, but nothing else is wasted.

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

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

With an output schema present, the description needn't explain return shape; it covers purpose, data origin, freshness, and an illustrative query. The only real gap is that it never mentions the date/weeks defaults or absent-argument behavior, which the agent must get from the 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 description coverage is 100%, and the two parameters (date, weeks 1–26 with defaults) are fully documented in the schema. The description adds only an oblique hint in the example question ("sex veckor") and no format or range detail beyond the schema, 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?

"Bokfört banksaldo plus förfallande in- och utbetalningar vecka för vecka" states a specific computation, its inputs (booked balance + due payments) and its output granularity (weekly). An agent can distinguish this forecast tool from aging/reporting siblings like get_payables_aging or get_receivables_aging without reading 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 example question ("Räcker pengarna de närmaste sex veckorna?") implies the liquidity-planning scenario in which to use it, but there is no explicit when-not guidance or named alternative among the ~90 siblings. Usage is inferable rather than 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 establish that this is a read-only, idempotent, non-destructive operation. The description adds useful behavior beyond that: results are computed server-side from live Fortnox data and cover all pages.

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 short and front-loaded: it identifies the resource and contents first, then gives concrete example questions and source context. 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?

With an output schema, rich parameter descriptions, and annotations covering safety, the description supplies the remaining important context: live Fortnox data and all-page coverage. It could be more complete by clarifying when to choose this over sibling account tools.

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

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

Schema description coverage is 100%, so the parameters are already well documented in the input schema. The description adds no parameter-level guidance, which is acceptable but not value-adding at the baseline 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 states the resource precisely: the company's chart of accounts by account class, including balance and VAT code. It is more specific than the title alone, but it does not distinguish this tool from nearby siblings such as list_accounts or show_fortnox_chart.

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

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

The example questions ('Which accounts do we have?' and 'Which account do we use for freight?') give clear usage context for account lookup. It does not state when not to use the tool or name alternative account-related tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description adds genuine context not in annotations: results are server-computed from live Fortnox data and read across all pages, and rows are ordered by flag volume.

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 definition, then the example question, then provenance; every element is relevant. Minor waste from repeating the title 'Klientöversikt:' at the start of the description.

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

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

With an output schema present, return values need not be described here, and the description covers source, scope and ordering. The definition of what counts as 'flagged' remains unspecified, a small gap for a prioritization view.

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 'fran' parameter's default and 25-company page size are documented in the schema itself. The description adds nothing about the 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 concrete shape: one row per connected company containing 'what needs to be done', sorted by amount flagged, plus an example question that pins the use case. It is clearly a cross-client priority dashboard, though it does not explicitly name how it differs from siblings like get_multi_year_overview or list_connected_companies.

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 embedded example question ('Vilka av mina klienter behöver uppmärksamhet just nu?') gives a clear triggering scenario for an agent. There are no exclusions or named alternatives, so it stops 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 already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile needs no restating. The description adds value beyond them by disclosing what the response carries (connection_url) and what that URL is for - managing connected companies, write access, invitations and removal of access.

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 ordered well: what it returns, when to call it, what comes back. The trailing clause enumerating connection-management features is oriented toward the end user rather than the agent and is slightly longer than needed, 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 does carry the burden of describing the return value, and it names connection_url and its purpose. A caller still lacks a picture of the rest of the payload (e.g. company name/ID), but for a zero-argument lookup that is a minor 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?

Zero-parameter tool, so the baseline is 4. There is nothing in the schema for the description to explain, and it correctly spends no words on 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?

The description states a specific verb and resource (return the currently connected company) and scopes it with 'currently working with', which separates it from the sibling list_connected_companies. It stops short of naming that sibling as the alternative, so the differentiation is implied rather than explicit.

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

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

'Call this first when you do not already know which company the person means' gives a clear ordering rule and the triggering condition, which is exactly what an agent needs before touching company-scoped tools. No explicit when-not or named fallback is given, so it does not reach 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the API path reference, which confirms the read semantics and gives a doc link but discloses no new behavior such as error/not-found handling or whether the response is the raw Fortnox payload.

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, purpose front-loaded, zero padding. The documentation URL is marginally useful but does consume space without adding actionable instruction.

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 low-complexity single-parameter read tool with a full annotation set and an output schema, so return values need not be explained. The only real gap is the missing routing guidance against list_customers, which is a modest omission for a tool this simple.

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 CustomerNumber parameter is documented in the schema as 'Customer number of customer to show'. The description mirrors that via the {CustomerNumber} path template but adds no format, example, or lookup hint 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 ('Retrieve a customer') with the exact underlying endpoint, so the agent knows this is a single-record fetch. However it never distinguishes itself from the obvious sibling list_customers, leaving the singular-vs-list distinction to be inferred from the name alone.

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

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

There is no guidance on when to use this versus list_customers, find_customer_invoices, or propose_create_customer. No prerequisites, no exclusions, no mention of what happens if the CustomerNumber does not exist.

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, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: the figures are computed server-side from live Fortnox data and cover all pages, telling the agent the result is a complete, freshly derived dataset rather than a paginated raw listing. It does not discuss latency or freshness lag, but with an output schema present that is a minor omission.

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 compact sentences, front-loaded with the metric definition and followed by the example question and provenance. The Fortnox API URL is marginal filler, but the rest 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 an aggregate analytics tool with an output schema and fully documented parameters, the description supplies what an agent still needs: what is measured, over what data source, and with full-pagination coverage. Only sibling differentiation 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 both the optional customer number and the fromdate default (one year back) are already documented in the schema. The description adds nothing about parameters, which is acceptable given the coverage but means it brings no extra semantic value here.

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

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

The description defines a specific computed metric set: how late each customer pays relative to the due date, plus the trend (improving/worsening). That is much more precise than the title alone. It does not, however, contrast itself with overlapping siblings such as get_receivables_aging, check_payment_details, or get_payment_list, 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?

An example question ("Vilka kunder betalar sent? Blir någon sämre på att betala?") implies when the tool applies, which is useful. There are no explicit when-not conditions and no routing guidance among the many receivables/payment siblings, so selection remains partly inferred.

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, so the safety profile is covered. The description adds real value beyond that: results are computed server-side from live Fortnox data and are aggregated "over all pages", which tells the agent pagination is already handled and the figures are current rather than cached.

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 in the first clause, followed by an example and provenance in a compact three-sentence block. The Fortnox API URL is marginally useful decoration but does not bloat the definition meaningfully.

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

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

With an output schema present and full parameter documentation, the description only needs to orient the agent, which it does via purpose, example, and data provenance. The remaining gap is minor: "avvikelse" is never defined (absolute SEK difference vs. percentage), and the relation to get_deviations_vs_last_year is left implicit.

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 six parameters (top, month, compare_to, from/to_account, date) are documented in the schema with their defaults. The description adds only the "konto för konto" framing and result ordering, not parameter semantics, 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?

"Avvikelser per månad: konto för konto mot föregående månad, största förändringen först" names a specific verb/operation (account-by-account deviation), the exact comparison baseline (previous month), and the result ordering. This is clearly distinguishable from the sibling get_deviations_vs_last_year 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?

The embedded example question ("Vilka konton sticker ut den här månaden jämfört med förra?") gives an explicit usage cue, so an agent can match a user intent to this tool. It stops short of naming the sibling alternative (get_deviations_vs_last_year) or stating when-not-to-use, so it does not reach 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond them: results are computed server-side from live Fortnox data and span all pages, so the agent knows pagination is already handled and the data is current.

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 segments: definition, example question, provenance note. No filler sentences. The mixture of Swedish body text and English parameter docs is slightly awkward but does not cost space.

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

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

An output schema exists, so return values need no prose. With annotations covering safety and the schema covering all four parameters and their defaults, the description adds exactly the missing pieces: sort order, data freshness, and full-page coverage.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's "konto för konto" hints that from_account/to_account bound the range, but it adds no detail on the top-N cap or how the date parameter selects the comparison year beyond what the schema already says.

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 operation: an account-by-account comparison against the prior year, ordered by largest change first. The verb+resource+scope are clear. It does not explicitly distinguish itself from the sibling get_deviations_vs_last_month, which is the one obvious confusion risk.

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 embedded example question ("Vilka kostnader har ökat mest mot förra året, och varför?") implicitly signals the use case without naming when not to use it. There is no reference to the near-identical get_deviations_vs_last_month sibling, so the agent must infer the choice from the tool name alone.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint, so safety is covered; the description adds what matters beyond that — the return is a download link, non-listed operations are rejected, and the upstream API spec is cited. It omits auth/permission expectations and says nothing about what happens on an invalid company_key or missing document.

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

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

Two sentences, front-loaded with the action and outcome; the parenthetical enumeration of supported document types is dense but earns its place by defining scope. The Fortnox API URL is arguably filler for an agent that already knows the connector.

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

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

It correctly describes the return (a download link), which is important since no output schema exists, and it bounds accepted operations. But for a 7-parameter generic dispatcher with nested objects and no parameter documentation, an agent still cannot tell what company_key means, how path_params/query_params are used, or how to enumerate valid operation_ids.

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

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

Schema description coverage is 0% across 7 parameters, so the description must carry the burden and it only covers operation_id (with one example, "more:aldersanalys_kund"). company_key, expand, fields, summarize, path_params and query_params — including the nested summarize object — receive no explanation at all, and there is no hint on how to discover valid operation_ids.

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 outcome ("give the person a download link") plus a concrete resource set (invoice/offer/order PDF, SIE, archive, inbox, xlsx reports) and the selector (operation_id). Sibling differentiation is only implicit — it never says how this differs from get_invoice_pdf, read_sie_file or download_archive_file — 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 a clear when-not boundary ("Any other operation is refused") and an example operation_id format, which is genuinely useful for a dispatcher tool. It never names the alternative sibling tools to use when the operation is refused, so the routing guidance is incomplete for an agent that has ~70 sibling tools.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds that the value is computed server-side from live Fortnox data spanning all pages, which is useful, but says nothing about latency, aggregation rules, or what happens when only one company exists.

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: the definition is front-loaded, the example question follows, and the data-source note is last. Little waste, though the API URL is marginal for an agent that cannot browse it.

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

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

An output schema exists so return values need not be described, and the description covers scope, elimination logic, data source and pagination. Only the multi-company precondition and behavior when no group exists are 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% with a single optional 'date' (ÅÅÅÅ-MM-DD to select fiscal year) documented in the schema itself. The description adds no further meaning about the date parameter or its default behavior, 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 concrete operation: group companies summed with internal invoices eliminated and reported, plus an example question that pins down the intent. It implicitly distinguishes itself from plain balance-sheet/result siblings via the intercompany elimination, though it never names them.

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

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

The example question ('Hur ser koncernen ut sammanlagt, utan handeln mellan bolagen?') gives an implied trigger, but there is no explicit when-to-use vs. get_balance_sheet, get_profit_and_loss or get_key_figures, and no stated preconditions such as requiring multiple connected companies.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds the underlying Fortnox GET endpoint and docs URL, which is modest context, but it gives no operational behavior such as error cases, auth needs, or whether it returns file content versus metadata.

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

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

Two short sentences with the purpose front-loaded before the API endpoint. The docs URL is compact and no sentence 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 a documented single parameter and an output schema, return-value details are less critical, but the description omits selection context among many inbox/file siblings and does not resolve what the Id points to. That gap matters in this large sibling set.

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

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

The single required parameter has 100% schema description coverage, so the baseline is 3. The description only mirrors the {Id} path token and does not clarify the schema's confusing 'identifies the folder' wording or explain how to obtain the 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 names a specific verb ('Retrieve') and resource ('a single file'), and the endpoint /3/inbox/{Id} confirms lookup-by-ID. It does not distinguish this from similar siblings such as read_inbox_file or download_inbox_file, 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?

No sentence states when to use get_inbox rather than list_inboxes, list_unprocessed_inbox, read_inbox_file, or download_inbox_file. The agent must infer usage from the name and endpoint alone.

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

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

Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the result is computed server-side from live Fortnox data across all pages (so the agent need not paginate), and it explicitly surfaces negative balances, articles below reorder point, and items lacking a purchase price.

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 value proposition and the ledger reconciliation are front-loaded, followed by the exception categories and the example question. It is a single dense sentence plus an example; the example earns its place as a trigger, but the sentence is syntactically heavy.

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 rich annotations, an output schema and 100% parameter coverage, the description only needs to convey scope and behavior — which it does (all pages, server-side, live data, exception categories). Only the language mismatch with English tool/sibling names and the unmentioned 'top' limit keep it short of full completeness.

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

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

Schema description coverage is 100% and the single 'top' parameter (default 50) is documented in the schema, so the baseline of 3 applies. The description says nothing about 'top' or limits, adding no meaning 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?

The description names a specific verb+resource: inventory value per article and total, reconciled against the inventory account balance in the ledger. That framing clearly separates it from list_articles, get_balance_sheet or get_sales_by_article, though no sibling is named explicitly as an 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 embedded example question ("Vad är lagret värt, och stämmer det med bokföringen? Vad behöver vi beställa?") gives concrete situational triggers, including the reconciliation and reorder use cases. It stops short of stating when NOT to use the tool or naming a substitute for related questions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered. The description adds the underlying Fortnox endpoint (GET /3/invoices/{DocumentNumber}), which helps an agent map fields, but it doesn't add return shape, error behavior, or lookup ambiguity details beyond the annotations and 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?

Two short sentences, front-loaded with the action and resource, followed by a compact API reference. No wasted words.

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

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

With an output schema present and rich annotations, the description doesn't need to explain return values. It sufficiently identifies the tool and its lookup key. It could be slightly more complete by distinguishing itself from PDF and document-variant siblings, but 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 description coverage is 100% and there is only one parameter. The description repeats the DocumentNumber placeholder via the API path, adding only minor value over the schema's 'identifies the invoice'. Baseline 3 is appropriate when the schema already documents the 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+resource combination ('Retrieve a single invoice') so the agent can distinguish it from list_invoices or find_customer_invoices. However, it doesn't differentiate it from close siblings like get_invoice_pdf or read_invoice_document, which also target a single invoice record.

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

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

Usage is only implied: you call it when you have a DocumentNumber for one invoice. There is no explicit when-to-use vs when-to-use-something-else guidance, and no mention of alternatives such as list_invoices for discovery or get_invoice_pdf for the PDF form.

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 safety is covered. The description adds genuinely non-obvious behavior: it returns a link rather than the file, and the file never flows through the conversation – a distinction an agent could not infer from the schema or 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?

Three short sentences, front-loaded with what is returned and how it is delivered; the API path and docs link are compact supporting detail rather than 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?

Output schema and annotations carry the structural load, and the description covers the one thing they cannot: that the result is a downloadable link, not file content. The remaining gap is sibling disambiguation against read_invoice_pdf.

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 a single well-described parameter, so baseline is 3. The description only restates it as '{DocumentNumber}' in the API path and adds no format, sourcing, or lookup guidance 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+resource: fetching an invoice as a PDF, and names the concrete Fortnox endpoint. However, it never distinguishes itself from the sibling read_invoice_pdf (or get_invoice), so an agent cannot tell from this text which one to pick.

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

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

No explicit when-to-use guidance and no mention of alternatives, despite an obviously overlapping sibling (read_invoice_pdf). The only implicit cue is 'a link the person opens', which hints at human-facing delivery but is not framed as a selection rule.

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 safety is covered. The description adds genuinely new context: the figures are computed server-side from live Fortnox data and aggregated 'over all pages', telling the agent it need not paginate or stitch results itself. Return shape is left to the 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-loaded with the figure list, then a usage example, then implementation provenance — a sensible order with little filler. The Fortnox API URL is marginal noise that a reader gains nothing from.

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 one optional parameter, full schema coverage, an output schema, and annotations covering the safety profile, the description supplies everything an agent needs: what is measured, for whom, and that computation is server-side and complete. No material gap remains.

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

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

Schema description coverage is 100% and the single optional date parameter is documented there as a fiscal-year selector (ÅÅÅÅ-MM-DD). The description says nothing about the date parameter or what its absence means, so it adds no meaning beyond the schema — the baseline 3 for high coverage 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?

Enumerates the concrete figures returned (omsättning, resultat, marginal, kassa, kundfordringar, leverantörsskulder) and states scope as 'ett bolag eller alla', so the agent knows exactly what resource this produces. It does not differentiate itself from close siblings such as get_profit_and_loss, get_management_report or get_balance_sheet, which keeps it from a 5.

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

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

The example question ('Hur går det för bolaget just nu — i siffror?') gives a concrete trigger context for selecting this tool. No when-not conditions or named alternatives are offered, so an agent comparing it against the many other financial-report siblings must infer the boundary itself.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds value beyond that by stating the report is computed server-side from live Fortnox data and spans all pages, so the agent knows there is no pagination to chase and no client-side aggregation needed. It does not discuss cost/latency of a multi-page aggregation call, which 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?

Content and scope are front-loaded in the first clause, and the supporting sentences each add something (contents, example trigger, data source). The example question is slightly redundant with the enumerated contents but earns its place as an intent-matching cue.

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 rich annotations, a full output schema, and complete parameter documentation, the description only needs to convey scope and provenance — which it does, including the live-data source and full-pagination behavior. 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?

Schema description coverage is 100%, so the schema already documents both optional parameters (period formats and forecast weeks). The description adds nothing about parameter behavior, defaults, or accepted formats, so the baseline 3 applies.

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

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

The description names a concrete deliverable and enumerates its contents precisely: month/YTD result vs prior year, balance sheet, liquidity, key figures, and largest changes, in one response. That enumeration implicitly distinguishes it from granular siblings like get_balance_sheet or get_key_figures, but no sibling is named 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?

The example question ("Gör en månadsrapport till styrelsen för september") gives a concrete trigger for invocation and maps well to a board-reporting intent. There is no explicit guidance on when to prefer the granular sibling tools instead, so the alternative-routing half of the guidance is 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the result is computed server-side from live Fortnox data and aggregates over all pages, telling the agent there is no pagination or staleness concern. It does not describe failure modes or data-freshness latency.

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

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

Three short sentences, front-loaded with the definition, followed by the example and the data provenance. The example question largely restates the definition, which is mild redundancy but serves as a routing trigger, so the sentence still 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?

With an output schema present, return values need not be explained, and annotations fully cover safety semantics. The description supplies source-of-truth and scope ('all pages'), leaving only minor gaps around what counts as 'obokfört' or 'förfallet' and how they are grouped in the response.

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

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

Schema description coverage is 100% and the single optional date parameter is fully documented in the schema, including the default of today and the retroactive behavior for past dates. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

The description states a concrete composite output — unbooked items, unpaid items, and overdue items in a single answer — which is more specific than a generic 'report' label and implicitly differentiates it from single-concern siblings like get_payables_aging or get_receivables_aging. It stops short of naming those siblings explicitly, so an agent must infer the distinction.

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 embedded example question ('Gör en månadsgenomgång: vad är obokfört, obetalt och förfallet?') gives a concrete trigger, so usage is implied rather than stated. There is no when-not guidance and no named alternative for agents who only need one of the three components.

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 read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: results are computed on the server from live Fortnox data and aggregated 'over all pages', which tells the agent there is no partial-result or pagination pitfall.

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 resource and its dimensions, followed by a usage example and one provenance sentence. The API documentation URL is slightly incidental but short and harmless.

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

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

An output schema exists, so return structure needn't be described; the description covers what is computed, the data source and the all-pages aggregation. Minor gap: it never says what happens when 'date' is omitted (presumably current year) or how from/to_account interact with the default full P&L series.

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 explains the date (YYYY-MM-DD, selects the year) and the BAS account range for a custom series. The description adds nothing further about parameters, 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?

Names a specific resource and computation: revenue, costs and result per month, current year vs prior year, computed server-side from Fortnox data. The year-over-year, per-month framing distinguishes it in practice from period-P&L siblings like get_profit_and_loss, but no sibling is named explicitly.

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

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

The sample question ('Hur har omsättningen och marginalen rört sig månad för månad i år?') gives a concrete trigger for when this tool is the right pick. There is no explicit when-not guidance or routing to alternatives such as get_key_figures or get_multi_year_overview.

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 fully carried by structured data. The description adds genuinely useful behavior: results are server-computed from live Fortnox data and aggregated across all pages, and the horizon caps at twenty years. It does not cover latency, caching, or what happens when a requested year has no data.

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 metric list, then the example question, then provenance — a sensible order with no filler. The provenance phrase is slightly long for the value it adds, 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?

A rich output schema exists, annotations cover safety, and all params are documented in the schema, so the description only needs to establish scope and data provenance — which it does. The only real gap is the absence of sibling disambiguation among the several financial-reporting tools.

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

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

Schema description coverage is 100%, so all three parameters (fran_ar, till_ar, antal_ar) are already documented with format and defaults in the schema; baseline 3 applies. The description's 'upp till tjugo år i ett svar' corroborates the antal_ar maximum of 20 but adds no interpretation of how fran_ar/till_ar interact with antal_ar when both are supplied.

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

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

States a specific resource (multi-year overview) and enumerates exactly what it contains: intäkter, kostnader, resultat, likvida medel, eget kapital, soliditet per räkenskapsår. That is far more specific than the title 'Flerårsöversikt' alone. It does not, however, differentiate itself from overlapping siblings such as get_key_figures, get_management_report or get_profit_and_loss.

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 embedded example question ('Hur har det gått de senaste tio åren?') implies when to reach for it — long-horizon trend questions spanning many fiscal years. But there is no explicit when-not guidance and no named alternative, despite several siblings returning closely related financial aggregates.

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

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

The annotations already establish that this is a non-destructive, idempotent read operation. The description adds meaningful behavior beyond that: the output is a link the person opens, and the file itself is not transmitted through the conversation.

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 short and front-loads the key output behavior in the first sentence. The API endpoint and documentation URL are useful context, though the fragmentary first sentence is less polished than it could be.

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 one-parameter read operation with an output schema and full annotation coverage, the description supplies the essential missing context: the return is a link rather than file content. It could be slightly more complete by naming the relevant alternative for reading the PDF internally.

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% for the single DocumentNumber parameter, so the schema already explains that it identifies the offer. The description reinforces this indirectly via the API path but does not add substantial parameter-level guidance 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?

The description makes clear that the tool returns an offer as a PDF and specifically as a download link, not a file in the conversation. It identifies the resource well but does not explicitly differentiate from nearby siblings such as read_offer_pdf or list_offers.

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 implies the usage scenario by saying the link is opened by a person to download the file and that the file never passes through the conversation. However, it does not explicitly say when to choose this over read_offer_pdf or other PDF-related siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's real contribution is the delivery model: it returns a link, and "the file never passes through the conversation." That is genuinely non-obvious behavior that prevents an agent from expecting PDF bytes back. Gaps remain (link expiry, auth, failure modes), 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?

Three short sentences with the delivery model front-loaded and the API reference last; nothing is padded. The opening sentence is a noun fragment rather than a verb-led statement, which slightly weakens the lead.

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 full annotation coverage and an output schema, describing the link-based delivery and citing the underlying endpoint is close to sufficient. What is missing is differentiation from read_order_pdf and any note on link lifetime, which would matter operationally.

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%, establishing the baseline of 3. The description only implicitly adds meaning via the endpoint template /3/orders/{DocumentNumber}/preview, which usefully implies the parameter is the order's document number — and quietly contradicts the schema's own text "identifies the offer", a mismatch the description never explicitly corrects.

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 order as a PDF" names the resource but never states the action as a verb; the intent (fetch a downloadable link) only emerges from the second sentence. It also fails to distinguish itself from the very similar siblings get_offer_pdf, get_invoice_pdf and especially read_order_pdf, so an agent cannot tell from the description which PDF accessor to pick.

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

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

There is no when-to-use guidance, no prerequisite stated (e.g. requiring a known DocumentNumber), and no mention of the sibling alternatives such as read_order_pdf or get_fortnox_document. The agent must infer selection purely from the tool name.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: results are 'computed on the server from live Fortnox data' and aggregate 'over all pages', telling the agent there is no client-side pagination or syncing to worry about.

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 content is front-loaded and short: scope first, example question second, data provenance last. Minor waste in that the opening clause restates the title verbatim, and the Swedish/English mixing adds slight friction, but nothing is padded.

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

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

With annotations and an output schema present, the description only needs to establish scope and data provenance, which it does. The remaining gap is sibling differentiation against list_due_dates and get_receivables_aging, which an agent might reasonably hesitate between in a tool list this dense.

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

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

Schema description coverage is 100% and the single optional 'date' parameter is fully documented in the schema, including the YYYY-MM-DD and month-end shortcuts. The description adds nothing about the parameter, so the schema does all the work — 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?

The first clause names a specific verb+resource pair: an aging analysis of supplier payables, broken down 'per intervall och per leverantör'. An agent can distinguish it from get_receivables_aging (customer side) by the word 'leverantörsskulder', but the description never explicitly contrasts it with list_due_dates or the receivables counterpart.

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

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

The 'Example question: "Vilka leverantörsfakturor har vi låtit förfalla, och hur länge?"' implies the use case well, but usage is conveyed only by example. There is no explicit when-to-use statement and no guidance on when to prefer list_due_dates or list_supplier_invoices instead.

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 description adds genuinely new operational context: results are computed server-side from live Fortnox data and span all pages, which tells the agent there is no pagination handling to do and the numbers are pre-joined rather than raw records.

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 sentence introducing the resource and its checks, followed by a concrete example question and a data-provenance note. Each element does distinct work and the key content is front-loaded.

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

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

An output schema exists, so return structure need not be explained, and annotations carry the safety profile. Combined with the check list, live-data provenance and all-pages note, an agent has enough to call it correctly; only explicit sibling routing is missing.

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

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

Schema coverage is 100%, and the single parameter 'dagar' is fully documented in the schema including default (7) and cap (60). The description adds nothing about the parameter, so baseline 3 is correct.

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 concrete resource – supplier invoices due in the coming days – and enumerates the specific analyses bundled into it (changed payment details, other bankgiro, duplicates, bank balance sufficiency). That is far more than a restatement of the name. It does not name its nearest siblings (get_payables_aging, list_due_dates, list_supplier_invoices), so differentiation is left implicit.

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 embedded example question ("Vad ska vi betala den här veckan? Är något konstigt bland fakturorna?") gives a clear situational trigger for selection. It stops short of explicit when-not guidance or naming an alternative, so it is clear context rather than full 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?

Annotations already declare read-only, idempotent, non-destructive and closed-world. The description adds genuinely new behavioral context: the figures are computed server-side from live Fortnox data and aggregated across all pages, so the agent knows results are complete rather than a single page and are not cached/stored data. That is real 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?

Three tight sentences: definition first, example scenario second, provenance third — appropriately front-loaded with zero filler. The example question is slightly verbose but does real work by illustrating intent.

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

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

With an output schema, full parameter documentation and rich annotations, the description only needs to cover scope and computation. It does both. Minor gaps: no statement of what period is used when date is omitted, and no differentiation from check_payroll, but for a single optional-param read tool this is close to complete.

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

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

Schema description coverage is 100% and the single optional date parameter carries its own YYYY-MM-DD explanation in the schema. The description adds only the granularity (per month and account group), not the semantics of the date parameter or what happens when it is omitted. 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 concrete resource and breakdown explicitly: personnel costs (salaries, pensions, social contributions) per month and per account group. That is specific verb+resource clarity. It stops short of naming which sibling it is not — check_payroll and get_profit_and_loss overlap thematically and the description doesn't draw 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?

The embedded example question ('Vad kostade personalen i år, och hur fördelar det sig...') gives a concrete usage scenario, which is better than nothing. However there is no explicit when-to-use/when-not guidance and no alternative sibling is named, so the agent must infer boundaries from the sibling list alone.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: results are computed server-side from live Fortnox data and span all pages, so the agent knows pagination is handled and data is current. It does not describe aggregation granularity or sorting, keeping it below a 5.

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

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

Three short sentences: the purpose is front-loaded, followed by an example and the data-source note. Nothing is redundant, and the API URL, while marginal, is compact and directly supports the 'live data' claim.

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

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

With an output schema present, return-shape explanation is not needed, and annotations plus 100% schema coverage handle safety and parameters. The description covers source, freshness and completeness of results; the remaining gap is routing guidance versus the closely related ledger/voucher tools.

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

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

Schema description coverage is 100%, with each of the six parameters documented (top default 40, date/fromdate/todate as YYYY-MM-DD, account as single/comma-separated/range, financialyear id). The description adds no parameter meaning 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?

The description states a concrete verb and resource: voucher rows (verifikationsrader) in a period grouped by account, computed from Fortnox data. It is clearly distinguishable from list_vouchers or get_voucher in that it returns account-grouped aggregates rather than individual vouchers, though it never names 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?

Usage is conveyed only through an embedded example question ('Kontrollera konteringen på verifikaten i september'), which implies an audit/review scenario. There is no explicit statement of when to prefer this over get_account_ledger or get_voucher, and no exclusions or prerequisites.

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

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

Annotations already declare this as a safe, idempotent, non-destructive read, so the bar is lower. The description still adds real value by stating the figures are computed server-side from live Fortnox data and aggregated across all pages, plus that results include a prior-year comparison period.

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 definition, then period scope, then a concrete example, then data provenance. Every sentence carries information; the API URL is slightly incidental but small.

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

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

With an output schema present, the description needn't explain return values, and it covers period scope, comparison basis, and data freshness. Nothing critical for correct invocation is missing, though a hint on choosing between this and adjacent result reports would round it out.

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 date, period, fromdate/todate, and financialyear formats. The description only restates the period options at a high level and adds no syntax or precedence guidance beyond what the schema provides. Baseline 3 applies.

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

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

The description opens with a specific verb+resource: an income statement showing revenues and costs per account class. That clearly separates it from report siblings like get_balance_sheet or get_monthly_result, though it never names those alternatives 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?

Usage is implied through example questions ("show the P&L for March, how did Q3 compare to last year?") and the list of supported periods. There is no explicit statement about when to prefer this over get_monthly_result, get_key_figures, or get_management_report.

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, closed-world), so the description's real contribution is that the figures are computed server-side from live Fortnox data and aggregated over all pages. That tells the agent it is pre-aggregated and needs no pagination loop, which is useful context not present in structured fields.

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 compact sentences: purpose first, then an example question, then provenance. The example is somewhat illustrative rather than load-bearing, but nothing is padded and the key claim is front-loaded.

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 one-optional-parameter read tool with an output schema and rich annotations, the description supplies everything an agent needs to select and call it: what it returns conceptually, that it is live data, and that it spans all pages. Only sibling disambiguation 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?

There is a single optional date parameter with 100% schema description coverage, and the schema already explains the YYYY-MM-DD / YYYY-MM forms and the default of today. The description adds no syntax, timezone, or interpretation detail beyond that, so the schema-baseline of 3 applies.

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

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

The description names the resource and the shape of the output ('förfallet per intervall och per kund' – overdue by bucket and by customer), which lets an agent distinguish it from the payables counterpart. It never explicitly names get_payables_aging as the sibling it is not, 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?

Usage is only implied, via an example question about how much is overdue, how old it is, and which customers account for most of it. There is no explicit when-to-use, when-not, or routing to adjacent tools such as get_payables_aging or list_due_dates, which overlap on due-date information.

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 read-only, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description still adds real context beyond them: the figures are computed server-side from live Fortnox data and span all pages, telling the agent results are current and fully paginated rather than a single page snapshot.

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 example questions are front-loaded, but the description packs three loosely joined clauses plus an API documentation URL into one run-on sentence, and mixes Swedish with English mid-sentence. The Fortnox API link earns little for an agent that cannot browse.

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

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

With an output schema present the description need not document return values, and annotations plus full schema coverage carry safety and parameter detail. The description completes the picture with data source, freshness, and pagination behavior; only the relationship to sibling result tools is left implicit.

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 four parameters (top, date, dimension, financialyear) are already documented in the schema, including the kostnadsstalle/projekt values and defaults. The description adds nothing about parameter behavior beyond the 'all pages' note, 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?

The description names a specific verb and resource: result (revenues, costs, profit) per cost center or project, drawn from accounting object balances. That scope distinguishes it from aggregate siblings like get_profit_and_loss or get_monthly_result by implication, though those siblings are never named.

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?

Two example questions ("Hur går det för varje projekt i år?" and "Vilket kostnadsställe kostar mest?") give clear routing context for when to reach for this tool over a plain P&L. The description stops short of naming alternatives or exclusions, which keeps it at 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 cover read-only, idempotent, non-destructive, closed-world. The description adds real value beyond them: results are computed server-side from live Fortnox data, all pages are traversed automatically, and contribution margin is only available 'där inköpspris finns' – an important data caveat an agent won't find in the annotations.