get_supplier_invoiceFetch a supplier invoice in full, including its accounting rows, using Fortnox's serial number. Retrieve complete invoice details needed for reconciliation and bookkeeping.
One supplier invoice in full, with its accounting rows. given_number is Fortnox's own serial number for it.
| Name | Required | Description | Default |
|---|---|---|---|
| given_number | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already specify readOnlyHint=true, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds that the invoice is returned 'in full, with its accounting rows', which is useful context on the return structure. However, it doesn't disclose error behavior or what happens if the given_number is invalid, which the annotations don't cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose and followed by a critical parameter clarification. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, rich annotations), the description covers purpose, return content, and parameter meaning. The main gap is lack of explicit routing guidance among similar get/list tools, but the core information is sufficient for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does by explaining that given_number is Fortnox's own serial number, clarifying the identifier's meaning beyond the schema's bare type. This is meaningful added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieving one supplier invoice 'in full, with its accounting rows'. This distinguishes it clearly from list_supplier_invoices (plural). It doesn't explicitly contrast with get_invoice, but the 'supplier' qualifier makes the domain clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a retrieval use case by naming a singular identifier, suggesting it's for fetching a specific invoice. However, it doesn't state when to use this vs list_supplier_invoices or get_invoice, nor does it mention prerequisites like needing a valid serial number.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.