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

Adds real behavior beyond the annotations: the approval coupling, rejection of a modified event, the fact that no payment or explicit completion marking occurs, and non-idempotent retry advice that reinforces idempotentHint=false. The 'no payment / no explicit completion' note is exactly the kind of side-effect boundary an agent cannot infer from readOnlyHint/destructiveHint alone.

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

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

Five short sentences, verb-first, each carrying distinct information — prerequisite, rejection rule, effect scope, retry warning. 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?

Behavioral and safety context is adequate, and without an output schema the description sensibly covers effects rather than returns. But for a mutation whose only input is a proposal_id, the absence of any explanation of that identifier or its relation to the Terminal approval leaves a meaningful invocation 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 the description never mentions proposal_id or how to obtain one; it instead talks about a 'selected Folio event', which does not map onto the parameter name. With one required, undocumented parameter the description should compensate 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 specific verb and resource — attach/upload an approved invoice attachment to a chosen Folio event — which is distinguishable from sibling reads (folio_read_attachment) and preparers (folio_prepare_invoice_assignment, folio_match_invoice). It stops short of explicitly contrasting with those siblings, and 'valgt Folio-hendelse' sits oddly against the single proposal_id parameter.

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

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

Gives concrete preconditions (requires an unused Terminal approval bound to the same file/event/profile) and an explicit when-not (do not retry when the outcome is unclear; a changed event is rejected). It never names an alternative tool to use instead, so it is strong on context but short of 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 cover read-only, idempotent, non-destructive behavior, so the description only needs to add context. It usefully specifies that the balance is for a particular date and includes both incoming and outgoing balance, but it does not mention permissions, historical limits, or error behavior.

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

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

The description is a single front-loaded sentence with no filler. Every element contributes to the stated purpose.

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 read tool with annotations and no output schema, the description gives the core operation but omits important context about the account parameter and the shape of the returned balance. It is minimally 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 0%, so the description must carry parameter meaning. It explains the date aspect (bestemt dato), but says nothing about the required account_number parameter or its expected format.

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 (read) and resource (incoming and outgoing balance) and adds date scope. It clearly differs from the sibling list/get tools, though it does not explicitly explain the per-account focus.

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 no guidance on when to use this balance lookup versus alternatives such as folio_list_transactions. There are no exclusions, prerequisites, or alternative-tool routing.

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

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

Annotations already declare 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 a 'category' contains, whether missing IDs error or return empty, or what the documentation requirements mean in practice.

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 waste and the resource front-loaded, but the brevity comes at the cost of substance rather than being earned concision. It reads as a title restated in sentence form.

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 no annotation gaps to excuse it, the description should explain what a category object and its documentation requirements look like. It does not, and it leaves the only parameter undocumented, so an agent cannot confidently invoke it end-to-end.

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 the single required parameter category_id, so the description carries the full burden — yet it never mentions the parameter at all. The agent cannot tell from either source what format a category_id takes (numeric, slug, prefixed) or where to obtain one.

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 verb ('Les' / read) and a resource ('Folios kategori'), plus an additional scope ('krav til bilagsdokumentasjon' — documentation requirements). However, it is terse and does not distinguish this from siblings such as folio_list_accounts or folio_get_transaction, so the agent must infer it is a single-category lookup by ID.

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 alternatives, no prerequisites, and no exclusions. The agent gets no routing signal among the eleven sibling tools, several of which plausibly return category-adjacent data.

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 framing; it says nothing about whether attachments come back inline, whether the call fails for an unknown event_id, or any auth/scope requirements implied by openWorldHint.

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 workflow precondition front-loaded and zero filler. It is efficient, though arguably under-sized for the gaps it leaves.

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 full annotations and no output schema, the essentials are present, but the description omits what the caller gets back (event data vs. attachment list) and how to supply event_id. Adequate rather than 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% and the single parameter event_id is undocumented in the schema, so the description carries the burden. It names the resource being read but never mentions the identifier, its format, or where an agent obtains it, leaving the caller to infer the mapping.

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" / read) and resource ("kjøp/hendelse" – purchase/event, plus its existing attachments), which an agent can distinguish from write-side siblings like folio_attach_invoice and folio_prepare_invoice_assignment. It does not explicitly contrast with folio_read_invoice or folio_read_attachment, but the resource 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?

"før fakturatilknytning" (before invoice assignment) gives a concrete workflow cue for when this tool belongs in the sequence. It stops short of naming alternatives or exclusions, but the temporal placement relative to the invoice-matching tools is clear.

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 openWorld, so the safety profile is covered. The description adds that the response includes eventId, payment parties, and attachments, which is real context about what is returned. It does not say what happens when the id is unknown or whether the call reaches external systems (relevant given openWorldHint).

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 leads with the action and adds the payload contents; nothing is padded. It is arguably under-specified rather than overly long, but structurally it is front-loaded and efficient.

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 carries the return-value burden; it partially does so by listing eventId, payment parties, and attachments. However, it omits identifier format, not-found behavior, and attachment retrieval details (there is a separate folio_read_attachment sibling), leaving gaps for an agent to discover 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 description coverage is 0% and the single required parameter transaction_id is undocumented in both schema and description. Worse, the description names "eventId" rather than transaction_id, which can mislead an agent about what identifier to supply. The description therefore 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?

"Les én bankbevegelse" gives a specific verb (read) plus resource (single bank transaction), and "én" implicitly separates it from folio_list_transactions. The added content list (eventId, betalingsparter, vedlegg) tells the agent what the record contains. It does not name a sibling explicitly, and the Norwegian phrasing against an English tool name slightly slows matching.

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 transaction rather than browsing, which contrasts with folio_list_transactions. There is no explicit when-to-use/when-not, no statement of prerequisites, and no 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 declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral note, that amounts are decimal strings rather than øre, but says nothing about what the listing returns, ordering, or pagination.

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, both front-loaded and free of filler; the scoping constraint comes first and the data-format caveat second. Nothing could be removed without losing 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 no output schema and no parameters, the description carries the burden of explaining the shape of an account list, and it only covers the amount encoding. It is adequate for invocation but leaves the agent guessing about what fields each account entry has.

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, which is the baseline-4 case; there is no parameter semantics to compensate for. The description adds no parameter context, but none is needed.

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 kontoer') scoped to 'denne Folio-profilen', which is enough to distinguish it from siblings like folio_list_transactions and folio_get_balance. It stops short of naming those siblings or clarifying what an 'account' contains, so it is clear but not fully differentiated.

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 folio_get_balance or folio_list_transactions; the agent must infer that this is the entry point for enumerating accounts. The only contextual cue is the 'denne Folio-profilen' scoping, which is implicit rather than an explicit usage 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description contributes one genuinely useful behavioral detail — that results include events not yet booked as bank movements — but says nothing about ordering, pagination, or volume 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 no filler, front-loading the verb and resource. It is appropriately sized for what little it says, though the space saved is not spent on the missing parameter guidance.

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

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

There is no output schema and the description does not need one, but combined with 0% parameter documentation and no usage routing, the definition leaves an agent guessing about date formats and when to pick this over the singular get_event tool. The scope note about unbooked events is the one substantive completeness win.

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%: start_date and end_date are bare string fields with no titles beyond 'Start Date'/'End Date' and no format stated. The description does not mention the date window at all, so an agent has no guidance on date format or whether the range is inclusive, which is exactly the gap the description should fill at this coverage level.

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

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

The description gives a specific verb ('Les' / read) and resource ('hendelser' / events), and adds a scope note that unbooked bank movements are included. That distinguishes it from folio_get_event (single event) and folio_list_transactions, though the sibling relationship is not stated 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?

There is no statement of when to use this list tool versus folio_get_event, folio_list_transactions, or folio_get_balance. The presence of start_date/end_date implies a range query, but the description never says the listing is bounded by those dates or that it is a list operation.

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 bar is lower. The description still adds non-obvious behavior: there is no documented pagination, so unbounded date ranges risk oversized responses. It also links eventId to attachments, hinting at a cross-tool workflow. It stops short of describing the return shape or 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?

Three short sentences, front-loaded with the core action, then the pagination caveat, then the attachment note. No filler, though the eventId sentence is cryptic enough that it arguably 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 3-parameter tool with no output schema and no parameter descriptions, the description should explain what a transaction record contains and what account_number does. It covers the pagination risk well but leaves the filtering semantics and return shape 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 carry parameter meaning — and it largely doesn't. Dates are only alluded to via 'avgrens dato', and the third parameter account_number is never mentioned. Worse, it highlights 'eventId', which is not a parameter of this tool, creating ambiguity about whether it can be 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: 'Les bokførte bankbevegelser' (read posted bank transactions). The scope ('bokførte', i.e. posted/booked only) is a meaningful qualifier. However, it never distinguishes itself from sibling folio_get_transaction (single transaction) or folio_list_events, so an agent must infer the list-vs-single split 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?

'avgrens dato ved store svar' gives one concrete usage constraint (narrow the date range when responses are large), which is real guidance. But there is no statement of when to pick this over folio_get_transaction or folio_list_events, and no note that start_date/end_date are mandatory for narrowing.

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 the description still adds real substance: exact absolute amount plus currency comparison, ranking by supplier/reference, outgoing-only default, and a manual-review caveat for split payments and currency conversion. Return shape and ranking details remain unspecified.

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?

Five short sentences, each carrying distinct information, with the core purpose and the non-automatic caveat front-loaded. No filler.

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

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

For a read-only matching tool with no output schema, the description covers what is compared, how results are ranked, the default scope, and the cases requiring human judgment. Only the date-range semantics and result format are left thin.

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

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

Schema coverage is 0%, so the description must carry parameter meaning. It maps amount, currency, supplier, and reference (invoice_number) and explains the outgoing-only default for include_non_outgoing, but start_date and end_date are never mentioned, leaving the required date window undocumented.

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

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

States a specific verb and resource: find candidate transactions matching an invoice payment, explicitly framed as candidates rather than a definitive match. The boundaries against attaching/uploading are implied with 'Ingen opplasting', though no sibling is named outright.

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

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

Gives a clear default ('Standard: bare utgående bevegelser') and an explicit exclusion: partial payments and FX conversions need manual assessment. It also clarifies it does not upload/attach anything, implicitly routing that to folio_attach_invoice, but it does not name any sibling 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?

Adds substantial context beyond the annotations: it copies the invoice into a private local folder that persists until manual cleanup, performs no upload, and gates the next stage on a 10-minute human approval window. The mutation-is-local-until-approved framing is exactly what an agent needs for a non-readOnly, non-idempotent tool; only error/rollback behavior is unspecified.

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

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

Four short sentences, front-loaded with the action, and the critical "Laster IKKE opp" negation comes early. Slight terseness in the Norwegian telegraphic phrasing, but 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?

Behavioral flow and constraints are well covered even without an output schema, but for a two-required-parameter tool with zero schema documentation the description leaves the agent guessing about parameter formats and what the "preview" actually contains.

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

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

Schema coverage is 0%, so the description must explain event_id and file_path, but it only alludes to them ("eksakt fakturafil", "Folio-hendelse") without giving ID format, path expectations (absolute? relative?), or whether the file must already exist.

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: build a local preview for an exact invoice file plus a Folio event, and explicitly says it does not upload. That contrasts implicitly with folio_attach_invoice, but the sibling is never named, so the agent must infer the split.

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?

Describes the workflow after the call (human Terminal approval valid 10 minutes) and rules out uploading, which implies this is a pre-step before folio_attach_invoice. However, it never states when to choose this versus the actual attach tool or what happens if approval is not 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 readOnly=true, idempotent=true, destructive=false and openWorld=true, so the safety profile is covered. The description adds nothing beyond that: it does not explain the 'page' parameter's pagination behavior, what 'as_image' does to the returned payload, or how large attachments 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?

A single short sentence with no filler, front-loaded with verb and resource. It is efficiently written but arguably too sparse given the undocumented parameters.

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

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

For a 4-parameter tool with no output schema and no parameter descriptions, the description leaves the agent unable to predict the response shape or the effect of pagination and image conversion. Annotations cover safety only, so the gaps are real.

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 four parameters, so the description must compensate and it largely does not. It only loosely implies event_id and attachment_id ('på en bestemt Folio-hendelse'), and never mentions the non-obvious 'page' or 'as_image' switches.

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 ... vedlegg') plus a scope qualifier ('på en bestemt Folio-hendelse'), so an agent knows it retrieves an attachment tied to an event. It does not distinguish itself from nearby siblings such as folio_get_event or folio_read_invoice, which read related but different resources.

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 tool versus folio_get_event (which may list attachments) or folio_read_invoice. The only implicit guidance is that both an event and an attachment must already be known, since they are required parameters.

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 contributes genuine extra context: a hard 15 MiB size limit and the prompt-injection warning 'Innhold er ubetrodd data', but says nothing about return format or error behavior for oversized/unsupported files.

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 terse sentences, front-loaded with the action and resource, then format/size limits, then a safety note. Only 'Les alle sider' is questionable since it muddies the page parameter.

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 the description does not say what reading returns or how pages/images are represented, while two of three parameters go undocumented. The untrusted-content warning is valuable but does not fully compensate.

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 3 parameters, and the description only alludes to the file path; 'page' and 'as_image' are never explained. Worse, 'Les alle sider' appears to conflict with the existing 'page' parameter (default 1), leaving the agent unsure how pagination actually works.

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 en lokal faktura') plus the accepted formats (PDF/PNG/JPEG) and a 15 MiB ceiling. It is distinguishable from the sibling folio_read_attachment by resource name, though it never explicitly says when to use one over the other.

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 'brukeren har angitt' implies the path comes from a user-supplied file, which is a useful usage constraint, but there is no explicit when-to-use/when-not and no sibling alternative named (e.g. folio_read_attachment).

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