Fortnox MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation3/5
The CRUD tools for customers, suppliers, invoices, and accounts are clearly distinct, but the large set of analytical tools creates ambiguity. Tools like period_comparison vs yearly_comparison, customer_growth vs period_comparison, and several 'LIMITED' tools that all defer to account_activity have overlapping or unclear boundaries.
Naming Consistency4/5
All tools share the fortnox_ prefix and consistently use lowercase with underscores. However, the pattern is not strictly verb_noun: CRUD tools use list_/get_/create_/update_/delete_, while analytics use noun-based names like invoice_summary, order_pipeline, and cash_flow_forecast. The style is predictable but not uniform.
Tool Count2/5
With 51 tools, the server is heavily oversized. Many analytics overlap or are stubs (e.g., five 'LIMITED' tools that just point to account_activity), suggesting the tool count could be reduced significantly without losing functionality. This exceeds the 25+ threshold for 'too many'.
Completeness3/5
Core financial entities (customers, suppliers, invoices, accounts, vouchers) have solid lifecycle coverage, but there are notable gaps: order and offer tools are list-only with no create/get/update/delete, supplier invoices lack creation/update, and several analytics return only metadata or structure rather than actual data, causing dead ends.
Average 4.1/5 across 51 of 51 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 4 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, so the write nature is known. The description adds that it returns the created account details, but offers no additional context on permissions, validation, or side effects. Minor added value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear main sentence and an Args list. It is slightly redundant with the schema but does not waste words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With eight parameters and no output schema, the description should more thoroughly describe the return value and any business rules. The return statement 'The created account details' is vague, and no mention is made of uniqueness or other constraints. The description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning the input schema already describes all parameters. The description restates the parameters with types and constraints but adds no new semantic insight beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new account in the chart of accounts, using a specific verb and resource. This distinguishes it from sibling tools like fortnox_update_account, fortnox_delete_account, and fortnox_get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It merely states 'Create a new account' without mentioning conditions, exclusions, or other tools like fortnox_update_account for modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds that it updates an existing account and returns the updated details, which is beyond the annotations. However, it does not disclose whether it performs a partial or full update, error behavior for missing accounts, or any side effects. Annotations already cover idempotency and non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and not verbose, with a clear intro, an Args list, and a Returns section. However, the Args list is redundant with the schema and could be trimmed without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema) and presence of annotations, the description is minimally adequate. It states the purpose and return value, but lacks detail on partial updates, error handling, and the response_format parameter, leaving notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args list repeats schema information without adding new meaning and omits the response_format parameter, providing no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing account in the chart of accounts, using a specific verb and resource. This distinguishes it from sibling tools like fortnox_create_account, fortnox_delete_account, and fortnox_get_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., create vs. update, or get vs. update). It does not mention prerequisites like account existence or any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it 'Shows growth rates and trends,' which is output-related rather than behavioral. No additional behavioral traits (e.g., data freshness, computation method, limitations) are disclosed, so the description adds limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no redundancy, and front-loaded with the core function. Every word contributes meaning, making it an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has six parameters and no output schema, so the description should clarify what the tool returns beyond just 'growth rates and trends.' It does not mention fields like customer names, revenue amounts, or growth rate calculations, leaving the output structure somewhat vague. For a read-only analytics tool, this is a moderate gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-level meaning beyond what the schema provides; it only mentions the high-level concept of comparing revenue across periods, which is consistent with the 'current_period' and 'compare_to' parameters but adds no new detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: identifying growing and declining customers by comparing revenue across periods. It uses a specific verb ('Identify') and resource ('customers') with a clear analytical scope. However, it does not explicitly distinguish itself from sibling tools like fortnox_period_comparison or fortnox_top_customers, which could also analyze growth or period trends.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for customer growth analysis but does not provide explicit guidance on when to use this tool versus alternatives such as fortnox_period_comparison or fortnox_top_customers. There are no stated exclusions or scenarios where another tool would be preferred, leaving the usage context only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds that results are ranked top performers, which is helpful, but does not disclose details about period handling, trends, or response format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main verb and resource, no wasted words. The structure is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives a high-level overview but does not explain nuances like the optional trends comparison, date range handling, or how it differs from other analytics tools. Given the absence of an output schema and competing siblings, more context would be beneficial, but the schema fills many gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description does not add extra parameter meaning, but the baseline of 3 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes product/customer sales performance and returns top performers ranked by revenue, quantity, or invoice count. It has a specific verb and resource, but does not explicitly differentiate from sibling analytics tools like fortnox_top_customers or fortnox_period_comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs top sales performers, but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. There is no mention of exclusions or sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral context such as 'customer_number auto-generated if not provided' and 'Returns: The created customer with assigned customer number.' It does not contradict the annotations, which already indicate non-read-only and non-idempotent behavior, but it does not deepen the explanation of side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an Args list and Returns section, but the Args block largely duplicates the information available in the input schema. While it is readable and front-loaded with the main purpose, the redundancy prevents it from being exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema, the description adequately explains the return value and the auto-generation of customer numbers. It is sufficiently complete given the rich input schema and annotations, though it could mention permission requirements or idempotency caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all 18 parameters (100% coverage). The description restates these parameters and adds minimal semantic value, such as grouping address fields and giving an example currency code. This does not meaningfully exceed what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Create a new customer in Fortnox,' which is a specific verb+resource statement. It clearly distinguishes this tool from sibling tools like fortnox_update_customer, fortnox_delete_customer, and fortnox_get_customer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new customer, but it does not explicitly state when not to use it or mention alternatives. For example, it does not say 'use fortnox_update_customer for existing customers.' Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds return-content details but does not disclose additional behavioral traits such as permission requirements, error behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured and succinct, but the 'Args' section duplicates schema content without adding value. The 'Returns' section is useful and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and no output schema; the description covers the return content adequately. It omits error-handling or auth context, but given the annotations and simple scope, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for both parameters, and the 'Args' section merely restates them. No additional semantic detail (format, defaults, edge cases) is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the target ('detailed information about a specific customer'), distinguishing it from list/get tools for other entities. The singular 'specific customer' makes it unambiguous that this is a point-lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for a known customer number but does not explicitly contrast with siblings like fortnox_list_customers or other lookup tools. There is no 'when not to use' or alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds behavioral context by mentioning pagination, partial matching for search_name, and the return fields. It does not contradict annotations but also does not go deeply into edge cases, ordering, or rate limits. The added value over annotations is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, an Args list, a Returns section, and examples. It is somewhat lengthy but each section earns its place by clarifying parameters and usage. The information is front-loaded with the purpose, and the formatting makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, 2 enums) and the absence of an output schema, the description provides good coverage: it explains pagination, filters, response format, and return fields. It lacks details like default sorting, but for a read-only list tool with strong annotations, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description repeats the parameter details in the Args section and adds examples (e.g., filter='active', search_name='Acme') that illustrate usage. However, it does not add new semantic meaning beyond the schema descriptions, such as parameter interactions or format specifics. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List customers from Fortnox accounting system' and elaborates on retrieving a paginated list with optional filters. It uses a specific verb+resource structure and distinguishes from sibling tools like fortnox_get_customer (single customer) and fortnox_create_customer (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (listing customers) and includes examples of common use cases. However, it does not explicitly contrast it with alternatives like fortnox_get_customer or fortnox_top_customers, nor does it state when not to use it. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior (destructiveHint=true), so the bar is lower. The description adds meaningful context by explicitly stating that booked invoices will have reversal entries created, which clarifies the side effect and provides insight beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a clear one-sentence purpose, a compact Args list, and a Returns note. No unnecessary words or redundant information, making it easy to parse and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema, the description covers the return value ('Confirmation of cancellation') and a key side effect (reversal entries). It's adequate for a straightforward cancellation tool, though it does not mention error handling or permissions, which are not critical for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema. The description repeats the parameter names and types without adding extra meaning or nuance, which meets the baseline for coverage but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Cancel an invoice.' It also distinguishes the behavior for booked invoices by mentioning reversal entries, which sets it apart from related tools like credit invoice or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as fortnox_credit_invoice or fortnox_delete_customer. The description simply explains the action without contextual direction, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, confirming the tool's safe read nature. The description adds no additional behavioral context such as pagination behavior, rate limits, or data scope beyond the filter options already present in the schema. It 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and key filtering options. Every word earns its place, with no redundant phrasing or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema (11 params, 5 enums, 100% coverage) and comprehensive annotations, the description is adequate for a list operation. It does not need to explain return values since no output schema exists, but the summary of filtering dimensions and the tool name are sufficient for an agent to understand the tool's role. Minor gap: no mention of pagination or response_format, though those are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 11 parameters are fully documented with descriptions and enums. The description provides a high-level summary of filters but does not add extra semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'sales offers/quotes', distinguishing it from sibling list tools such as list_invoices and list_orders. It also outlines the primary filtering dimensions (status, customer, date range), providing a clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing sales offers but does not explicitly differentiate when to use this tool over siblings like list_orders or list_invoices. No exclusions or alternative recommendations are provided, leaving the agent to infer context from the tool name and resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context beyond the schema—it restates the filter options but does not mention pagination behavior, output content, or any operational quirks beyond what the schema already documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource ('List sales orders'). Every sentence adds value, with no filler or repetition. The structure is ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 comprehensive schema and annotations, the description covers the essential purpose. However, with no output schema, it could explicitly describe what the response contains (e.g., order fields or format). The tool name and context largely suffice, but a small addition would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to compensate for undocumented parameters. It does provide a high-level grouping of parameters (status, customer, date range) and lists the filter enum values, but this largely duplicates the schema's existing param descriptions. The baseline of 3 is appropriate since no additional semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and clearly identifies the resource 'sales orders', along with the filtering dimensions (status, customer, date range). This distinguishes it from sibling tools like fortnox_list_invoices or fortnox_list_customers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when sales orders are needed but does not explicitly state when to choose this over alternatives like fortnox_list_invoices or fortnox_list_offers. No exclusions or alternative guidance is provided, which is a gap given the number of similar list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clear. The description adds that the tool shows year-over-year growth trends, going slightly beyond the raw name and title. However, it does not disclose details about the output structure or how it handles incomplete years, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences totaling under 20 words. It is front-loaded with the core purpose and immediately states the key scoping (2-5 years) and output (growth trends), with no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With full schema coverage and annotations indicating a safe, read-only operation, the description provides adequate context for an agent to use the tool correctly. It conveys the primary purpose and scope, though it does not explicitly describe the return format (e.g., a table or JSON). Given the lack of an output schema, a brief mention of what the 'showing' entails might improve completeness, but the current state is sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all three parameters (years, metrics, response_format), so the description does not need to add parameter-specific meaning. The description's mention of 'metrics' aligns with the schema's enum values, but adds no additional semantic detail beyond what the schema already explains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Compare revenue and metrics across multiple years (2-5). Shows year-over-year growth trends.' It specifies the action (compare), the resource (revenue and metrics), and the scope (multiple years with a range), which distinguishes it from sibling tools like fortnox_period_comparison that focus on arbitrary periods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is only implied through the description's mention of comparing across years; there is no explicit statement of when to use this tool versus alternatives, such as fortnox_period_comparison. The '2-5 years' scope provides context, but the description does not mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds context by noting that supplier_number is auto-generated if not provided, and that the created supplier with assigned supplier number is returned. It does not contradict annotations and provides useful behavioral details beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, an Args list, and a Returns section. It is compact given the 19 parameters, with no filler text. However, the parameter list largely repeats the schema descriptions, making it slightly redundant but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 19 parameters and no output schema, the description covers purpose, all parameters, and the return value. It does not address potential error cases or constraints beyond 'required' on name, but it provides sufficient context for an agent to invoke the tool correctly. The absence of an output schema is mitigated by the Returns section.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already explains each parameter. The description lists the parameters with brief clarifiers (e.g., '3-letter currency code') and notes auto-generation, but this mostly duplicates schema content. It adds little new meaning beyond the schema, fitting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Create a new supplier in Fortnox,' which clearly specifies the action (create), the resource (supplier), and the system (Fortnox). This distinguishes it from sibling tools like update_supplier, delete_supplier, and list_suppliers. The description also summarizes the expected outcome in Returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for creating a new supplier, which implies usage when adding a supplier. However, it does not explicitly mention when not to use it, such as when the supplier already exists (in which case update_supplier would be appropriate) or any prerequisites. The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, openWorld, and non-destructive behavior. The description supplements this by specifying the return content (customer info, dates, amounts, line items, payment status), which is useful because there is no output schema. It 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with Args and Returns sections, and the purpose is front-loaded. It is concise but includes some redundancy with the schema (e.g., parameter descriptions), making it slightly less crisp than the ideal, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately explains the return value (complete invoice details with specific fields). It also clarifies required vs optional parameters. It does not mention errors or authorization, but for a simple get tool with strong annotations, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters, and the description largely repeats that information (document_number required, response_format enum). Since schema coverage is 100%, the description adds no significant semantic value beyond what is structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Retrieve detailed information about a specific invoice including all line items'), which distinguishes it from list-oriented siblings like fortnox_list_invoices. The verb+resource combination makes it immediately obvious what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a specific invoice (as opposed to listing multiple invoices), but does not explicitly mention when to prefer this over alternatives or any exclusions. No alternative tools are referenced, and the context signals show many sibling tools that could overlap in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: pagination (limit/page), partial-match search behavior, the response_format parameter, and the specific return fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a bulleted Args list, and a Returns section. It is readable and front-loaded, though the Args list duplicates schema details, making it slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description appropriately explains return values ('supplier number, name, email, city, and organisation number'). It also covers pagination, filtering, and output format. However, it omits potential error cases and ordering/sorting behavior, so it is not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, including defaults and enums. The description's Args section largely repeats the schema information, such as 'limit (number): Max results per page' and 'filter ('active' | 'inactive')', without adding new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and clearly identifies the resource ('suppliers from Fortnox accounting system'). It distinguishes itself from sibling tools like 'fortnox_list_customers' and 'fortnox_get_supplier' by focusing on a paginated, filterable supplier list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing suppliers with optional filtering and pagination, but it does not explicitly state when to prefer this over alternatives (e.g., 'fortnox_get_supplier' for a single supplier) or provide exclusion criteria. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds value by specifying the return fields (code, description, manual entries allowed) and the domain purpose, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-line summary, a contextual note, and clear Args/Returns sections. It is concise but includes a slight redundancy by re-stating the parameter description already present in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is adequately complete: it states what it returns and explains the domain. It does not mention pagination or whether all series are returned, but given openWorldHint and the likely small set, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter response_format, including enum and default. The description merely repeats the schema's explanation ('Output format: markdown or json'), adding no new semantic detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List available voucher series in Fortnox' with a clear verb and resource. It distinguishes from siblings like fortnox_list_vouchers by focusing on voucher series, and adds explanatory context about their purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining that voucher series categorize vouchers, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling tool is named as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, signaling a write operation. The description adds value by explaining the outcome ('marks it ready for payment processing') and the return value (confirmation). It does not mention reversibility or permissions, but the provided context goes beyond the annotation basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured, with a clear opening statement, a brief explanation of the effect, and a compact Args/Returns layout. Every sentence contributes useful information without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with only two parameters and no output schema, the description covers the action, its consequence, parameters, and return value. It doesn't mention error scenarios or status prerequisites, but these are not critical for understanding the core function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description's Args section largely mirrors the schema's parameter descriptions. It adds no additional semantic detail beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool approves a supplier invoice for payment, using a specific verb ('approve') and resource ('supplier invoice'). It also clarifies the consequence ('marks it ready for payment processing'), which distinguishes it from sibling tools like cancel, credit, or bookkeep.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the action, but provides no explicit guidance on when to choose this tool over alternatives (e.g., bookkeep_invoice or credit_invoice) or any prerequisites like invoice status. There are no exclusions or conditions given, so it offers only implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so a write operation is expected. The description adds useful context beyond annotations: the return value (created invoice with document number), default for invoice_date, and example row structure. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into Args, Returns, and Example rows. It lists all parameters concisely without fluff. The example is valuable. Slightly longer than ideal but well-structured and every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 15 parameters and no output schema, the description covers all parameters, the return value, and provides an example. It doesn't address edge cases or error handling, but for a create tool this is reasonably complete, especially given the annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description repeats parameter names but adds an example row structure and clarifies invoice_type/send_type enums. This is helpful but not a significant semantic addition beyond the schema's detailed descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new invoice in Fortnox' with a specific verb and resource. It distinguishes from sibling tools like fortnox_credit_invoice (credit) and fortnox_update_invoice (update) by being the create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear for a create operation, but it does not explicitly name alternatives or when-not-to-use scenarios. It provides defaults and an example, giving practical guidance, but lacks exclusions like 'use fortnox_credit_invoice for credit invoices'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only and non-destructive behavior. The description adds that a new credit invoice referencing the original is created, but does not detail side effects on the original invoice or any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, but the Args section largely duplicates the schema property descriptions, making it slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter create operation with no output schema, the description provides purpose, parameters, and return value, but lacks information on side effects or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds that document_number is the invoice to credit, clarifying its role, while response_format is already fully documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a credit note for an invoice' with a specific verb and resource, and clarifies it creates a new credit invoice referencing the original, distinguishing it from sibling tools like cancel_invoice or create_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly indicates when to use the tool (when a credit note for an invoice is needed) but does not explicitly contrast it with alternatives such as cancel_invoice or update_invoice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. The description adds value by specifying the return content (description, VAT settings, balances), giving the agent concrete output expectations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured with Args and Returns sections. Every line adds useful information without unnecessary fluff, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool, the description covers purpose, parameters, and return value highlights. Annotations handle side-effect transparency, and the absence of an output schema is compensated by the explicit return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description only restates parameter names and the account_number range already present in the schema. It does not add additional semantic meaning beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Retrieve detailed information about a specific account', which is a specific verb+resource+scope. It clearly distinguishes from sibling tools like list_accounts by focusing on a single account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'specific account' phrasing implies use for single-account lookups, but the description does not explicitly mention alternatives or when-not scenarios. No reference to list_accounts or other siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds value by explicitly listing the returned data fields (company name, organisation number, addresses, contact details) and notes it's 'other company information,' which helps set expectations about the response. It does not introduce any contradicting behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with clear sections and is not overly long, but it contains redundancy: the initial sentence already states what is returned, and the 'Returns' section repeats nearly the same detail. This duplication makes it slightly less concise than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, read-only annotations), the description is complete. It identifies the resource, enumerates the returned fields, and mentions the optional output format. With rich annotations covering the operational context, no additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter 'response_format' already has a description and enum in the schema. The description's 'Args' section repeats this information without adding new semantics, so it adds no meaningful value beyond what the schema provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' and the specific resource: 'information about the company connected to this Fortnox account.' It distinguishes from siblings like fortnox_get_account or fortnox_get_customer by focusing on company-level info. The name and title reinforce this purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for retrieving company information from the connected Fortnox account. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for an agent to know when to select it over other getters. A brief alternative note would elevate it to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 the behavioral detail that percentage changes are computed, which is useful but limited. It does not contradict annotations and provides some extra context, aligning with the calibration example for a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It immediately states the verb and resource, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the full schema, rich annotations, and clear description, the tool is well-specified. The description mentions percentage changes, which is the key output, and the response_format parameter covers output presentation. No output schema exists, but the description plus schema are sufficient for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions and enums for all parameters. The description adds minimal parameter meaning beyond 'revenue, invoice count' as examples, but the schema already does the heavy lifting. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Compare' with a clear resource ('business metrics') and scope ('between two time periods with percentage changes'). This clearly distinguishes it from sibling analytics tools like fortnox_invoice_summary or fortnox_yearly_comparison, as period-over-period comparison is the unique focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (comparing metrics across two periods) but does not explicitly mention when not to use it or name any alternatives among the many sibling report tools. This is clear context without exclusions, so it falls short of a 5 but is still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it specifies that the email goes to the customer's configured address and that a confirmation is returned. The annotations already indicate openWorldHint (external side effect) and destructiveHint false, and the description aligns with these, providing clarity on the specific side effect without contradicting 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary purpose, and includes a clear Args section and Returns statement. It avoids unnecessary verbosity, though it could be slightly tighter by omitting the redundant parameter repetitions, but overall it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description sufficiently explains the tool's effect (sends email to configured address) and return value (confirmation). The annotation openWorldHint already signals external interaction, and the description complements it with specifics. It does not mention edge cases like missing email configuration, but the level of detail is appropriate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the input schema, and the description merely repeats their names and types ('document_number', 'response_format') with minimal additional context. Since schema description coverage is 100%, the baseline of 3 applies; the description does not add significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Send an invoice to the customer via email', which clearly identifies the action (send), resource (invoice), and delivery method (email). This distinguishes it from sibling tools like fortnox_get_invoice or fortnox_create_invoice, as no other sibling is focused on emailing invoices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states that this tool sends an invoice to the customer's configured email address, providing clear context for when it should be used. It does not explicitly mention alternatives or exclusions, but the purpose is straightforward and unambiguous within the sibling set, so it meets the 'clear context, no exclusions' bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutating operation (readOnlyHint=false), and the description adds valuable behavioral context: the irreversible nature of booking and the return of a voucher reference. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and efficient: a single purpose sentence, a clear args list, and a returns line. No fluff or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter action, the description covers what it does, the critical constraint (irreversibility), and the return value. It lacks explicit mention of prerequisites like the invoice existing or being in a bookable state, but the overall clarity is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters are well-defined in the schema. The tool description repeats the parameter details without adding extra meaning, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Bookkeep' and resource 'an invoice', and clearly states the outcome: 'creating the accounting entries'. This distinguishes it from sibling tools like create_invoice, cancel_invoice, or approve_supplier_invoice by indicating a final accounting action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for finalizing an invoice into the accounting ledger, and the note 'Once booked, the invoice cannot be edited' provides important context about when to use it. However, it does not explicitly name alternatives or exclude cases like already-booked invoices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context by specifying the data source (unpaid receivables/payables) and output components (expected inflows, outflows, net flow, running balance), going beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that immediately conveys the tool's purpose and output. It is front-loaded with the action verb and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description adequately explains the return values (inflows, outflows, net flow, running balance). All parameters are covered by the schema, and the description covers the core business logic. Minor caveats about forecast estimation could be added, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents every parameter. The description only reinforces the 'group_by' concept by mentioning grouping by week or month, but adds no new semantics for the remaining parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Generate cash flow forecast') with a specific resource ('unpaid receivables and payables') and defines the expected outputs (inflows, outflows, net flow, running balance). This distinguishes it from sibling reporting tools by focusing on forecast generation from unpaid items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when a cash flow forecast based on unpaid receivables/payables is needed. It does not explicitly mention alternatives or exclusions, but the purpose is specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds crucial details: 'cannot be undone' and 'must not have any transactions.' It also states a return confirmation, adding beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short lines: action, warning, precondition, arg doc, return. Front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter destructive delete, it includes warning, precondition, and return value. Output schema is absent but return is stated. It could specify error behavior (e.g., if account has transactions), but the warning implies it won't proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with account_number defined and constrained (integer 1000-9999). The description repeats the parameter name/type but adds no new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete an account from the chart of accounts,' specifying the verb and resource. It distinguishes from sibling delete tools (e.g., delete_customer, delete_supplier) by targeting accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description warns that the account must not have any transactions, providing a clear precondition for use. It also flags irreversibility. While it doesn't explicitly name alternatives, the precondition serves as a when-not condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds that the action 'cannot be undone' and requires the customer to have no invoices or orders. This goes beyond the annotation by specifying irreversibility and a critical precondition, enriching the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear one-line purpose, a warning, an Args list, and Returns. No unnecessary words or fluff. Every sentence earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation with annotations, the description covers the essential aspects: the action, irreversibility, precondition, and return confirmation. It lacks details on error handling if the customer has invoices, but is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with the description 'Customer number to delete'. The description's Args section merely repeats this information without adding extra syntax, format, or edge-case details. Since schema coverage is high, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a customer from Fortnox', which is a specific verb and resource. This distinguishes it from sibling tools like fortnox_create_customer, fortnox_update_customer, and fortnox_get_customer. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition: 'The customer must not have any invoices or orders.' This implies when not to use the tool, though it does not explicitly name alternatives. The context is clear enough for an agent to decide when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent. The description adds valuable context: it specifies that 'financial_year' uses Fortnox sequential IDs not calendar years, and clarifies that the return includes 'all debit/credit rows.' No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening line, an IMPORTANT caveat, an Args list, and a Returns section. It is somewhat redundant with the schema but stays efficient and front-loads the core purpose. Every section earns its place, though the Args list could be trimmed given schema duplication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read operation with no output schema, the description fully specifies what the agent gets ('Complete voucher details including all debit/credit rows') and the essential prerequisite for financial_year. Combined with the schema's rich parameter descriptions and the annotation set, the tool is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description's Args section largely mirrors schema descriptions. The only added value is the pointer to fortnox_list_financial_years, but that is already embedded in the schema's financial_year description. Therefore, the description adds no significant semantics beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a crisp, specific verb+resource: 'Retrieve detailed information about a specific voucher including all accounting rows.' This clearly distinguishes it from sibling tools like fortnox_list_vouchers (list all) and fortnox_search_vouchers (search) by focusing on a single, fully-detailed voucher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage prerequisite: 'Use fortnox_list_financial_years first to find the correct ID for your target year.' This is practical guidance that prevents misuse. However, it doesn't explicitly state when to prefer this tool over search_vouchers or list_vouchers, but the 'specific voucher' wording implies the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 clear. The description adds useful behavioral details: the age bucket definitions, the return summary/breakdown structure, and the ability to filter by min_amount and supplier_number. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections: purpose, example questions, arguments, return value, age buckets, and examples. It is dense with useful information yet remains scannable and free of fluff. Every section contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description covers the essential context: what it does, what parameters to use, what the report includes, age bucket definitions, and practical examples. It could be more explicit about the exact output structure (e.g., field names), but for a report tool this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter descriptions (e.g., 'Only include invoices with balance >= this amount'). The description's 'Args' section mostly restates the schema, and the examples (min_amount=50000, supplier_number='1') add minor flavor but no new semantic meaning. It meets the baseline for full schema coverage but doesn't elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate an accounts payable aging report for unpaid supplier invoices,' a specific verb and resource. The example questions (e.g., 'What supplier invoices are overdue?') further clarify the tool's scope and distinguish it from neighboring invoice and report tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example questions effectively convey when to use the tool (e.g., 'Show me aging breakdown of payables'). However, it does not explicitly name alternatives or say when not to use it, though the context is clear enough from the questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and idempotentHint, so the safety profile is covered. The description adds behavioral context by specifying the output contents (counts, values, conversion rates), which is useful. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the main action and resource. It immediately conveys the funnel stages and outputs, with no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a read-only analytics function with full schema coverage and rich annotations. The description covers the core purpose and outputs, which is sufficient for most use cases. It does not mention the period/date-range precedence, but that is already documented in the schema, so the description need not repeat it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already well-documented (period enum, date range patterns, response_format enum). The description adds no parameter-specific semantics beyond what the schema provides, which aligns with the baseline score for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Analyze'), a defined resource ('sales funnel'), and the stages involved (offers → orders → invoices). It also mentions the metrics shown (counts, values, conversion rates), which distinguishes it from sibling tools like fortnox_invoice_summary or fortnox_order_pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool: when analyzing the sales funnel from offers to invoices. It does not explicitly mention alternatives or exclusions, but the stated stages and metrics make the intended use obvious relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond these: the unbooked precondition and that the rows parameter replaces all existing rows. This is important side-effect information not captured by 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence purpose, a succinct Args list, and a Returns line. Every sentence earns its place, and the 'Other fields: Same as create_invoice' shorthand avoids lengthy repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 11-parameter schema, 100% schema coverage, and presence of annotations, the description covers the essential context: it mentions the unbooked restriction, the row-replacement behavior, and the return value. It relies on the sibling create_invoice for field semantics, which is acceptable but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so all 11 parameters are already documented with meaning and constraints. The description restates document_number as required and says rows replaces all existing rows, but both are already present in the schema. 'Other fields: Same as create_invoice' is a minor cross-reference but does not add per-parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update an existing invoice in Fortnox') and identifies the specific resource (existing invoice). It also includes a key scope constraint ('Only unbooked invoices can be updated') that distinguishes it from create_invoice and other invoice operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool is for updating existing unbooked invoices, and explicitly warns that booked invoices cannot be updated. However, it does not explicitly name alternatives (e.g., 'use create_invoice for new invoices'), so the usage guidance is clear but not fully explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read/write nature, idempotency, and destructiveness. The description adds key behavioral detail: 'only provided fields are updated' (partial update semantics) and states that it returns the updated supplier details. This goes beyond what annotations provide, though it does not mention auth requirements or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using one sentence for the purpose and brief bullet-like lines for parameters and return value. It avoids redundant explanations and stays within a few lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool with complete schema descriptions and useful annotations, the description is adequately complete. It covers the essential behavioral aspects (partial update, return value) but relies on referencing create_supplier for field details. Since the schema lists all fields, this is acceptable; a fully self-contained description would have been slightly better.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 17 parameters, so the baseline is 3. The description adds meaningful semantic context by highlighting that supplier_number is required and that all other fields are optional with partial update behavior. This clarifies the effect of omitting fields, which the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing supplier in Fortnox' with a specific verb and resource. It distinguishes from sibling tools like create_supplier and delete_supplier by focusing on the update operation and noting that only provided fields are updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (updating an existing supplier) but does not explicitly mention when to use this tool instead of create_supplier or delete_supplier. It also does not provide exclusions or alternative tool references, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false). The description adds valuable behavioral context beyond annotations: the critical balance requirement ('sum of debits must equal sum of credits'), the minimum of 2 rows, and the return value ('created voucher with assigned voucher number'). The example further clarifies expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, important note, args, returns, and an example. Every sentence provides useful information without redundancy. The 'IMPORTANT' callout emphasizes the critical balance rule, and the example is compact yet complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, nested rows, no output schema), the description is highly complete. It covers the return format, all required parameters, the balance constraint, and includes a realistic example. No output schema exists, so the explicit return description is especially valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description's Args section mostly repeats schema info, but it adds a concrete example showing how to structure rows with debit/credit and descriptions, which clarifies parameter semantics beyond the schema's field-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Create a new voucher (manual accounting entry) in Fortnox.' This clearly distinguishes it from sibling tools like get_voucher, list_vouchers, and list_voucher_series, and the parenthetical clarifies it is for manual entries, not automatic invoice booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'manual accounting entry' implies when this tool is appropriate, but there is no explicit guidance on when to use it versus alternatives (e.g., fortnox_bookkeep_invoice for automatic bookings). No exclusions or alternative mentions are provided, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which the description's 'Retrieve' aligns with. The description adds value by enumerating the returned data categories (contact info, addresses, bank details, payment terms), giving more behavioral context than annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a one-sentence purpose, an Args block, and a Returns section. Every element earns its place with no filler, and the structure allows quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two parameters and an enum, the description fully covers the purpose, parameters, and return content. It explicitly lists the categories of supplier details returned, which compensates for the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description's Args section essentially restates the schema. No additional meaning is added for either parameter beyond what the schema already documents, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('supplier'), and clarifies it targets a specific supplier by number. This distinguishes it from fortnox_list_suppliers (which lists all) and fortnox_get_supplier_invoice (which targets invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is for fetching a single supplier's details by supplier_number. It doesn't explicitly name alternatives like list_suppliers, but the context is unambiguous enough for an agent to select this over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by disclosing what data is returned (supplier info, dates, amounts, line items, payment status) and mentions the required parameter and output format. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-purpose first sentence, a brief Args section, and a Returns section. Every sentence earns its place, with no redundancy or fluff. It is front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with no output schema, the description is complete. It explains the purpose, identifies the required parameter, describes the output format option, and details the return content (including line items and payment status). It covers all necessary operational aspects without needing extra context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameter descriptions: given_number and response_format each have clear descriptions. The description merely restates these in Args (e.g., 'The supplier invoice given number to retrieve' and 'Output format'), adding no additional semantic meaning beyond what the schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Retrieve') and resource ('specific supplier invoice'), including scope ('all line items'). It distinguishes itself from sibling tools like fortnox_list_supplier_invoices (which lists rather than retrieves a single invoice) and fortnox_get_invoice (which targets customer invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when detailed information about a specific supplier invoice is needed. It doesn't explicitly mention alternative tools or exclusions, but the 'specific' qualifier and the name align with typical get-by-ID usage, making the intended use clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral details beyond those annotations: pagination behavior (limit/page), filtering ranges (account numbers 1000-9999), and return shape (account number, description, active status). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: a one-sentence summary, a bulleted Args list, a Returns line, and two practical examples. Every section earns its place, and the text is appropriately sized for a tool with six parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description provides all necessary context: pagination, filtering, return fields, and concrete examples. It fully equips an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter already described in the schema. The description restates the parameters and adds illustrative examples (e.g., 'List revenue accounts: from_account=3000, to_account=3999'), but it does not provide significant additional meaning beyond the schema's existing descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List accounts from the chart of accounts in Fortnox,' using a specific verb and resource. It clearly differentiates from sibling tools like fortnox_get_account (single account) and fortnox_create_account/update_account/delete_account (mutations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: a paginated list with optional filtering, supported by examples such as 'from_account=3000, to_account=3999' for revenue accounts. It stops short of explicitly naming when to use alternatives (e.g., fortnox_get_account for a single account), but the intended use is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by disclosing the non-obvious financial_year sequential ID behavior (not calendar years) and examples of how to use it. It also confirms pagination and return content, adding meaningful behavioral context even though the read-only/idempotent safety profile is already covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, important note, Args list, Returns, and Examples. It is slightly verbose because the Args section largely duplicates schema descriptions, but the note and examples earn their place, making it appropriately sized for a 7-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (series, number, description, date), provides a critical dependency (financial_year ID), and includes usage examples. The combination of pagination, filtering, and the financial_year caveat gives a complete picture for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds value by reinforcing the financial_year semantics, providing concrete examples (e.g., 'ID 4 = 2025'), and explaining the response_format. However, much of the Args section repeats schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists vouchers (accounting entries) from Fortnox with pagination and filtering. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like fortnox_search_vouchers or fortnox_get_voucher, though 'list' implies a plural summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: it is a paginated list for vouchers with optional filters. It explicitly instructs the user to call fortnox_list_financial_years first to resolve the financial_year ID, which is a concrete usage guideline, but it doesn't directly compare to alternative list/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context by stating that it shows pending vs invoiced orders and supports grouping, which goes beyond the safety flags. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and resource. Every word adds value and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analytics tool with rich schema annotations and a full parameter schema, the description sufficiently covers the tool's purpose, output shape, and grouping options. It is complete enough for an agent to select and invoke correctly without additional detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and every parameter is documented. The description's mention of grouping by status, customer, or month aligns with the group_by parameter but adds no new semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Analyze') and names the exact resource ('order pipeline and backlog'), then details the output ('pending vs invoiced orders grouped by status, customer, or month'). This clearly differentiates it from siblings like fortnox_list_orders or fortnox_invoice_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when analyzing order pipeline and backlog with pending vs invoiced comparison. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous and the sibling list makes the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond annotations: it discloses that the search is performed client-side, that financial_year is not a calendar year, and that max_vouchers limits the scan scope. These details help the agent anticipate performance and correctness issues. The annotations already establish read-only/idempotent, so the description complements rather than repeats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with IMPORTANT, Args, Returns, and Examples sections, and the financial-year warning is front-loaded. However, the Args list essentially repeats the schema verbatim, adding redundancy for a 10-parameter tool. Still, the examples and warning earn their place, making it reasonably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 params), the description covers the core purpose, the critical financial_year caveat, scanning limits, and illustrative examples. It lacks explicit output shape details, but no output schema exists and the return is described as matching vouchers. Overall it is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description's Args section largely duplicates the schema descriptions (e.g., financial_year warning is identical). It adds no new parameter semantics beyond examples, so no uplift beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Search vouchers by description text,' a specific verb and resource that clearly differentiates this from sibling tools like fortnox_list_vouchers (list all) and fortnox_get_voucher (single voucher). The additional 'client-side text search' phrase further clarifies the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides important usage context, including the warning that financial_year uses sequential IDs and instructs users to 'Use fortnox_list_financial_years first.' It also gives examples of typical searches. However, it does not explicitly state when to prefer this over fortnox_list_vouchers or exclude other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context by stating the limited return type and that it does not provide full cost data, which helps set expectations beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, with the key limitation '[LIMITED]' front-loaded. It avoids redundancy and every sentence adds information, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no output schema, the description adequately indicates the output type ('cost center list only') and limitations. It also points to a richer alternative, covering the essential context without extraneous detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 7 parameters with complete descriptions (100% coverage), so the description need not repeat parameter details. It adds no extra semantic value, but the schema is sufficient, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Analyze costs by cost center/department' with a specific verb and resource. It also distinguishes itself by noting it 'Returns cost center list only' and directing to a sibling tool for actual data, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage guidance: the '[LIMITED]' marker warns of constraints, and the instruction to 'use fortnox_account_activity with cost center filtering on vouchers' for actual cost center data gives a clear alternative. This satisfies when-to-use and when-not-to-use requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds that the tool is '[LIMITED]' and returns only category structure, not actual expense data, which is valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the core purpose and limitation, the second points to the alternative. No fluff, immediately scannable, and appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description clearly states that the tool returns 'category structure only,' which sets expectations. It also points to the sibling tool for actual data, covering the main functional gap. However, it does not detail what the category structure contains (e.g., totals, counts), so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description does not add specific parameter-level detail beyond what the schema provides, but it reinforces the account_range defaults indirectly via the alternative tool example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes expenses by account class and explicitly notes it 'Returns category structure only.' This distinguishes it from sibling tools like fortnox_account_activity and fortnox_expense_analysis's limited scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when not to use this tool ('For actual expense data, use fortnox_account_activity') and provides a concrete alternative with parameters. This gives the agent clear decision guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds the crucial limitation that it returns only formula and structure, not real data. This goes beyond annotations to prevent misuse, though it could further describe exactly how the formula is returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the critical limitation ('LIMITED' and 'Returns formula and structure only') before pivoting to a practical alternative. Every sentence carries weight, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that intentionally provides only formula and structure, the description is complete enough: it states its limited output, points to the correct tool for actual data, and relies on a fully documented schema for parameter details. A minor gap is not describing what the formula/structure output actually looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of the seven parameters, including enums, defaults, and date format patterns. The tool description adds account range examples for the alternative tool rather than new parameter semantics for this tool, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly identify the tool as 'Gross Margin Trend Analytics' while immediately flagging it as '[LIMITED]' and stating it returns 'formula and structure only.' This precise scope distinguishes it from sibling analytics tools and prevents false expectations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: for actual margin data, use fortnox_account_activity with specific account ranges for revenue (3000-3999) and COGS (4000-4999). This directly answers when to use this tool versus the alternative, which is model behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral details beyond the annotations: it warns about truncation for >10,000 invoices, notes that from_date/to_date are ignored when period is specified, describes error handling ('Returns "Error: ..." if API call fails'), and outlines the return format for both JSON and Markdown. These enrich the read-only, idempotent nature already declared by annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear sections: purpose, example questions, Args, Returns, Examples, and Error Handling. It front-loads the core purpose in the first sentence. However, the Args section largely duplicates the input schema, which adds redundancy and length. The extra examples and error handling justify some length, but the duplication keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 8 parameters and no output schema. The description compensates admirably by detailing the return structure for JSON, describing the Markdown format, explaining truncation and error handling, and providing parameter combination examples. It covers the essential behavioral and output aspects that the schema and annotations do not, making it complete enough for an agent to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description repeats most parameter details already in the schema, adding little new semantic meaning. It does provide useful combination examples (e.g., group_by='customer' with period='this_year') that illustrate parameter interplay, but this is more about usage context than fundamentally new parameter semantics. Thus, it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculate summary statistics for invoices over a period.' It uses a specific verb and resource, and the example questions further clarify that it answers analytical queries about totals, counts, averages, and breakdowns. This distinguishes it from sibling tools like fortnox_list_invoices (which lists raw invoices) and fortnox_unpaid_report (which focuses specifically on unpaid invoices).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool through example questions and examples of parameter combinations (e.g., 'Monthly revenue: period="this_month"', 'Revenue by customer this year: period="this_year", group_by="customer"'). However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance. Still, the context is strong enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by stating the tool is '[LIMITED]' and 'Returns project list only,' which clarifies a key behavioral constraint not fully captured by annotations alone. However, it doesn't go deeper into what 'project list' includes (e.g., project number, name, aggregated metrics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two clear sentences, front-loaded with '[LIMITED]' to immediately set expectations. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 optional parameters, a robust annotation set, and no output schema, the description is fairly complete. It explains the limited scope, specifies the output boundary ('Returns project list only'), and points to the correct alternative for full financials. A minor gap is not describing what fields are in the returned project list, but the sibling alternative mitigates this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions, and the schema description coverage is 100%, so the description doesn't need to add parameter details. The description itself adds no new information about parameters, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Analyze profitability by project.' It also specifies the output scope: 'Returns project list only.' This distinguishes it from sibling tools like fortnox_account_activity and fortnox_invoice_summary, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit alternative usage: 'For actual project financials, use fortnox_account_activity with project filtering on vouchers.' This tells the agent when to choose a different tool, which is exactly the guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutating (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds valuable behavioral details: 'only provided fields are changed' conveys partial-update semantics, and 'Returns: The updated customer details' sets expectations. It does not cover error behavior or authorization, but with annotations present this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one opening sentence, a short Args list, and a one-line Returns statement. No wasted words, and the structure is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has many parameters but the schema fully documents each. The description covers purpose, partial-update behavior, and return value. Given the rich schema and annotations, this is adequately complete, though it could mention failure scenarios (e.g., customer not found) for full contextual coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining that optional fields are updated only when provided (partial update), which is critical for understanding how to use the 17 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Update an existing customer in Fortnox' with a specific verb and resource, clearly distinguishing it from creation (fortnox_create_customer), deletion (fortnox_delete_customer), and read-only tools (fortnox_get_customer, fortnox_list_customers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing customer' implies this tool is for updating already-created customers and not for creating new ones, providing clear context. However, it does not explicitly name alternative tools or state when not to use it, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description explicitly warns that the action cannot be undone and requires the supplier to have no invoices. This adds critical safety context that the annotation alone does not convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a clear main statement, a warning, an args section, and a returns section. Every sentence serves a purpose, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers purpose, danger, prerequisites, and return value. It is complete and sufficient for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter supplier_number is fully described in the schema, and the description restates it without adding new meaning. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes a supplier from Fortnox, using a specific verb and resource. It is distinctly differentiated from sibling tools like fortnox_delete_customer and fortnox_delete_account by naming the exact resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by warning that the supplier must not have invoices, implying when deletion is valid. It doesn't explicitly name alternatives, but the precondition and naming convention make usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral details beyond annotations: pagination, fetch_all auto-pagination with a 10,000-result cap, client-side vs. server-side filtering (min_amount/max_amount), and response format options. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is neatly organized with a summary, Args list, Returns section, and Examples. It is long but appropriately so for 15 parameters, and every part contributes actionable information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully equips an agent to invoke the tool correctly: it explains all parameters, return content (supplier, dates, amounts, status), pagination behavior, filter semantics, client-side filtering, and provides concrete examples. Since there is no output schema, the description's Return section compensates well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with each property having a rich description. The description's Args section mostly mirrors the schema, only adding minor clarifications like 'period overrides from_date/to_date' and 'client-side' for amount filters. It does not substantially enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and a precise resource 'supplier invoices (accounts payable) from Fortnox', which clearly distinguishes it from sibling tools like fortnox_list_invoices (which likely lists customer invoices) and fortnox_list_suppliers. It also communicates the tool's scope with optional filtering and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, listing status filters, date ranges, and examples like 'filter="unpaid"' and 'period="last_month"'. It does not explicitly name alternatives or state when not to use it, but the purpose is unambiguous enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description enriches the readOnly/openWorld/idempotent annotations by disclosing auto-pagination limits (max 10,000 results), client-side filtering behavior for min/max_amount, error handling for rate limits, and optional truncation. This is valuable behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (Args, Returns, Examples, Error Handling). It front-loads the core purpose and keeps each element purposeful, although some details repeat schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 15 parameters and no output schema, the description is comprehensive: it explains return formats for JSON and Markdown, includes pagination details, provides five illustrative examples, and covers error scenarios. This gives the agent sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all 15 parameters with 100% documentation, but the description adds extra semantic value through an organized Args list with defaults, explicit override behavior (period overrides from_date/to_date), and practical examples tying parameters to use cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List invoices from Fortnox accounting system' and explains it provides a paginated list with filtering options. This distinguishes it from related tools like fortnox_get_invoice (single invoice) and fortnox_invoice_summary (summaries). The scope is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed use cases through examples (unpaid invoices, period filters, sorting, fetch_all) and clarifies when to use filters. However, it does not explicitly contrast with alternative tools like fortnox_get_invoice, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds value beyond annotations by stating the return contents (ID, date range, accounting method) and the critical fact that the ids are sequential, not calendar years. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, immediately followed by a crucial warning, an illustrative example, structured args/returns, and no filler. Every sentence contributes necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, one optional param, and no output schema, the description fully covers what the tool returns and why it's useful, including the ID mapping that prevents misuse. With annotations covering safety, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter has a clear enum/default/description. The description repeats the parameter information without adding any new semantics, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List all financial years configured in Fortnox.' It distinguishes from sibling tools by clarifying this tool provides the sequential ID mapping needed by voucher tools, not just a generic list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this tool first to find the correct ID' for voucher tools, with a concrete example mapping ID 4 to a calendar year. This clearly tells when to use this tool in relation to alternatives like fortnox_list_vouchers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive hints. The description adds substantial context beyond that: truncation warnings for >10,000 invoices, error response format, age bucket definitions, and the impact of include_details on output. This far exceeds the baseline expectation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (main description, example questions, Args, Returns, Age Buckets, Examples, Error Handling). It is thorough yet concise, front-loading the core purpose and using bullet-style formatting for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return structure for both JSON and Markdown, lists age buckets, and documents error handling. It also provides enough guidance on parameter combinations to cover the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage of parameter descriptions, so a baseline of 3 applies. The description adds practical examples, default values, and parameter semantics in the Args section, reinforcing but not drastically extending schema information. It earns a 4 because it clarifies usage patterns like min_amount=50000.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb and resource: 'Generate an accounts receivable aging report for unpaid invoices.' It distinguishes this from sibling tools like fortnox_list_invoices (listing) and fortnox_payables_report (payables) by focusing on unpaid invoices and aging buckets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description answers common questions and provides concrete examples (full aging report, large invoices, specific customer). It implies when to use this report versus other financial tools, but does not explicitly name alternatives or exclusionary conditions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavioral details: it warns about truncation when over 10,000 invoices are analyzed, explains error handling ('Error: ...'), and specifies return formats for JSON and Markdown. This adds significant transparency beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear headline, example questions, Args list, Returns section, and Examples, all of which earn their place. It is appropriately detailed given the tool's complexity, and the front-loaded purpose makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no output schema, and sits among many analytics siblings, the description fully compensates by describing return values, providing multiple usage examples, and covering error conditions. It leaves no significant gaps for an agent to invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enriches each parameter beyond the schema by listing them in a clear Args block with defaults and behavioral notes such as 'ignored if period specified'. It also provides examples showing parameter combinations, which the schema alone does not offer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Identify top customers by various metrics' and provides concrete example questions that illustrate the tool's specific purpose of ranking customers. This distinguishes it from sibling tools like list_customers (which lists all customers) and customer_growth (which focuses on growth trends).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context through example questions and parameters, effectively communicating when to use it (analytics on top customers). However, it does not explicitly mention when not to use it or name alternative tools for different analytics needs, so it falls short of the highest bar for explicit exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it fetches voucher details and filters client-side, has a max_vouchers limit, and returns a summary. This goes beyond the annotations and helps the agent understand performance and output implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into sections: core purpose, critical warning, use cases, parameter list, return note, and examples. It is longer than average, but every section earns its place and aids correct invocation; important warnings are placed prominently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description adequately explains what the tool returns (transactions matching account criteria with optional summary). It also covers prerequisites, parameter constraints, and usage examples, making it complete for a read-only reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so the description carries the entire burden of documenting parameters. It enumerates all arguments with types, constraints (e.g., account_numbers max 20, max_vouchers 10-500, response_format enum), and concrete examples, making the tool fully invocable by the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement: "Show all voucher transactions affecting specific account(s)." It clearly distinguishes this tool from sibling tools like fortnox_list_vouchers or fortnox_search_vouchers by focusing on account activity and account-based filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs agents to call fortnox_list_financial_years first to get the correct financial year ID, and warns that the API doesn't support native account filtering, recommending date ranges to limit the scan. Common use cases with example account numbers and ranges provide actionable when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![fortnox-mcp MCP server](https://glama.ai/mcp/servers/erp-mafia/fortnox-mcp/badges/card.svg)](https://glama.ai/mcp/servers/erp-mafia/fortnox-mcp)

Score Badge

Copy to your README.md:

[![fortnox-mcp MCP server](https://glama.ai/mcp/servers/erp-mafia/fortnox-mcp/badges/score.svg)](https://glama.ai/mcp/servers/erp-mafia/fortnox-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/erp-mafia/fortnox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server