get_supplier_invoicesRetrieve supplier invoices, newest first, with optional company filter and limit to review or approve bookkeeping entries.
Supplier invoices (leverantörsfakturor), newest first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| company | No | Company id or name; may be omitted with one company |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare this as a read-only, idempotent, non-destructive open-world read, so the safety profile is covered. The description contributes only the 'newest first' ordering; it says nothing about pagination, the 50-item default, the 200 cap, or what omitting company does when multiple companies exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence with the key attribute (ordering) front-loaded and no filler. It is efficient, though it errs toward under-specification rather than saying anything wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and rich annotations, the description needn't explain return values, but for a two-parameter list tool where one parameter is undocumented and multi-company behavior is ambiguous, the description leaves material gaps an agent would need filled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%: company is documented in the schema, but limit has no description at all, and the description does not compensate by explaining what limit counts or how ordering interacts with it. The description adds no parameter meaning beyond what the schema already shows for company.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (supplier invoices) and adds the Swedish domain term plus a sort order, so the agent knows what it gets back. However, it supplies no verb (only the name implies 'get') and does not distinguish this list tool from the sibling get_supplier_invoice, which fetches a single invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this list tool rather than get_supplier_invoice, search_wint, or list_missing_documents, and no prerequisites or exclusions are given. The agent must infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.