Skip to main content
Glama

Get an invoice, or search them

eurodns_invoice_get
Read-onlyIdempotent

Retrieve a specific invoice by ID or search invoices by date, type, status, or order to confirm billed amounts and payment status. Get invoice lines to see exactly what was charged.

Instructions

Returns one invoice with its lines by id, or searches invoices by date, type, status, order or invoice profile when id is omitted. Use it for what was billed and whether it is paid; the order behind a line is in eurodns_order_get, and the billing identity in eurodns_invoice_profile_get.

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. Dates show when Glama detected each change.

  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.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, so the safety profile is fully covered by structured data. The description adds the consequential behavioral trait that omitting the id parameter changes the call from a single-invoice fetch into a search, and it sets scope expectations via sibling routing. It omits pagination and response-shape details, but those are covered by the schema and output schema respectively.

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 with zero filler: the first front-loads the core dual-mode behavior, and the second delivers usage guidance and sibling routing. 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 complex 14-parameter, dual-mode tool, this description combined with a 100%-covered schema, four annotations, and an output schema leaves little unresolved. The only implicit point is that search mode returns a paginated set rather than everything at once, which the page and size parameter descriptions already clarify.

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 and the schema carries the full parameter burden, including per-status enum meanings and pagination quirks. The description contributes only a high-level grouping of filter dimensions (date, type, status, order, invoice profile), which helps quick mapping but adds no new semantics 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 names a specific verb and resource — 'Returns one invoice with its lines by id, or searches invoices' — and covers both operating modes in a single sentence. It also distinguishes itself from siblings by explicitly naming eurodns_order_get and eurodns_invoice_profile_get as the homes for order and billing-identity data.

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 second sentence is an explicit usage directive: 'Use it for what was billed and whether it is paid.' It then names the alternatives for adjacent concerns — 'the order behind a line is in eurodns_order_get, and the billing identity in eurodns_invoice_profile_get' — so an agent knows exactly when not to use this tool.

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

Latest Blog Posts

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/JigSawFr/eurodns-mcp'

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