Skip to main content
Glama
JigSawFr

eurodns-mcp

by JigSawFr
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Get an order, or search them

eurodns_order_get
Read-onlyIdempotent

Fetch order details and delivery status by ID, or search orders by payment status, date, and description. Diagnose why a subscription never became active.

Instructions

Returns one order with its lines and their delivery status by id, or searches orders by status, date and description when id is omitted. Use it to find out what happened to a subscription that was created but never became active; the invoice raised for it is in eurodns_invoice_get.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoNumeric id of the order to return with its lines. Omit it to search orders 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.
termNoThe search term allowing to search orders based on the description of its order lines.
endDateNoThe parameter allowing to search orders before the given date
statusesNoKeep only orders in these payment statuses, e.g. PAID, PENDING_PAYMENT or REFUSED.
ordersIdsNoThe list of order identifiers.
sortFieldNoResult field to sort on, spelled as in the response items. Unsorted when omitted.
sortOrderNoASC or DESC; only read with sortField.
startDateNoThe parameter allowing to search orders after the given date
orderLineIdsNoThe list of order line id related to the orders.
deliveryInProgressNoThe delivery status of the orders. An order delivery is considered in progress once the order payment has been processed but no all order lines are delivered yet.

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. Changed13 schema fields changedv0.10.0
    • addedInput schema / properties / deliveryInProgress
      Added value: +{
+  "description": "The delivery status of the orders. An order delivery is considered in progress once the order payment has been processed but no all order lines are delivered yet.",
+  "type": "boolean"
+}
    • addedInput schema / properties / endDate
      Added value: +{
+  "description": "The parameter allowing to search orders before the given date",
+  "type": "string"
+}
    • addedInput schema / properties / id / description
      Added value: +"Numeric id of the order to return with its lines. Omit it to search orders with the filters below."
    • addedInput schema / properties / orderLineIds
      Added value: +{
+  "description": "The list of order line id related to the orders.",
+  "items": {
+    "maximum": 9007199254740991,
+    "minimum": -9007199254740991,
+    "type": "integer"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / ordersIds
      Added value: +{
+  "description": "The list of order identifiers.",
+  "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 / 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 / startDate
      Added value: +{
+  "description": "The parameter allowing to search orders after the given date",
+  "type": "string"
+}
    • addedInput schema / properties / statuses
      Added value: +{
+  "description": "Keep only orders in these payment statuses, e.g. PAID, PENDING_PAYMENT or REFUSED.",
+  "items": {
+    "description": "The order payment status. - CART: no payment attempts were made. - CREDIT_LINE: an invoice will be sent in relation to the order. - EXPIRED_CART: no payment attempts were made and the cart end of life has been reached. - FRAUD: a payment attempt was flagged as potentially fraudulent. - NO_CHARGE: no payment required. - PAID: a payment has been accepted and completed. - PENDING_PAYMENT: a payment attempt has been initiated. - QUOTE: a payment is required to process the quote - QUOTE_AUTHORIZATION: an authorization approver needs to validate the quote. - REFUSED: a payment attempt has been declined.",
+    "enum": [
+      "CART",
+      "PAID",
+      "CREDIT_LINE",
+      "PENDING_PAYMENT",
+      "REFUSED",
+      "NO_CHARGE",
+      "FRAUD",
+      "QUOTE",
+      "EXPIRED_CART",
+      "QUOTE_AUTHORIZATION"
+    ],
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / term
      Added value: +{
+  "description": "The search term allowing to search orders based on the description of its order lines.",
+  "type": "string"
+}
    • removedInput schema / required
      Removed value: -[
-  "id"
-]
  2. First observedv0.9.1

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the bar for additional disclosure is lower. The description adds meaningful behavioral context: the returned order includes lines and delivery status, and omitting id switches the call into search mode. It also reveals that the related invoice lives in eurodns_invoice_get.

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, no wasted words. The first sentence states the core behavior and the second provides a motivating use case with a sibling pointer. The most important information is front-loaded.

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 read-only retrieval/search tool with a full output schema and strong annotations, the description covers both operational modes, gives a concrete scenario, and names a related tool. The detailed filtering and pagination semantics are already thoroughly documented in the schema, so nothing critical is missing.

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% and the parameter descriptions are already rich, covering id omission, pagination, size truncation, and status enum meanings. The description adds no parameter-level meaning beyond what the schema provides, so the 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?

The description names the exact operation: return one order with its lines and delivery status by id, or search orders by status, date, and description when id is omitted. It clearly distinguishes the dual retrieval/search behavior and differentiates the resource being acted on.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a concrete use case: finding out what happened to a subscription that was created but never became active. It also points to eurodns_invoice_get for the related invoice, which helps route the agent to an alternative. It does not enumerate exclusions versus other sibling search tools, but the context is clear enough.

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

Install Server

Other Tools

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