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

Annotations already establish readOnly, idempotent, non-destructive and open-world behavior, so the bar is lower. The description still adds a genuinely non-obvious behavioral trait: revenue accounts (3xxx+) are sign-flipped so income reads positive, which an agent could not infer from the schema or annotations and which materially affects result interpretation.

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

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

Two sentences, front-loaded with the core operation before the examples. The range examples occupy most of the text but each one earns its place by disambiguating the account parameters; nothing is redundant 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 four-required-parameter read tool with no output schema, the definition covers what the tool computes and the sign-flip rule, but says nothing about the shape of the result (per-month series, currency, whether empty months appear) or how the date range interacts with monthly bucketing.

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

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

Schema coverage is 0%, so the description must carry the parameter burden, and it does for the two account parameters by mapping number ranges to business meaning (3000–3999 revenue, 7000–7699 personnel, 1930 business account). The date parameters get no explanation, but their ISO pattern and the required from/to pairing are self-evident.

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

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

States a specific operation (monthly net movement) over a specific resource (an account-number range), which clearly distinguishes it from aggregate siblings like income_statement and balance_sheet. The concrete range examples (3000–3999 revenue, 5000–6999 external costs) pin down the domain precisely, though no sibling is named as an explicit 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?

Usage is only implied: the account-range examples hint at when this tool applies (per-month account aggregation), but there is no explicit statement of when to use it versus income_statement, balance_sheet, or list_vouchers, and no prerequisites or exclusions are given.

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

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, and the description does not contradict them. It goes beyond the annotations by disclosing what the report actually contains — including the year's result not yet closed to equity and the 19xx account convention for cash and bank, which is genuine domain context an agent would not otherwise have.

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 report's contents, followed by a useful clarifying convention. No filler or repetition of the title. Slightly cryptic phrase 'not yet closed to equity' costs a little readability but carries real 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, the description must convey the return shape, and it partially does by listing the report's sections and the per-account granularity. It leaves open how results are structured, grouped, or presented, and says nothing about usage context versus sibling financial reports, so it is 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?

There is only one parameter and schema coverage is 100%, with the schema itself stating the YYYY-MM-DD pattern and 'Default today'. The description adds nothing about the date argument, so the baseline of 3 applies.

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

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

States a specific artifact (balance sheet) and enumerates its contents: assets, equity, liabilities on a date, per account, plus the year's result not yet closed to equity. That is far more specific than a bare report name. It does not explicitly name or differentiate from the sibling income_statement, so not a 5.

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

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

No when-to-use, no prerequisites, no alternatives are given. The closing note about 19xx accounts is domain color rather than guidance on when to call this versus income_statement or account_totals_by_month. The agent must infer the use case 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is established. The sentence "nothing that sends, prints or changes data is reachable" largely restates readOnlyHint rather than adding new traits such as pagination limits, rate limits, or how invalid paths are handled. With annotations doing the heavy lifting, a 3 is appropriate.

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

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

Two sentences, no filler. The operational constraint (must match a list_endpoints template) is front-loaded before the read-only guarantee, which is the right ordering for an agent deciding whether it can call this.

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

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

For an open-world GET passthrough with no output schema, the definition covers the calling contract: where paths come from, their shape, and that reads are safe. It omits pagination/query semantics and invalid-path error behavior, which are minor but non-trivial for a generic proxy.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful context: the path is a concrete instantiation of a discovered template with {placeholders} filled in, and it shows two worked examples. That clarifies how to derive the required value beyond the schema's terse "Concrete path" note.

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 (GET) and resource (a Fortnox API path) and ties it to a discovery source (templates from list_endpoints) with concrete examples. An agent can distinguish this generic passthrough from the domain-specific siblings like list_customers or get_invoice without opening any schema.

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

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

The description makes the precondition explicit: the path must match a template obtained from list_endpoints, with placeholders substituted. It does not state when to prefer this generic tool over the purpose-built siblings (e.g. get_customer), which is the one remaining routing gap.

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 the read-only, idempotent, non-destructive, and open-world nature of the tool, so the safety profile is covered. The description adds the returned data fields but does not disclose any additional behavioral traits such as authentication needs, rate limits, or response 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?

The description is two concise sentences, front-loading what the tool returns and then giving a clear call-to-action. Every 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?

For a zero-parameter read-only tool with no output schema, the description adequately enumerates the returned data (name, org number, address, VAT number, financial years, locked period) and provides orientation guidance. Nothing essential is missing.

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

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

The tool has zero parameters, so the baseline score is 4. The description cannot and need not add parameter semantics beyond what the empty schema provides.

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

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

The description clearly states the resource and its contents (company identity, financial years, locked period), but it does not use a specific verb or explicitly differentiate itself from the sibling list_financial_years tool.

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 instruction 'Call this first to orient' provides clear usage context, but it does not specify when not to use this tool or name alternative siblings for specific data needs.

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's real contribution is enumerating the returned payload (addresses, payment terms, VAT type, default references), which matters because no output schema exists. It still says nothing about error/not-found behavior or permissions.

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 scope ('One customer in full') followed by the payload contents. No filler, nothing that fails to earn its place.

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

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

Annotations cover the safety profile and the description covers the payload, so the basics are there. It is still incomplete for an identifier-based lookup: the parameter format and the not-found/error outcome are undocumented in both description and schema.

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

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

The single required parameter customer_number has 0% schema description coverage, so the description must carry the semantics. It never names the parameter or its expected format, only implying lookup by some customer identifier via 'One customer'.

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

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

States a specific resource (one customer) and the scope of the payload ('in full'), with a concrete enumeration of returned fields (addresses, payment terms, VAT type, default references). It implicitly separates itself from the sibling list_customers by emphasizing a single record, but 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 statement of when to use this versus list_customers, get_supplier, or the other get_* lookups. The singular 'One customer' weakly implies a lookup-by-identifier use case, but no conditions, prerequisites, or exclusions are given.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, so the safety profile is covered structurally. The description adds value by disclosing the return content (field list) in lieu of an output schema, but says nothing about the lookup key, failure modes for an unknown document_number, or scoping (e.g. per financial year).

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 tight sentence with the resource stated first and the returned fields enumerated. Nothing is redundant, though the fragment style leaves no room for the missing usage 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?

With no output schema, the field enumeration usefully signals what the caller receives, and annotations cover the safety profile. But the required document_number parameter is completely unexplained, which is the main gap for an otherwise simple single-param read tool.

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

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

Schema description coverage is 0% and the schema only declares document_number as a non-empty string. The description never mentions the parameter, its format, or where it comes from (e.g. an invoice list), so it fails to compensate for the coverage gap.

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

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

Names a specific resource (one customer invoice) and enumerates what it returns (rows, Net, VAT, Balance, due date, references, booked/sent state). It is clearly distinct from list_invoices and get_supplier_invoice by naming 'customer invoice' and 'one'. However, the verb is only implicit in the tool name, and no sibling is named explicitly.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_invoices for browsing versus this tool for fetching a single document. The only signal is the tool name itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful disclosure — that bank details are returned — but says nothing about not-found behavior or what the rest of the 'full' payload 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?

A single short sentence with the scope claim front-loaded and no filler. It is efficient, though almost too terse given the gap left in parameter and usage 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?

For a one-parameter read tool whose annotations cover safety and with no output schema, the minimum is met. Still missing: how to obtain a valid supplier_number and what happens when it does not resolve.

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% and the description says nothing about supplier_number — not its format, source, or whether it matches the identifier used in list_suppliers. The name is self-explanatory, but the description does nothing to compensate for the documented 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: retrieves a single supplier 'in full'. The word 'One' implicitly contrasts with the sibling list_suppliers, though no sibling is named, so an agent must still infer the boundary itself.

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

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

No when-to-use guidance, no prerequisites, and no routing between this tool and list_suppliers or get_supplier_invoice, both of which return overlapping supplier data. The description assumes the agent already knows which lookup tool to pick.

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

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

Annotations already specify readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds that the invoice is returned 'in full, with its accounting rows', which is useful context on the return structure. However, it doesn't disclose error behavior or what happens if the given_number is invalid, which the annotations don't cover.

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 purpose and followed by a critical parameter clarification. No wasted words.

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

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

Given the tool's simplicity (one required parameter, no output schema, rich annotations), the description covers purpose, return content, and parameter meaning. The main gap is lack of explicit routing guidance among similar get/list tools, but the core information is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It does by explaining that given_number is Fortnox's own serial number, clarifying the identifier's meaning beyond the schema's bare type. This is meaningful added value.

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

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

The description states a specific verb and resource: retrieving one supplier invoice 'in full, with its accounting rows'. This distinguishes it clearly from list_supplier_invoices (plural). It doesn't explicitly contrast with get_invoice, but the 'supplier' qualifier makes the domain clear.

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 a retrieval use case by naming a singular identifier, suggesting it's for fetching a specific invoice. However, it doesn't state when to use this vs list_supplier_invoices or get_invoice, nor does it mention prerequisites like needing a valid serial number.

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

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

Annotations already declare the operation as read-only, idempotent, open-world, and non-destructive, so the description is not responsible for the safety profile. It adds useful context by stating the return includes debit/credit rows, but it does not describe not-found behavior, permissions, or any other behavioral detail.

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 fragment with no wasted words, so it is concise. However, it is so terse that it lacks structure and sufficient informational payload, making it under-specified rather than optimally concise.

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 tool with three parameters, no output schema, and zero schema descriptions, the description should compensate by explaining parameter usage and return behavior. It only hints at the return content and leaves parameter identification and tool selection entirely unexplained.

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 does not mention any of the three parameters (series, number, financial_year). An agent gets no guidance on how to identify the voucher beyond the raw schema types.

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

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

The description identifies a specific resource ('one voucher') and its content ('debit/credit rows'), distinguishing it implicitly from sibling list operations like list_vouchers. However, it does not use a full verb and does not explicitly name the sibling alternative, so it falls short of a 5.

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

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

The description gives no indication of when to use this tool versus list_vouchers or other retrieval tools. There are no prerequisites, exclusions, or alternative-selection 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 readOnly/idempotent/destructive=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it is built from the SIE export, matches the books exactly including manual vouchers, and revenue is positive while costs are negative — a sign convention the annotations cannot convey.

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

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

Dense and front-loaded — the purpose comes first, then the grouping, sign convention, and data provenance. Slightly run-on but every clause carries information; nothing is padding.

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

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

With no output schema, the description usefully sketches the return shape (grouped by account class, per-account lines) and the sign convention. The only real gap is period-boundary semantics for the two date parameters, which is minor for a read-only report.

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 schema only conveys the date format via a regex pattern. The description adds that the range is arbitrary ('any date range') but does not state whether to_date is inclusive, which matters for a period report. Partial compensation only.

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

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

States a specific resource and output shape: 'Profit and loss for any date range, grouped by BAS account class with per-account lines', and even enumerates the line categories. An agent can tell this apart from balance_sheet, though no sibling is named explicitly.

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

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

Usage is implied by 'for any date range' and the revenue/cost framing, but there is no explicit when-to-use statement, no exclusion, and no pointer to alternatives such as account_totals_by_month or balance_sheet for other reporting needs.

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 the content scope (balances included) but says nothing about pagination, result size, or whether unused accounts are returned — behavior the annotations do not cover.

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 key domain term (kontoplan) and the balance fields front-loaded; nothing is padded. It is a noun phrase rather than a statement of action, which slightly weakens the front-loading of intent.

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

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

For a two-parameter, read-only list tool with no output schema, the description is minimally adequate: it tells the agent what the result set represents, and the schema carries parameter details. It lacks any indication of which fields each account row returns or how the balance columns are structured, which would matter for downstream use.

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

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

Schema description coverage is 100%, so both parameters (only_used with its default-true behavior and financial_year defaulting to the current year) are already fully documented in the schema. The description only obliquely references the financial-year scoping and never mentions the only_used filter, so the baseline 3 applies.

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

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

The description names a specific resource (chart of accounts / kontoplan) and specifies the scope (a financial year) plus the data it carries (opening and closing balances), which goes beyond the bare name. It does not differentiate itself from siblings like account_totals_by_month or balance_sheet, and it omits an explicit verb, 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 when-to-use guidance, no mention of prerequisites (e.g., needing a financial_year id from list_financial_years), and no routing to alternatives such as account_totals_by_month despite many overlapping accounting siblings. The agent must infer usage entirely 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered by structured data. The description adds only an entity definition, no behavioral context such as filtering semantics, default paging behavior, or whether inactive records are included by default.

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 is efficient and front-loaded, with no filler. But it is terse to the point of under-specification, so it earns only a middle score for structure.

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 three parameters, no output schema, and low schema coverage, the description should clarify the return shape, filter behavior, and the undocumented parameters. It supplies none of these, leaving the agent guessing about how articles are filtered and returned.

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

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

Schema coverage is only 33%: max is documented in the schema, but filter (enum active/inactive) and description have no schema descriptions. The description text does not compensate, giving no meaning for what 'description' filters on or what 'active' means for an article.

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

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

The description names the resource and clarifies its domain meaning (articles are products/services with prices and stock), which is genuinely more informative than the bare name. However, it states no verb and never says the tool lists or retrieves them, nor does it differentiate from the many sibling list_* tools. The purpose is inferable but vague.

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 list_orders or list_suppliers, nor any prerequisites or exclusions. The agent is left to infer usage entirely 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered by structured data. The description adds nothing beyond that — no scoping, no pagination, no indication of whether the list is tenant-wide or filtered.

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 certainly short and free of waste, but it is a fragment rather than a front-loaded functional statement, so brevity here reflects under-specification rather than disciplined concision.

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?

Even for a trivial zero-parameter read tool, the description gives no hint of what a cost center is in this accounting context or what the list contains. Annotations carry the safety story, but the description contributes essentially nothing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level information is missing.

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

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

The description is a bare noun phrase for the resource with a Swedish gloss ('kostnadsställen') and never states the verb 'list' that the name and title carry. It identifies the object but not the action, so it largely restates the name/title rather than describing what the tool does.

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 alternatives among the many sibling list_* tools, and no preconditions. The agent must infer usage purely 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety and mutability profile is covered. The description adds no behavioral context beyond what annotations provide — no pagination behavior, no default result limits, no ordering. With annotations covering the safety profile, a 3 reflects that the description adds nothing extra but does not contradict.

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 no wasted words, but the brevity comes at the cost of completeness. Front-loading is fine, but the description is under-specified rather than efficiently concise.

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 5 parameters and 20% schema coverage, no output schema, and no annotations covering return format, the description is insufficient. It doesn't explain default/max limits, filter behavior, or what fields are returned. An agent would need to guess or experiment to use it correctly.

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

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

Schema description coverage is only 20%, so most parameters lack documentation in both schema and description. The description mentions searching by name, org number, and email, which maps to three parameters, but it omits 'max' (partially documented in schema) and 'filter' (enum with no description). For a low-coverage schema, the description fails to compensate for the missing parameter details, especially the enum filter 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 the resource (customer register) clearly, but the purpose is vague as a listing tool — 'Customer register' is a noun phrase rather than a verb+resource. It doesn't differentiate from sibling get_customer, and the search verbs are secondary to the identity of the tool. An agent can infer it lists customers, but with less precision than a stronger definition.

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

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

No explicit when-to-use guidance or alternatives are named. The description implies this is for searching customers, but does not state when to use this vs. get_customer or other list_* tools. No exclusions or prerequisites 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 readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds useful context on the return shape (path templates and summaries) but does not describe pagination, result size, or how to use the returned templates.

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 with the purpose and return value front-loaded. Minor redundancy: 'read-only' restates the readOnlyHint annotation, but no meaningful waste otherwise.

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 one-parameter discovery tool, the description covers what it searches, what it returns, and which tool consumes the output, which is sufficient without an output schema. It could be slightly more explicit about how to chain into fortnox_get.

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

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

Schema coverage is 100% and the single 'search' parameter is fully documented with examples in the schema. The description adds no syntax or matching-behavior detail beyond what the schema already provides, so baseline 3 is appropriate.

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

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

States a specific verb (search/list) and resource (the read-only Fortnox endpoints that fortnox_get can call), and gives concrete category examples. It clearly differentiates itself from the data-returning siblings by being a discovery tool for fortnox_get rather than a data list itself.

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

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

By naming fortnox_get as the consumer, it implies this is the discovery step before calling that tool, but it never explicitly says when to use this versus a direct list_* sibling or how to proceed after finding an endpoint. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds value beyond that by disclosing the shape of the payload (id plus date range) and the cross-tool dependency on the id, though it says nothing about auth needs 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?

Two short sentences, no filler. The payload contents come first and the downstream-dependency note second, which is the right front-loading.

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

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

There is no output schema, so the description must carry the return-value burden, and it does by naming the id and date range fields. Combined with annotations covering the safety profile, an agent has everything needed to call this tool correctly.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is nothing to mistranslate and the description correctly omits parameter talk.

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 the resource precisely (all financial years, with the Swedish synonym räkenskapsår) and enumerates the returned fields (id and date range). It also explains the role of the id, which lets an agent distinguish this listing tool from the other list_* siblings at a glance.

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

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

"The id is what SIE and voucher calls take" gives a concrete reason to call this tool before voucher/SIE operations, which is real usage context. It stops short of naming the specific sibling tools or stating when not to use it, but the sequencing intent 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=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the domain meaning of the resource but says nothing extra about result size, pagination behavior, or ordering beyond what the max parameter already states.

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 resource and followed by the filtering hint; nothing is padded. The telegraphic fragment style is efficient, though slightly sparse on connective detail.

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 zero-required-parameter list tool, the description plus annotations and schema give enough to call it correctly. With no output schema, a note on what a payment record contains would help, but the core invocation requirements are covered.

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

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

Schema coverage is 50%: max is fully documented in the schema (default 100, up to 2000), while invoice_number carries no schema description. The phrase "Optionally for one invoice" partially compensates by implying invoice_number is a filter, but it does not clarify whether results are limited to that invoice's payments or how the number is matched.

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

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

States a specific verb+resource: payments registered against customer invoices, with the Swedish term (inbetalningar) aiding disambiguation. It implies a collection-listing scope distinct from get_invoice, though it never explicitly names sibling tools to differentiate itself.

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

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

"Optionally for one invoice" hints at filtering but gives no when-to-use guidance, no conditions, and no mention of alternatives such as list_invoices or get_invoice. The agent must infer whether to call this or a sibling when it wants invoice payment 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 cover readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real behavioral value by disclosing the default result ordering ('newest first unless sorted otherwise') and clarifying that Total is VAT-inclusive while Balance reflects Fortnox's remaining-unpaid figure. It does not, however, discuss pagination or the practical effect of the max cap.

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 the primary resource and default ordering front-loaded, then filters, then field semantics. No filler, though the parenthetical Swedish term and the trailing field notes dilute focus slightly.

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

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

For a 7-parameter read tool with no output schema, the description helps by explaining the Total and Balance return fields and the default sort, but it is silent on result shape as a whole, the max/pagination behavior, and how it relates to the single-invoice and payment siblings. Adequate but with clear gaps.

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

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

Schema coverage is only 43%, so the description must carry weight; it does map the filter enum to its meaning ('status (unpaid, unpaidoverdue, fullypaid, unbooked, cancelled)') and explains the date-range and customer filtering intent. It adds nothing for max, sort_by or sort_order, so several parameters remain 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 the specific resource, 'Customer invoices (kundfakturor)', which cleanly separates it from the sibling list_supplier_invoices and get_invoice. The listing verb plus the scoping ('filter by ...') makes the tool's job unambiguous 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?

It enumerates what can be filtered and the default ordering, which implies the browse-with-filters use case, but never states when to choose this over get_invoice for a single record or list_invoice_payments/list_supplier_invoices. No explicit when/when-not 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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds nothing beyond that — no default row count, no pagination behavior, no note about what the filter enum states mean or the interaction between date bounds and filter.

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 short, but this is under-specification rather than conciseness — the brevity comes at the cost of all actionable content. There is nothing to front-load because nothing useful was written.

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?

Five parameters, 80% undocumented, no output schema, a multi-value filter enum, and an ambiguous 'offers vs quotes' domain concept combine to make this definition far too thin for correct invocation. An agent cannot determine what a returned 'offer' is or how to filter meaningfully.

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

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

Schema description coverage is only 20% (just 'max'), and the description says nothing about any of the five parameters. The filter enum values (cancelled/expired/completed/ordercreated/etc.), the from_date/to_date date semantics, and customer_number are left entirely unexplained in both places. For a 5-param tool with low coverage, the description carries the burden and fails to.

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 'Quotes/offers (offerter)' merely restates the resource noun and mirrors the tool name/title, with no verb, scope, or listing behavior specified. The parenthetical Swedish synonym is the only additive information. An agent learns nothing about what shape of offers are returned or at what granularity.

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 vs any sibling, and no mention of filtering/preconditions. The sibling set is full of other list_* tools (list_orders, list_invoices, list_customers), so differentiation matters here, yet none is offered. It is not misleading, just absent.

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, open-world, and non-destructive behavior. The description adds the meaning of the 'invoicenotcreated' filter, which is useful behavioral context, but says nothing about return format, pagination, sorting, 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?

The text is short and front-loaded, but the first sentence is a fragment and the whole definition is under-specified for a five-parameter tool with low schema coverage. It is concise without being adequately informative.

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

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

For a tool with five parameters, only 20% schema coverage, and no output schema, the description is far too sparse. It omits parameter meanings, usage context, and return behavior, leaving an agent unable to invoke it reliably beyond a default list 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 only 20% (only 'max' is documented in the schema). The description explains just one filter value, 'invoicenotcreated,' leaving 'filter' alternatives, 'from_date,' 'to_date,' and 'customer_number' undocumented in both schema and description.

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 terse resource phrase, 'Customer orders,' and adds one filter behavior, but does not itself state the verb (list) or scope. The title/name supply 'List orders,' yet the description alone is vague about what the tool actually does.

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 tool versus siblings like list_invoices or list_customers. The only contextual note is about one filter value, not when or why to choose this 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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral detail beyond that — no pagination/default behavior, no return format, no rate limits — and does not contradict the annotations.

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

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

It is a single short fragment with no wasted words, but it is not front-loaded with the tool's action and is arguably too terse to orient an agent. Concise yet under-specified.

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 one-parameter read-only list tool with full schema coverage and annotations, much of the necessary context is already present. However, the description never says the tool lists projects or what it returns, leaving the core operation implicit.

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

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

Schema description coverage is 100%, so the single 'max' parameter (default 100, up to 2000) is fully documented in the schema. The description adds no parameter meaning, so the baseline of 3 is appropriate.

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

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

The description defines the resource ('Projects, used to tag invoices, vouchers and costs') but never states the operation. It relies on the name/title 'list_projects' to convey that it lists them, and it does not distinguish this list tool from the many sibling list_* tools.

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

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

There is no when-to-use guidance, no exclusions, and no named alternatives among the many list_* siblings. The only hint is the domain context that projects tag invoices/vouchers/costs, which implies a use case but gives no selection criteria.

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 a useful clarification that 'authorizepending' means awaiting attest, but says nothing about pagination, default page size behavior, 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 compact sentences, front-loaded with the resource and then the filtering capabilities. No filler, though the parenthetical enum list makes the second sentence dense and it could be tightened slightly.

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, no-required-arg list tool with no output schema, the description covers the main filtering axes and benefits from annotations covering safety. It leaves max/row-limit behavior and supplier_number semantics undocumented, which is a real but modest gap.

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

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

Schema description coverage is only 20%, so the description carries weight here and does partially compensate: it enumerates the filter status values and explains the opaque 'authorizepending' enum. However, it says nothing about supplier_number, and the date-range parameter names (from_date/to_date) are only implied as 'date range'.

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

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

Names the specific resource (supplier invoices, with the Swedish synonym leverantörsfakturor) and the filterable dimensions, which distinguishes it from the sibling list_invoices and get_supplier_invoice. It does not explicitly name those siblings, so it stops short of a 5.

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

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

The mention of status, date range and supplier filtering implies when the tool is useful, but there is no explicit guidance on when to choose it over list_invoices or get_supplier_invoice, and no prerequisites or exclusions 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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered externally. The description adds nothing beyond that — no note on pagination limits, sorting, or whether the register includes inactive suppliers, which is the kind of context that would earn credit here.

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 short, but the brevity reflects under-specification rather than economy — the fragment "Supplier register." does not function as a usable instruction and wastes the only sentence available.

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-only list tool with one fully documented parameter and complete annotations, the description still leaves basic questions unanswered: what fields a supplier record contains and how this list relates to get_supplier. The structured fields carry most of the load, but the prose is too thin to be considered 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?

With a single parameter and 100% schema description coverage ("max": "Max rows to return (default 100, up to 2000)"), the schema fully documents the input. The description contributes no additional meaning, so the baseline 3 applies.

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

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

"Supplier register." is a noun phrase that essentially restates the tool name and title without a verb or scope. It does not distinguish this tool from siblings such as get_supplier or list_supplier_invoices, so an agent gets almost no signal about what the call actually returns.

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 alternatives (e.g., get_supplier for a single supplier, list_supplier_invoices for invoices), and no stated prerequisites. The agent must infer the listing intent purely from the tool name.

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

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavioral context by stating that voucher rows are NOT included, which tells the agent the payload is header-level only. It does not mention pagination or ordering, but it improves on the annotations rather than restating them.

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

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

Two sentences, no filler, and the primary capability is front-loaded ahead of the disambiguation note. Every 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?

There is no output schema, so the description correctly carries the return-shape burden by saying rows are excluded, and annotations cover the read-only safety profile. The remaining shortfall is the several unexplained filter parameters, which is a minor rather than blocking gap for a list tool.

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

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

Schema coverage is only 40% (max and series documented; from_date, to_date, financial_year not). The description compensates partially by naming date range and series as the two filter modes, but leaves financial_year and the default/ceiling behavior of max unaddressed. Adequate but with real gaps.

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?

It names the resource (vouchers/verifikationer) and the two retrieval axes (date range or series), and explicitly distinguishes itself from get_voucher and the report tools. The only weakness is that the verb is implicit in the tool name rather than stated, but an agent can still tell exactly what this returns.

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 routes the agent to alternatives with conditions: get_voucher for a single voucher and the report tools for totals. That is explicit selection guidance. It stops short of a full when-not-to-use rule (e.g. what to do when you need rows or account-level detail).

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, non-destructive, so the safety profile is covered. The description adds useful behavior context (bucketing by days past due, per-supplier grouping, highlighting the most overdue) but leaves return shape and 'most overdue' semantics undefined.

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 front-loaded sentence with no wasted words. However, the trailing phrase 'with the most overdue' is cryptic and reads as an incomplete clause rather than a clear behavioral statement.

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-optional-param report with no output schema, the description covers the general aggregation but not the output structure (bucket boundaries, per-supplier columns, what 'most overdue' returns). Adequate but with clear gaps.

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

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

Schema description coverage is 100% and the single as_of parameter is already documented with a default of today. The description adds nothing about as_of, so the baseline 3 applies.

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

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

Specific resource and semantics: unpaid supplier invoices bucketed by days past due, per supplier. An agent can distinguish this from receivables_aging by the payables scope, though the description never names that sibling or explicitly contrasts the two.

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

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

No when-to-use guidance at all. The description doesn't tell the agent when to pick payables_aging over list_supplier_invoices, get_supplier_invoice, or receivables_aging, nor that it's a reporting/aggregation view rather than a raw list.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely new behavioral content beyond annotations: the bucketing scheme and the fact that output includes the most overdue invoices per customer. It stops short of stating return structure or row limits, so not a 5.

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

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

One dense sentence that front-loads the purpose and packs the bucket boundaries without filler. Nothing is wasted and nothing essential is omitted.

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-optional-param ageing report with no output schema, the description conveys scope, grouping dimension, and buckets. It could note the as-of semantics (retrospective vs current) but is otherwise complete enough to call correctly.

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

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

Schema description coverage is 100% and the single param (as_of) is already documented with its pattern and default. The description adds no parameter detail, so the baseline 3 applies.

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

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

States a specific verb+resource (receivables ageing) and enumerates the exact buckets (not due, 1–30, 31–60, 61–90, 90+) plus the per-customer and most-overdue framing. This clearly distinguishes it from the sibling payables_aging (receivables vs payables) and from list_invoices.

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 it is a reporting/aggregation tool but gives no explicit when-to-use guidance and doesn't name payables_aging or list_invoices as alternatives. Usage is largely inferable from the ageing-bucket framing, but no conditions or exclusions are stated.

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