eudr

Start preparing a Due Diligence Statement

eudr_prepare_dds

Destructive

Compile and sign an Annex II Due Diligence Statement. This WRITES: it stores a compile task holding the operator and supplier details you pass, and sends the plot geometry, HS code, country and quantity to emem.dev to be measured and independently signed. Operator and supplier identity are not forwarded upstream. Returns a task handle; read the outcome with eudr_get_dds. For an organisation's statement it also makes one revocable share link, valid for 7 days, so report_url opens in a browser that is not signed in to eudr.dev; the organisation can withdraw it from its account. Nothing is filed with any authority. Confirm the details with the user first. Costs 5 credits from the organisation's wallet (from 30 October 2026, plus 1 for each plot after the first), refunded automatically if the compile fails; every other tool here is free.

Input Schema

Name	Required	Description
`product`	Yes	What is being placed on the market: its HS code, what it is in words, and its net mass (Annex II point 2).
`operator`	Yes	Who places the goods on the EU market and answers for this statement (Annex II point 1). Not forwarded to the satellite service.
`producer`	No	The primary producer, where that is not the supplier.
`supplier`	Yes	Who the goods were bought from, as the operator's own records name them. Not forwarded to the satellite service.
`geolocation`	Yes	Where it was produced and when it was harvested (Annex II point 3). The plot geometry, country, HS code and quantity are the only things sent to the satellite service.

Output Schema

Name	Required	Description	Default
`state`	No
`task_id`	Yes
`report_url`	Yes
`next_action`	Yes
`data_stored_here`	Yes
`read_outcome_with`	Yes
`data_sent_upstream`	Yes
`report_link_expires_at`	No
`filed_with_any_authority`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 30, 2026

changedInput schema / properties / operator / properties / role / enum

Previous value: -[
-  "operator",
-  "non_sme_trader",
-  "downstream_operator",
-  "sme_trader"
-]New value: +[
+  "operator",
+  "trader_as_operator",
+  "downstream_operator",
+  "sme_trader"
+]

removedInput schema / properties / product / properties / scope_evidence

Removed value: -{
-  "additionalProperties": false,
-  "description": "Needed when the HS code meets an \"ex\" Annex I row (live cattle, palm oil, most wood and rubber) or is wider than its row: the document that shows the product is, or is not, what the row describes. The compile refuses such a code without it and names the row.",
-  "properties": {
-    "annex_i_code": {
-      "description": "The row as printed, e.g. 1511.",
-      "type": "string"
-    },
-    "document_id": {
-      "type": "string"
-    },
-    "within_clause": {
-      "type": "boolean"
-    }
-  },
-  "required": [
-    "document_id",
-    "annex_i_code",
-    "within_clause"
-  ],
-  "type": "object"
-}

Changed2 schema fields changedOct 30, 2026

changedInput schema / properties / operator / properties / role / enum

Previous value: -[
-  "operator",
-  "trader_as_operator",
-  "downstream_operator",
-  "sme_trader"
-]New value: +[
+  "operator",
+  "non_sme_trader",
+  "downstream_operator",
+  "sme_trader"
+]

addedInput schema / properties / product / properties / scope_evidence

Added value: +{
+  "additionalProperties": false,
+  "description": "Needed when the HS code meets an \"ex\" Annex I row (live cattle, palm oil, most wood and rubber) or is wider than its row: the document that shows the product is, or is not, what the row describes. The compile refuses such a code without it and names the row.",
+  "properties": {
+    "annex_i_code": {
+      "description": "The row as printed, e.g. 1511.",
+      "type": "string"
+    },
+    "document_id": {
+      "type": "string"
+    },
+    "within_clause": {
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "document_id",
+    "annex_i_code",
+    "within_clause"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 28, 2026
- addedOutput schema / properties / report_link_expires_at
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```
- changedOutput schema / properties / report_url / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / geolocation / properties / plot_id / description

Previous value: -"The primary plot's own identifier (a field, cadastral or cooperative code)."New value: +"The primary plot's own identifier (a field, cadastral or cooperative code) — never a person's name: it is carried into a signed, public, append-only fact at the evidence provider."

Changed4 schema fields changedOct 15, 2026

addedInput schema / properties / geolocation / description

Added value: +"Where it was produced and when it was harvested (Annex II point 3). The plot geometry, country, HS code and quantity are the only things sent to the satellite service."

addedInput schema / properties / operator / description

Added value: +"Who places the goods on the EU market and answers for this statement (Annex II point 1). Not forwarded to the satellite service."

addedInput schema / properties / product / description

Added value: +"What is being placed on the market: its HS code, what it is in words, and its net mass (Annex II point 2)."

addedInput schema / properties / supplier / description

Added value: +"Who the goods were bought from, as the operator's own records name them. Not forwarded to the satellite service."

Changed2 schema fields changedSep 30, 2026

addedInput schema / properties / geolocation / properties / additional_plots

Added value: +{
+  "description": "Every further plot of the consignment. Each is measured and filed on its own; the consignment is negligible only if every plot is.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "country": {
+        "description": "Only when the plot lies in another country than the consignment's.",
+        "pattern": "^[A-Za-z]{2}$",
+        "type": "string"
+      },
+      "harvest_window": {
+        "type": "string"
+      },
+      "plot_geojson": {
+        "description": "GeoJSON Polygon, MultiPolygon or Point in WGS84.",
+        "type": "object"
+      },
+      "plot_id": {
+        "maxLength": 64,
+        "type": "string"
+      },
+      "quantity_kg": {
+        "description": "This plot's share; omitted, the rest of the consignment is split evenly.",
+        "minimum": 0,
+        "type": "number"
+      }
+    },
+    "required": [
+      "plot_id",
+      "plot_geojson"
+    ],
+    "type": "object"
+  },
+  "maxItems": 500,
+  "type": "array"
+}

addedInput schema / properties / geolocation / properties / plot_id

Added value: +{
+  "description": "The primary plot's own identifier (a field, cadastral or cooperative code).",
+  "maxLength": 64,
+  "type": "string"
+}

First observedSep 22, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the annotations: which fields are forwarded to the external provider and which are withheld (operator/supplier identity), that a revocable 7-day share link is minted for organisations, that nothing is filed with an authority, and the credit cost with refund-on-failure. This substantially softens the destructiveHint=true alert by explaining what is and is not actually at stake.

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?

Front-loads the write semantics and outcome path before the secondary share-link and pricing detail, and nearly every sentence carries operational weight. The dated credit-pricing clause is verbose, though it is real cost information an agent should surface.

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 costly, non-idempotent, externally-visible mutation with nested parameters, the description covers the async task model, the follow-up tool, privacy boundaries, billing, and the reassurance that no regulatory filing occurs. An output schema exists, so not explaining the return shape beyond 'a task handle' is acceptable.

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?

Schema coverage is already 100%, so the baseline is 3; the description adds a genuinely useful data-flow layer by naming exactly which inputs (plot geometry, HS code, country, quantity) leave the system, which no field description states. It does not, however, explain the operator/supplier/product/geolocation split beyond what the schema already documents.

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 artefact ('Compile and sign an Annex II Due Diligence Statement') and immediately frames it as the start of a task whose outcome is read elsewhere. An agent can distinguish it from eudr_get_dds and eudr_export_statement from the description alone.

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?

Explicit handoff ('read the outcome with eudr_get_dds') and an explicit interaction rule ('Confirm the details with the user first'), plus a cost contrast against every other free tool. It stops short of saying when to use it instead of prerequisite siblings like eudr_check_plots or eudr_assess_evidence_gaps before compiling.

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

All eudr tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.