eurodns-mcp

Get an invoice profile, or search them

eurodns_invoice_profile_get

Read-onlyIdempotent

Retrieve invoice profile details by ID or search with filters like name, company, country, and active status. Returns billing information and profile ID for subsequent invoice queries.

Instructions

Returns one customer invoice profile — the billing name, address and VAT details invoices are issued to — by id, or searches the account’s profiles when id is omitted, by profileName, companyName, countryCode, active and defaultProfile, paged. Use it to find the id a profile is billed under, then pass that id as cipId to eurodns_invoice_get to list its invoices; the invoices themselves are not here. The termMatchingMode argument says how the text filters compare, EQUALS or CONTAINS for instance.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Numeric id of the invoice profile to return in full. Omit it to search the account’s profiles with the filters below.
`city`	No	The invoice profile city.
`page`	No	1-based page number. There is no page meaning everything: walk pages until a short one comes back.
`size`	No	Results per page, 1 to 500. A wide page is truncated by the character limit, so prefer a filter to a large size.
`email`	No	The invoice profile email address.
`active`	No	The invoice profile active status. Inactive invoice profiles are not selectable by users when placing orders and should only be used for keeping track of past invoices.
`lastName`	No	The invoice profile last name.
`firstName`	No	The invoice profile first name.
`sortField`	No	Result field to sort on, spelled as in the response items. Unsorted when omitted.
`sortOrder`	No	ASC or DESC; only read with sortField.
`companyName`	No	The invoice profile company name.
`countryCode`	No	The invoice profile country code.
`profileName`	No	The display name of the invoice profile.
`defaultProfile`	No	The invoice profile default status.
`termMatchingMode`	No	The match mode to apply on the given `profile-name`, `first-name`, `last-name`, `company-name`, `city` or `email` field.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes	Response body as returned by the API.
`status`	Yes	Upstream HTTP status code.

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv0.10.0Sep 7, 2026

addedInput schema / properties / active

Added value: +{
+  "description": "The invoice profile active status. Inactive invoice profiles are not selectable by users when placing orders and should only be used for keeping track of past invoices.",
+  "type": "boolean"
+}

removedInput schema / properties / cipId

Removed value: -{
-  "maximum": 9007199254740991,
-  "minimum": -9007199254740991,
-  "type": "integer"
-}

addedInput schema / properties / city

Added value: +{
+  "description": "The invoice profile city.",
+  "type": "string"
+}

addedInput schema / properties / companyName

Added value: +{
+  "description": "The invoice profile company name.",
+  "type": "string"
+}

addedInput schema / properties / countryCode

Added value: +{
+  "description": "The invoice profile country code.",
+  "type": "string"
+}

addedInput schema / properties / defaultProfile

Added value: +{
+  "description": "The invoice profile default status.",
+  "type": "boolean"
+}

addedInput schema / properties / email

Added value: +{
+  "description": "The invoice profile email address.",
+  "type": "string"
+}

addedInput schema / properties / firstName

Added value: +{
+  "description": "The invoice profile first name.",
+  "type": "string"
+}

addedInput schema / properties / id

Added value: +{
+  "description": "Numeric id of the invoice profile to return in full. Omit it to search the account’s profiles with the filters below.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / lastName

Added value: +{
+  "description": "The invoice profile last name.",
+  "type": "string"
+}

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 / profileName

Added value: +{
+  "description": "The display name of the invoice profile.",
+  "type": "string"
+}

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"
+}

addedInput schema / properties / termMatchingMode

Added value: +{
+  "description": "The match mode to apply on the given `profile-name`, `first-name`, `last-name`, `company-name`, `city` or `email` field.",
+  "enum": [
+    "EQUALS",
+    "NOT_EQUALS",
+    "CONTAINS",
+    "STARTS_WITH",
+    "ENDS_WITH",
+    "NOT_CONTAINS"
+  ],
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "cipId"
-]
```

First observedv0.9.1Sep 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

The description is consistent with the readOnlyHint, openWorldHint, and idempotentHint annotations, and clearly bounds the operation to returning or searching profiles. It adds helpful context about inactive profiles and chaining to invoice_get, though it does not describe error behavior or edge cases for invalid ids, which are covered only partially 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 compact and information-dense, with no obvious filler. It is somewhat run-on with multiple clauses, but every clause adds relevant context about the tool's purpose, usage, and filtering behavior, so it remains effective and focused.

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 15 optional parameters and existing output schema, the description provides sufficient orientation: it covers the main read/search modes, pagination guidance, the key filter fields, and the integration with eurodns_invoice_get. It does not elaborate on sorting or every filter field, but the rich schema descriptions fill those gaps, making the overall context adequately complete.

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 already provides full descriptions for all 15 parameters, so the baseline is high. The description adds semantic value by explaining the id-versus-filter mode, the meaning of termMatchingMode, and the relationship between profile id and invoice retrieval, which helps clarify the most important parameters 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 tool returns one invoice profile by id or searches account profiles with filters and pagination. It distinguishes itself from related tools by explicitly pointing to eurodns_invoice_get for retrieving invoices and noting that invoices themselves are not returned here.

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 explains when to use the tool: to fetch a single profile by id or search profiles by fields, and then pass the id to eurodns_invoice_get. It also gives negative guidance ('the invoices themselves are not here') and clarifies that filtering is preferred over large page sizes via schema descriptions, making the usage path clear.

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

Deploy Server