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

Annotations already declare readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real behavioral context: no date-window restriction, a pagination ceiling via max_pages, and the important caveat that zero hits is not proof of uniqueness. It stops short of saying how matches are returned or whether pagination truncation is signalled.

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 dense sentences with no filler; the match criteria come first and the caveats follow. It is efficient, though the three caveats are packed into a single trailing sentence rather than being signposted.

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

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

There is no output schema, so the description should say what a result looks like — a list of matching purchase objects, with IDs, is never stated. Combined with undocumented required parameters and the currency-unit ambiguity, the definition is serviceable but leaves gaps an agent must guess at.

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

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

With 0% schema description coverage, the description must carry parameter meaning, and it only partly does: it explains the OR-relationship between invoice_number and gross amount/date, and names max_pages as a search cap. It leaves company_slug, supplier_id, document_date format, and the fact that gross_ore is in øre (it says NOK gross amount) unexplained.

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 (find duplicate purchases for a supplier) and spells out the exact match logic: same invoice number OR equal NOK gross amount plus date. That level of specificity separates it cleanly from siblings like fiken_list_purchases or fiken_get_purchase, which merely retrieve purchases.

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 states the search is unbounded by date and capped by max_pages, and explicitly lists what is out of scope (drafts/inbox, other supplier IDs). That gives clear conditions for using it, though it never names an alternative tool to use when the caller wants draft/inbox coverage or a plain listing.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on which company fields are returned, on access to other companies, or on failure behavior for an unknown slug.

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 short sentence with zero waste, front-loading the verb and resource. It is efficient but almost too terse given the schema gap.

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

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

For a simple single-parameter read tool with full annotation coverage and no output schema, the definition is minimally adequate. It does not clarify the slug format or what 'details' encompasses, which would matter for correct invocation.

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

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

Schema description coverage is 0%, so the only parameter (company_slug) is undocumented in the schema. The description weakly indicates it is a Fiken company identifier, but gives no format, casing, or example, leaving the agent to guess the slug's shape.

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 ("Hent detaljer om et foretak") plus the key identifier (company_slug). This cleanly separates it from the list-style sibling fiken_list_companies, though it never names that sibling 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?

No when-to-use or when-not-to-use guidance. The agent can infer this is the single-company lookup versus fiken_list_companies, but the description never states that condition or any prerequisites (e.g. obtaining a slug first).

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, so the safety profile is fully covered and the description only needs to add context. It adds that the response contains organisation number, but says nothing about behavior when the contact ID is unknown or the slug is wrong. A 3 is appropriate with annotations doing most of the work.

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 short sentence with no filler and the key resource front-loaded. It is efficiently sized, though efficiency here partly reflects under-specification rather than disciplined editing.

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

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

No output schema, no annotation gaps, but two undocumented required parameters and no statement of what fields come back beyond organisation number. For a lookup tool keyed on company slug plus contact ID, the definition should clarify scoping and failure behavior.

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% for both required parameters, so the description carries the full explanatory burden — and it provides none for contact_id or company_slug. The parameter names are conventional enough that an agent can guess, but the definition adds no meaning about identifier scope or company scoping.

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 ('Les') and a specific resource (leverandør-/kundedetaljer plus organisasjonsnummer), which distinguishes it from write tools and from the bulk sibling fiken_list_contacts. It stops short of saying explicitly that it retrieves one contact by ID, leaving the singular-vs-list distinction to be inferred from the name.

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 statement and no reference to alternatives such as fiken_list_contacts, even though that sibling is the obvious routing choice for the same resource. An agent must infer the distinction 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true. The description adds a meaningful behavioral warning that the returned content is data, not instructions, but it does not describe output format, error behavior, or authentication requirements.

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

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

The description is two short sentences, front-loaded with the tool's purpose. Both sentences carry useful information: one states what is read, the other warns about content trust.

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

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

With no output schema and 0% parameter description coverage, the description should explain the required inputs and expected return shape. It only says 'structured lines' and provides no parameter semantics, leaving an agent under-equipped to invoke the tool correctly.

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

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

There are two required parameters, company_slug and document_id, with 0% schema description coverage. The description does not mention either parameter or explain their meaning, so it does not compensate for the missing schema documentation.

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: reading structured lines from an EHF. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like fiken_list_ehf or fiken_read_document.

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 tool versus alternatives such as fiken_list_ehf. The second sentence is a security note about treating content as data, not instructions, which is useful but not usage 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 readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds only that it returns metadata and a source-ID, with no detail on permission needs, what the metadata contains, or error behavior when the document ID is unknown.

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 short sentence with no filler, and the key outcome (metadata and source-ID) is front-loaded. Its brevity becomes under-specification rather than elegance, but the sentence itself wastes nothing.

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?

Mentioning the return content (metadata plus source-ID) is valuable given there is no output schema, and it implies a follow-up path to reading the document. Still, for a tool with two undocumented parameters and no annotation on data scope, the description does not fully equip an agent to call it correctly or know its limits.

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% and both parameters (document_id, company_slug) are documented only by their titles. The description does not clarify that document_id refers to an inbox item identifier or what company_slug represents, leaving the agent to infer identifier formats and scoping.

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: fetch metadata and source-ID for a single inbox document, which is more precise than the bare tool name. However, it never distinguishes itself from close siblings such as fiken_read_document or fiken_list_inbox, so an agent must guess which retrieval variant applies.

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 indication of when to use this versus fiken_read_document, fiken_list_inbox, or fiken_read_purchase_attachment. No preconditions, no note about whether the document must first be located via fiken_list_inbox.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds nothing beyond that – no note on what is returned, error behavior for a nonexistent invoice_id, or whether company_slug must be a valid Fiken company.

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 short sentence with zero padding, but its brevity reflects under-specification rather than efficiency. It is also in Norwegian while the tool name and siblings are English, a minor consistency friction.

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

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

No output schema exists and parameter documentation is absent, yet the description explains neither the returned invoice structure nor the role of the required company_slug. For a two-required-parameter retrieval tool this leaves an agent guessing at one of the two inputs.

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 and largely does not: company_slug is never mentioned, and invoice_id is only labeled as the "Fiken" identifier without format or example. That label adds marginal meaning (Fiken-scoped ID vs internal ID) but leaves the required company_slug unexplained.

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 ("Hent én faktura") and the lookup key ("etter Fiken invoice_id"). The word "én" signals single-record retrieval, implicitly distinguishing it from fiken_list_invoices, though no sibling is 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?

Usage is only implied: the singular "én" suggests fetching a known invoice rather than browsing, and the sibling list fiken_list_invoices exists for the latter case. No explicit when-to-use, when-not, or prerequisite guidance is 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 declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds genuine value by disclosing that the response includes lines and attachments, which is not in any structured field. It omits what an attachment uuid is or where to obtain it, which the follow-on instruction depends on.

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 core operation front-loaded and the cross-reference trailing. No padding, though the second sentence is ambiguous enough that its brevity costs more than it saves.

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 tool with an output shape briefly described (lines and attachments), this is close to adequate. But with 0% schema coverage and no output schema, the unexplained company_slug and the ambiguous uuid reference leave an agent guessing about inputs.

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 both parameters, and it does not. It never explains company_slug, and its mention of 'uuid' actually risks confusion since journal_entry_id is typed as an integer, not a uuid. The reader cannot tell what identifier is required or how the uuid relates to journal_entry_id.

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

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

States a specific verb and resource: 'Les én journalpost med linjer og vedlegg' (read one journal entry with lines and attachments). The singular 'én' implicitly distinguishes it from fiken_list_journal_entries, though the sibling is not named. Clear enough to select 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?

Points to a follow-on tool ('Bruk uuid med fiken_read_journal_entry_attachment'), which gives partial routing guidance. However, it never states when to use this instead of fiken_list_journal_entries or what prerequisites exist (e.g. needing a valid journal_entry_id from a list call). Usage is implied rather than specified.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds content-level context by saying the response includes posting lines, supplier and payment data, but there is no output schema for this and no mention of error behavior, required permissions, or format.

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, tightly packed sentence with no filler, stating the verb, the resource and the expected payload up front.

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 single-entity tool with no output schema, the description does tell the agent what comes back, which is valuable. However, it leaves the parameters unexplained and gives no routing context relative to the many sibling purchase tools, so it is only minimally sufficient.

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% and neither parameter is documented in the schema or the description. The description does not explain that purchase_id identifies a specific purchase or what company_slug means, so an agent gets no semantic grounding for the two required inputs.

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 ('Les ett kjøp') and enumerates what the read returns: konteringslinjer, leverandør, betalingsinformasjon. This clearly distinguishes it from the singular-read sibling fiken_list_purchases, though the differentiation is implicit rather than stated.

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, when-not-to-use, or alternative guidance is given. Nothing tells the agent when to prefer this over fiken_list_purchases, fiken_get_purchase_draft, or fiken_purchase_history; the agent must infer usage purely from the name and the plural 'list' sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered elsewhere. The description adds no behavioral context beyond that — no word on error behavior for a missing draft, what the 'details' comprise, or any access constraints.

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 short sentence with no filler, and the resource is front-loaded. Brevity here is not the problem; the missing content is captured under other dimensions.

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

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

No output schema exists, so the description should at least indicate what reading a draft returns and what the two required identifiers mean. With 0% parameter documentation and no return-value hint, an agent must guess at both input and output for a real multi-tenant API.

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 both parameters and it carries neither. 'draft_id' is only weakly implied by 'kjøpsutkast', and 'company_slug' — non-obvious in a multi-company API — is completely unaddressed.

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 ('Les' / read) plus resource ('kjøpsutkast' / purchase draft), so an agent can tell it fetches a single existing draft rather than listing them. It does not name or contrast the sibling fiken_list_purchase_drafts, and 'detaljer' is vague about what is actually returned.

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?

Nothing states when to prefer this over fiken_list_purchase_drafts or fiken_get_purchase, nor what precondition (an existing draft_id) is required. Usage is only inferable from the name and the word 'eksisterende'.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful, non-obvious convention — that amounts are normally expressed in øre — which is real behavioral context beyond the annotations. It still omits pagination behavior despite page/page_size existing, and does not say whether balances are as-of the given date.

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 sentence with the verb front-loaded and no filler. It is efficient, though the extreme brevity is partly under-specification rather than pure conciseness.

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 list tool requiring a date plus an account range and paging, the description says nothing about whether the date is an as-of balance date, how account ranges are interpreted, or how results are paged. With no output schema and no annotations covering semantics, the description leaves most of the contract for the agent to guess.

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

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

With 6 parameters at 0% schema description coverage, the description carries the full burden, yet it never mentions date, from_account, to_account, page or page_size. The øre note addresses amount representation rather than any parameter, leaving every input undocumented in both schema and text.

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 specific verb and resource ('List kontosaldoer' = list account balances), which is clearly understandable even though it is written in Norwegian. It does not distinguish the tool from close siblings such as fiken_list_accounts or fiken_list_bank_balances, so an agent must infer which 'balances' listing applies.

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 statement of when to use this tool, when not to, or which sibling to prefer (list_accounts vs list_bank_balances). The only guidance is an implicit domain hint via the øre unit convention, which does not help the agent choose the 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered structurally. The description adds only that the account set can be narrowed, but discloses nothing about pagination behavior, default page size, or how results are ordered – moderate value over 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?

A single compact sentence, front-loaded with the verb and resource. Nothing wasted, though its brevity comes at the cost of substance rather than being a model of efficiency.

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 5-parameter, list-style tool with 0% schema coverage and no output schema, the description omits the pagination model and the meaning of the account-range parameters. An agent would have to guess at how from_account/to_account behave and how to page through results.

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% with 5 parameters, so the description must compensate and largely does not. 'Optional account restrictions' vaguely gestures at from_account/to_account but never explains range semantics, inclusivity, or format, and says nothing about page, page_size, or company_slug.

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 clear verb+resource: list accounts in the chart of accounts, with optional account restrictions. An agent knows what it retrieves. It does not, however, distinguish this from the sibling fiken_list_account_balances (balances vs. master data), which is a meaningful ambiguity in an accounting context.

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 statement of when to use this versus fiken_list_account_balances or fiken_list_account_balances-style siblings, and no prerequisites such as needing a company_slug resolved first. The only usage hint is the implicit 'optional restrictions' phrase, which is not guidance about tool 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, destructiveHint=false, and openWorldHint, so the safety profile is fully covered structurally. The description adds essentially no behavioral context: nothing about pagination defaults, whether all accounts are returned or only bank-type ones, or that a company_slug is required to scope results.

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 short sentence with no filler, but it is under-specified rather than concise; the limited content is front-loaded but the description also mixes Norwegian domain jargon into an otherwise English tool ecosystem.

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 paginated, company-scoped list tool with no output schema and no parameter documentation needs at least a note on required company_slug and paging. Given 3 params at 0% coverage and no return-value description, the definition is not complete enough for confident invocation.

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

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

Schema description coverage is 0% and none of the three parameters (company_slug, page, page_size) are mentioned in the description. The required company_slug scoping and pagination behavior are left entirely undocumented, so the description fails to compensate for the schema gap.

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

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

States a specific verb and resource: list actual bank accounts and account codes. It does not differentiate from nearby siblings such as fiken_list_accounts or fiken_list_bank_balances, and the trailing purpose phrase 'for vurdering av motkonto' is vague, so an agent must guess which listing tool 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?

The only usage signal is the fragment 'for vurdering av motkonto', which implies a reconciliation/contra-account scenario but never says when to use this instead of fiken_list_accounts, fiken_list_bank_balances, or fiken_list_companies. No prerequisites, no exclusions, no alternatives.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety and idempotency are covered. The description adds only the date format requirement, which is somewhat useful. It says nothing about pagination defaults/behavior or what happens when no balances exist for a given date, which would be valuable for a paged open-world list tool.

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

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

A single short sentence with the resource stated first and the optional modifier second — well front-loaded and free of padding. It is arguably too terse rather than too long, but the structure itself is clean.

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?

This is a 4-parameter tool with 0% schema documentation and no output schema. With annotations covering safety but nothing explaining company_slug, pagination, or the shape of returned balances, the definition leaves too much for the agent to infer before a correct call.

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 4 parameters. The description rescues only the 'date' parameter by specifying the YYYY-MM-DD format, but page, page_size (default 100) and especially company_slug — the sole required parameter — get no explanation of what a slug is or where to obtain it. The coverage gap is not compensated.

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 plus resource ('List banksaldoer' – list bank balances) and states the optional date scoping. It is understandable but written in Norwegian, and it doesn't distinguish itself from close siblings like fiken_list_bank_accounts or fiken_list_account_balances, so an agent must infer the difference between 'balances' and 'accounts'.

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

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

The description implies usage through the optional date parameter ('eventuelt for en dato'), which signals a point-in-time vs current balance behavior. However, it offers no explicit when-to-use guidance and never names alternatives such as fiken_list_bank_accounts (listing the accounts themselves) or fiken_list_account_balances (general ledger balances), leaving the agent to guess among several similar list 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds one genuinely useful behavioural fact not in the annotations: results are restricted to companies the user has authorized via OAuth. It says nothing about pagination behaviour or result size, which matters for a paged list 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?

It is a single, front-loaded sentence with no filler, which is good. However, the extreme brevity is under-specification rather than efficiency — the sentence could carry the paging and discovery-role information at almost no cost.

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 root-level discovery tool with no output schema, the description should at least indicate what a company record contains (e.g. name and the identifier required by sibling tools) and how paging works. Neither is present, so an agent cannot tell what it will receive or how to iterate.

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% and the description never mentions the two parameters ('page', 'page_size') or their defaults. The schema titles and defaults give minimal hints, but the description does no compensating work on paging semantics or maximum page size.

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 specific verb (list) plus a scoped resource: the companies ('foretak') the user has granted OAuth access to. That scope distinguishes it from sibling tools that operate on a single company (fiken_get_company) or on sub-resources, although no sibling is named explicitly. The only friction is that the description is in Norwegian while the tool name and schema are in English.

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: listing accessible companies is obviously a discovery step, but the description never says 'call this first to obtain the company identifiers the other tools need', nor does it name any alternative or exclusion. An agent must infer the prerequisite role from the OAuth-scoping phrase 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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds no behavioral context of its own: no mention of pagination semantics (page defaults to 0, page_size to 100), no note on result volume, and no statement about how empty filters behave.

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 well-formed sentence with no filler, front-loading the action and resource. It is efficient but so terse that conciseness shades into under-specification for a five-parameter tool.

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

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

With five parameters, zero schema description coverage, no output schema and a required company_slug, the definition is far too thin. An agent cannot tell how to page through results or what the required company scoping parameter is for.

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 carries the full burden, yet it only names two of five parameters (name, email) with no format guidance. company_slug, page and page_size – including the fact that company_slug is required – are completely unaddressed.

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 (Søk/search) and resource (kunder og leverandører = customers and suppliers) plus the searchable fields (navn, e-post). This distinguishes it from fiken_get_contact, which retrieves a single contact. However, the tool name says 'list_contacts' while the description says 'search', and the description never mentions the company_slug scoping that dominates 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?

No indication of when to use this versus fiken_get_contact or the other list tools. It also omits that name/email default to empty strings, meaning an unfiltered call returns all contacts – a crucial usage distinction the agent must infer from the schema defaults 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 openWorld, so the safety profile is covered. The description adds a little context beyond that — that these are *received* documents carrying *structured* voucher data, which distinguishes them from raw attachments — but it omits pagination behavior and the important fact that the default status filter suppresses processed/deleted items.

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 well-formed sentence with no filler, and the key identifying words are front-loaded. It is efficient, but efficient at too low a level of detail for a paginated, status-filtered list tool.

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

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

With 4 undocumented parameters, no output schema, and a status enum whose values are unexplained, the description leaves the agent guessing about paging and filtering. For a query tool whose whole behavior is determined by those parameters, considerably more text is warranted.

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%: none of the four parameters (page, page_size, status, company_slug) has documented meaning in the schema. The description supplies no compensating information — no mention of paging semantics, page numbering base, or what each status enum value actually selects.

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 ("list") and a specific resource ("mottatte EHF-fakturaer og kreditnotaer" — received EHF invoices and credit notes), so the agent knows this is an inbound-document listing rather than an outgoing-invoice or single-document tool. It does not explicitly name siblings like fiken_list_invoices or fiken_get_ehf, so differentiation is inferable but not stated.

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 is given: nothing says to prefer this over fiken_list_invoices for outbound invoices, or over fiken_get_ehf for a single document. Critically, the schema's status parameter defaults to "unprocessed", meaning processed and deleted documents are hidden unless the caller changes it, and the description never hints at this filtering behavior.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the workflow hint about reading before posting. It says nothing about pagination behavior, the default filtering that occurs when status is omitted, or result ordering.

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 immediately by the next-step routing. No filler. It is arguably under-specified rather than over-long, but every included sentence 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?

A read-only list tool with annotations and no output schema has modest requirements, but four parameters at 0% schema coverage — including a default-filtering enum — leave the agent guessing about what it will actually receive. The description should at minimum explain the unused/all/used distinction and pagination defaults.

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% for four parameters, so the description carries the full explanatory burden and provides none of it. Most critically, the status enum (all/unused/used) defaults to 'unused', meaning results are silently filtered unless the agent overrides it — a material semantic the description never mentions. page, page_size and company_slug are equally unexplained.

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 ('List bilag i innboksen' – list vouchers in the inbox), clearly narrower than fiken_list_journal_entries or fiken_list_transactions. It also routes to fiken_read_document for content, giving a concrete next step. It does not explicitly contrast with fiken_get_inbox_document, so sibling differentiation within the inbox family is incomplete.

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?

'Hent innholdet med fiken_read_document før kontering' gives explicit workflow guidance: list here, then read the document before posting. That is a real when-to-use chain. However, there is no guidance on when not to use it, nor on how to choose between the status values or when to page.

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 the date-format contract and confirms filtering semantics, but says nothing about pagination behavior, defaults, or ordering of results.

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 short sentence with the resource up front and the format constraint appended; nothing is wasted. It is arguably over-compressed for an 8-parameter tool, but the structure itself is sound.

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 8 undocumented parameters, no output schema, and two distinct date families plus pagination, this description is not sufficient for correct invocation. The agent would have to guess at paging defaults and which date field applies.

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 8 parameters, so the description must carry the meaning. It conveys only that date filters exist and use YYYY-MM-DD, leaving page, page_size, company_slug, settled, and the crucial due_date vs issue_date distinction completely unexplained.

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?

'List fakturaer' states a specific verb and resource, and the mention of date and paid filters scopes it further. It does not, however, distinguish it from siblings like fiken_list_sales or fiken_get_invoice, so an agent still has to 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 description names the available filters but gives no guidance on when to choose this tool over fiken_get_invoice for a single record or fiken_list_sales for related data. There are no prerequisites, exclusions, or alternative-routing hints.

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, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds only that date scoping is optional and its format; it says nothing about pagination behavior despite page/page_size existing, which is a meaningful omission for a list 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?

One short sentence with the resource first and the optional constraint second — front-loaded and waste-free. It is arguably too terse rather than verbose, which is not a conciseness fault.

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 5-parameter, 0%-coverage listing tool with no output schema, the description only addresses the date filter. Pagination semantics and the required company_slug — the one mandatory argument — are left entirely to the agent's guesswork.

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 5 parameters, so the description carries the burden. It does explain the date bound format (YYYY-MM-DD) for date_from/date_to, but company_slug, page, and page_size get no mention at all, leaving most parameters undocumented in both places.

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 ("List") and resource ("journalposter"), so an agent knows this is a collection-listing operation rather than a single-record fetch like fiken_get_journal_entry. It does not explicitly call out that distinction, but the verb+resource pairing is unambiguous.

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?

"eventuelt avgrenset på dato" only indicates that date filtering is optional; it never says when to prefer this tool over fiken_get_journal_entry or fiken_list_transactions, nor any prerequisites. The agent is left to infer usage context entirely.

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, so the safety profile is covered. The description's only added behavioral value is implying each returned item carries a uuid consumable by the read tool; it says nothing about pagination, result count, or empty-list 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?

Two short sentences with zero filler, and the core action is front-loaded before the follow-up instruction. It is efficient, though the terseness leaves gaps that a slightly longer description could have closed.

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, no annotations gap but 0% schema coverage, the description should clarify the two required inputs and roughly what is returned. It gives only the action and one follow-up pointer, leaving company_slug semantics and result shape 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% for both required parameters (company_slug, purchase_id), and the description does not explain either of them — notably not the expected company_slug format. The 'uuid' mentioned is an output value, not an input, so it adds nothing to parameter semantics.

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 ('List') and resource ('bilagsvedlegg på et kjøp' – attachments on a purchase), which an agent can distinguish from fiken_get_purchase or fiken_read_purchase_attachment. The only weakness is that the resource noun is Norwegian while the tool name and schema are English, adding a small comprehension cost.

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?

'Bruk uuid med fiken_read_purchase_attachment' explicitly routes the agent to the correct sibling for fetching attachment content, which is the natural follow-up action. No when-not-to-use case is given (e.g., listing vs. reading), 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?

The annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so "Oppretter eller endrer ingenting" merely restates structured data rather than adding value. No extra behavioral context is supplied — nothing about pagination behavior, result volume, or what a draft record contains.

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 prose. The second sentence earns little of its place since it duplicates the annotations, but the description remains tight and scannable.

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

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

For a list tool with a required company_slug, pagination parameters, no output schema and 0% schema coverage, the description should at least explain paging and what is returned. As written it covers only the bare purpose, leaving the invocation details underspecified.

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% and the description says nothing about company_slug, page, or page_size, so the pagination contract and the required company scoping are undocumented in both places. The description does not compensate for the coverage gap at all, leaving the agent to guess defaults and semantics.

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 ("Les eksisterende kjøpsutkast" = read existing purchase drafts), which is unambiguous. It does not distinguish itself from the closely related siblings fiken_get_purchase_draft (single draft) or fiken_list_purchases (finalized purchases), so an agent must infer the boundary 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 statement of when to use this tool versus fiken_get_purchase_draft, fiken_list_purchases, or fiken_purchase_history, and no prerequisites are mentioned. The only hint is the implied read-only listing context, which the agent could already infer from the 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 and openWorld behavior, so the safety profile is covered. The description adds only the date-format hint and nothing about pagination defaults (page=0, page_size=100) or the existence of supplier filtering, so it contributes little beyond 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?

A single short sentence with the resource front-loaded and the optional filter second – no wasted words. It is efficient, though its brevity borders on under-specification rather than pure conciseness.

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

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

For a 6-parameter tool with no output schema and zero schema description coverage, the description should at minimum explain pagination and the supplier filter. It covers only the date range, leaving key parameters and result behavior 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% across 6 parameters, so the description carries the full burden. It documents the date format (YYYY-MM-DD) for date_from/date_to, but says nothing about page, page_size, or the supplier_id filter, which is a significant omission.

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 specific verb ('List') and resource ('kjøp/leverandørbilag' – purchases/supplier vouchers), which lets an agent distinguish it from the singular fiken_get_purchase. It does not explicitly differentiate itself from adjacent list tools like fiken_list_purchase_drafts or fiken_purchase_history, but the resource is clear enough.

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 phrase 'eventuelt avgrenset på dato' implies the date filter is optional, which gives minimal usage context. There is no guidance on when to choose this tool over fiken_list_purchase_drafts, fiken_purchase_history, or fiken_find_duplicate_purchases, and no mention of filtering by supplier.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context of its own — nothing about pagination defaults, result ordering, volume limits, or what a page of results contains — despite page/page_size parameters implying paginated delivery.

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 short sentence with zero filler, and the core action is front-loaded ahead of the optional constraint. Its brevity is appropriate structurally, though it borders on under-specification given the five-parameter schema.

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

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

With five parameters at 0% schema coverage and no output schema, the description should explain pagination behavior and the required company_slug. Instead it covers only the date filter, leaving an agent unable to call the tool correctly beyond the simplest case.

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 burden, but it only clarifies the date format (YYYY-MM-DD) for date_from/date_to. The three other parameters — page, page_size (default 100), and the required company_slug — receive no explanation of meaning, format, or constraints.

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

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

States a specific verb and resource ("List salg") plus an optional date scoping, so an agent knows it retrieves sales records. It does not differentiate from near-siblings such as fiken_list_invoices or fiken_list_transactions, leaving ambiguity about whether sales and invoices overlap.

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?

"eventuelt avgrenset på dato" only signals that the date filter is optional; it gives no indication of when to choose this tool over fiken_list_invoices or fiken_list_transactions. No prerequisites, exclusions, or alternative routing are provided.

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, so the safety profile is covered. The description adds nothing on top: no note about pagination defaults, result volume, ordering, or what a transaction record contains. It does not contradict the annotations, but it contributes no behavioral context.

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

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

The single sentence is short and front-loaded, but it is under-specified rather than concise: it contains no information beyond the tool name, and it is written in Norwegian while the tool name and siblings are English, adding a small comprehension cost with no payoff.

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 three parameters at zero schema coverage and no output schema, the description carries the full explanatory burden and delivers almost none of it. An agent cannot tell from this text how to paginate, what company_slug format to supply, or what a returned transaction looks like.

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 all three parameters (company_slug, page, page_size), and the description mentions none of them. The agent gets no explanation of what a company_slug is, whether page is zero-based (it defaults to 0), or what units page_size uses — all of which the description should compensate for and does not.

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 verb ("List") and a resource ("transaksjoner") which maps to the tool name, so the domain is identifiable. However it gives no scope or qualification, and with 28 sibling list/get tools it does nothing to separate itself from fiken_list_journal_entries, fiken_list_invoices, or fiken_list_sales beyond the bare resource noun.

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 mention of prerequisites (e.g. a valid company_slug), and no reference to any alternative tool. The only signal is the implied meaning of "list transactions", which the agent must infer from the 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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: results are a sample rather than authoritative data, and "complete=false betyr ufullstendig søk" tells the agent how to detect truncated results. It stops short of explaining pagination limits (max_pages) or auth needs.

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 with no filler; the scope and ordering lead, and the caveat about incomplete searches follows. Dense but imagery ("konteringslinjer", "kilde-ID") is left unexplained, slightly limiting immediate comprehension.

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 covers the key risk of the tool (treating sample history as authoritative) and hints at return shape despite no output schema. But for a 5-parameter, open-world read with 0% schema coverage, the missing date-range and page-limit guidance leaves the definition only partially 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 0% for five parameters, so the description must carry the burden. It only implicitly ties supplier_id to "samme leverandør" and explains the output-side complete flag, but says nothing about date_from, date_to, or max_pages semantics, leaving three parameters undocumented anywhere.

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?

A specific verb and resource ("Les tidligere kjøp fra samme leverandør") plus ordering ("nyeste først") and return contents ("kilde-ID og konteringslinjer"). It clearly differs from fiken_get_purchase and fiken_list_purchases by being supplier-scoped history, 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?

"Historikk er eksempler, ikke fasit" implies this is for orientation/reference rather than authoritative totals, which is useful guidance. However, it gives no explicit when-to-use versus fiken_list_purchases or fiken_get_purchase, and no exclusions or prerequisites are stated.

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

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

Annotations already declare read-only, idempotent, open-world, non-destructive, so the bar is lower; the description still adds real context the annotations cannot: a 15 MiB size cap and the warning that document text is untrusted data (a prompt-injection caution). It doesn't describe failure modes when a page is out of range or the document is not a PDF, which is the main 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?

Four short clauses, each carrying distinct information: scope, output type, the as_image rule with page numbering, the size limit, and the untrusted-data warning. Zero filler and the core action 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?

With no output schema, the description does supply what the call returns (page text or image), plus size limit, paging base and a safety caveat. Only the boundary behavior — invalid page, non-scanned image PDFs, auth scope for company_slug — is unaddressed.

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. It does explain page semantics (starts at 1) and as_image (scanned PDFs), covering two of four params, but company_slug and document_id are left entirely to their names.

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: read one page from an inbox document (innboksbilag), and clarifies the output is PDF text or an image. That distinguishes it from list-level siblings, though it never explicitly contrasts with fiken_get_inbox_document, which sounds adjacent.

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 one concrete usage rule: use as_image for scanned PDFs, and notes page numbering is 1-based. It offers no guidance on when to pick this tool over fiken_get_inbox_document or the attachment-reader siblings, so selection between close alternatives is left to inference.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds one genuinely useful behavioral note: the link is fetched from Fiken rather than produced by the model, which signals a trusted source. It does not explain what is returned (page image? PDF bytes? URL) or how pagination works.

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 tight sentences, action stated first and the trust caveat second. 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 no output schema, no parameter descriptions, and a binary/PDF-returning tool, the description leaves key gaps: what the call returns, how page/as_image behave, and how it differs from the other read_* siblings. Annotations cover safety but not these operational details.

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% and the description explains none of the five parameters (company_slug, journal_entry_id, attachment_uuid, page, as_image). With low coverage the description should compensate, but it only gestures at 'attachment' abstractly.

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: 'Les PDF/bilde fra en journalpost' (read PDF/image from a journal entry), with a concrete example ('inngående balanse'). It does not distinguish itself from the close siblings fiken_read_purchase_attachment or fiken_read_document, 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?

There is no guidance on when to use this versus fiken_read_document or fiken_read_purchase_attachment, nor on prerequisites or conditions. Usage is only inferable from the resource 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 and non-destructive, so the safety profile is covered. The description adds one genuinely useful behavioral fact: the link is resolved from Fiken rather than constructed by the model. It omits, however, what the tool actually returns (URL, base64, binary) and how page/as_image change the response.

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

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

Two short sentences, the core purpose front-loaded, and the link-provenance caveat second. 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?

A 5-parameter tool with 0% schema coverage, no output schema, and no explanation of return format, pagination (page) or image conversion (as_image). For a binary/document retrieval tool the description leaves the agent guessing about the response shape, which is a material gap.

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

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

Schema description coverage is 0% and all five parameters are undocumented. The description only faintly hints at format behavior via 'PDF/bilde' (relevant to as_image) and says nothing about page, company_slug, or the expected shape of attachment_uuid, so it does not compensate for the coverage gap.

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

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

States a specific verb (read) and a specific resource (attachment from an existing purchase), and clarifies the payload is a PDF/image. The resource scoping ('fra et eksisterende kjøp') distinguishes it from fiken_read_journal_entry_attachment, though the description never explicitly contrasts it with fiken_list_purchase_attachments or fiken_read_document.

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 guidance on when to use this versus fiken_list_purchase_attachments or fiken_read_document, and no prerequisite noted (e.g. that attachment_uuid must first come from the list tool). 'Eksisterende kjøp' only faintly implies the tool requires a pre-existing purchase.

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, the description discloses that Fiken GET checks may be performed, that local-only validation is possible, and that the tool never books or confirms tax correctness. This adds meaningful behavioral context without contradicting annotations.

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

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

The description is compact and front-loaded with the purpose, followed by operational caveats. Every sentence adds useful information, though it could be slightly more structured around parameters and outcomes.

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 tool has a complex nested input and no output schema, but the description never explains what validation results are returned or how failures are surfaced. It covers important behavioral boundaries well, but leaves a key completeness gap for an agent invoking it.

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 reported as 0%, so the description must carry the parameter burden. It explains check_fiken and the supplier_id requirement for duplicate search, but ignores max_pages and does not otherwise clarify the large nested proposal structure.

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: 'Kontroller et FULLSTENDIG konteringsforslag' and explains that it validates Claude-created proposals from attachments. It clearly distinguishes validation from booking by stating 'Bekrefter aldri ... bokfører noe', though it does not name a specific sibling alternative.

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

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

It gives useful conditions such as 'supplier_id kreves for duplikatsøk' and 'check_fiken=false gir bare lokal kontroll'. However, it does not explicitly say when to use this tool versus related tools like duplicate-finding or purchase-reading siblings.

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