Skip to main content
Glama

Get an invoice, or search them

eurodns_invoice_get
Read-onlyIdempotent

Retrieve invoice details and line items by ID, or search invoices using filters for creation date, type, status, related order, or billing profile.

Instructions

Returns one invoice with its lines by id, or searches invoices when id is omitted — by createdAfter and createdBefore, invoiceType, invoiceStatuses, orderIds or the invoice profile cipId — paged with page and size. Use it for what was billed and whether it is paid; the filters are ignored when id is given. The order behind a line is in eurodns_order_get and the billing identity in eurodns_invoice_profile_get, not here.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNumeric id of the invoice to return with its lines. Omit it to search invoices with the filters below.
pageNo1-based page number. There is no page meaning everything: walk pages until a short one comes back.
sizeNoResults per page, 1 to 500. A wide page is truncated by the character limit, so prefer a filter to a large size.
cipIdNoNumeric id of the customer invoice profile, from the list eurodns_invoice_profile_get returns when called without an id.
orderIdsNoThe identifier of orders related to the invoices.
sortFieldNoResult field to sort on, spelled as in the response items. Unsorted when omitted.
sortOrderNoASC or DESC; only read with sortField.
invoiceIdsNoThe list of unique invoice identifiers.
invoiceTypeNoKeep only invoices of this type: INVOICE, CREDIT_NOTE, CORRECTIVE_INVOICE or EDITED_INVOICE.
createdAfterNoThe invoice creation date start range.
createdBeforeNoThe invoice creation date end range.
invoiceNumbersNoThe list of invoice numbers.
invoiceStatusesNoKeep only invoices in these statuses, e.g. TO_PAY, PAID or CANCELLED.
relatedInvoiceIdNoThe related invoice identifier. Edited invoices, credit notes and corrective invoices are created based on this invoice.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesResponse body as returned by the API.
statusYesUpstream HTTP status code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv0.10.0
    • addedInput schema / properties / cipId
      Added value: +{
      +  "description": "Numeric id of the customer invoice profile, from the list eurodns_invoice_profile_get returns when called without an id.",
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / createdAfter
      Added value: +{
      +  "description": "The invoice creation date start range.",
      +  "type": "string"
      +}
    • addedInput schema / properties / createdBefore
      Added value: +{
      +  "description": "The invoice creation date end range.",
      +  "type": "string"
      +}
    • addedInput schema / properties / id / description
      Added value: +"Numeric id of the invoice to return with its lines. Omit it to search invoices with the filters below."
    • addedInput schema / properties / invoiceIds
      Added value: +{
      +  "description": "The list of unique invoice identifiers.",
      +  "items": {
      +    "maximum": 9007199254740991,
      +    "minimum": -9007199254740991,
      +    "type": "integer"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / invoiceNumbers
      Added value: +{
      +  "description": "The list of invoice numbers.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / invoiceStatuses
      Added value: +{
      +  "description": "Keep only invoices in these statuses, e.g. TO_PAY, PAID or CANCELLED.",
      +  "items": {
      +    "description": "The invoice status - CANCELLED: the invoice has been cancelled and should no longer be considered. - INTERNAL: the invoice is being processed by our system. - PAID: the invoice has been payed. No other operation is expected on this invoice. - PARTIALLY_PAID: the invoice has been partially paid, but the payment did not cover the invoice full price. Another payment is expected to cover the due leftover amount. - PARTIALLY_REIMBURSED: the invoice was paid, and then partially reimbursed, but the reimbursement did not cover the invoice full price. Another reimbursement is expected to cover the invoice paid amount. - PENDING_PARTIAL_PAYMENT: a payment not covering the full invoice price has been initiated, but has yet to be completed. - PENDING_PAYMENT: a payment covering the full invoice price has been initiated, but has yet to be completed. - PENDING_REIMBURSEMENT: a reimbursement has been initiated, but has yet to be completed. - REIMBURSED: the invoice has been reimbursed in its full paid amount. - TO_PAY: the invoice is outstanding and needs to be paid. - TO_REIMBURSE: the invoice reimbursement has not been initiated yet. - WAITING_PO_NUMBER: the invoice requires a P.O. number to be provided before being processed.",
      +    "enum": [
      +      "INTERNAL",
      +      "TO_PAY",
      +      "NOT_TO_PAY",
      +      "WAITING_PO_NUMBER",
      +      "PENDING_PAYMENT",
      +      "PENDING_PARTIAL_PAYMENT",
      +      "PARTIALLY_PAID",
      +      "PAID",
      +      "TO_REIMBURSE",
      +      "PENDING_REIMBURSEMENT",
      +      "PARTIALLY_REIMBURSED",
      +      "REIMBURSED",
      +      "CANCELLED"
      +    ],
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / invoiceType
      Added value: +{
      +  "description": "Keep only invoices of this type: INVOICE, CREDIT_NOTE, CORRECTIVE_INVOICE or EDITED_INVOICE.",
      +  "enum": [
      +    "INVOICE",
      +    "CREDIT_NOTE",
      +    "CORRECTIVE_INVOICE",
      +    "EDITED_INVOICE"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / orderIds
      Added value: +{
      +  "description": "The identifier of orders related to the invoices.",
      +  "items": {
      +    "maximum": 9007199254740991,
      +    "minimum": -9007199254740991,
      +    "type": "integer"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / page
      Added value: +{
      +  "description": "1-based page number. There is no page meaning everything: walk pages until a short one comes back.",
      +  "maximum": 9007199254740991,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / relatedInvoiceId
      Added value: +{
      +  "description": "The related invoice identifier. Edited invoices, credit notes and corrective invoices are created based on this invoice.",
      +  "maximum": 9007199254740991,
      +  "minimum": -9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / size
      Added value: +{
      +  "description": "Results per page, 1 to 500. A wide page is truncated by the character limit, so prefer a filter to a large size.",
      +  "maximum": 500,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / sortField
      Added value: +{
      +  "description": "Result field to sort on, spelled as in the response items. Unsorted when omitted.",
      +  "type": "string"
      +}
    • addedInput schema / properties / sortOrder
      Added value: +{
      +  "description": "ASC or DESC; only read with sortField.",
      +  "enum": [
      +    "ASC",
      +    "DESC"
      +  ],
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "id"
      -]
  2. First observedv0.9.1

TDQS

A4.5/5.0
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 the key behavioral nuance that filters are ignored when id is given and that results are paged. It doesn't contradict annotations, and the output schema covers return details.

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?

Three sentences with zero filler. The main action is front-loaded, followed by the search filters, then a usage note, and finally pointers to siblings. Every sentence earns its place.

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 dual-mode tool with 14 parameters, the description clearly explains both modes, pagination, and explicitly routes related data to other tools. With an output schema present, an agent has everything needed to decide when and how to call this 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%, so the schema already documents all parameters. The description adds the context that filters apply only when id is omitted, which is also implied by the schema's id description. It doesn't significantly enhance parameter understanding beyond what the schema provides, 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?

States a specific verb and resource: 'Returns one invoice with its lines by id, or searches invoices when id is omitted'. It distinguishes itself from siblings by explicitly pointing to eurodns_order_get and eurodns_invoice_profile_get for related data, so an agent can tell it apart without opening schemas.

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 says when to use it ('Use it for what was billed and whether it is paid') and what it is not for (order behind a line and billing identity are in other tools). It also clarifies that filters are ignored when id is given, guiding the agent on parameter usage.

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