Skip to main content
Glama

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. 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

TableJSON Schema
NameRequiredDescriptionDefault
productYes
operatorYes
producerNoThe primary producer, where that is not the supplier.
supplierYes
geolocationYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
stateNo
task_idYes
report_urlYes
next_actionYes
data_stored_hereYes
read_outcome_withYes
data_sent_upstreamYes
filed_with_any_authorityYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • 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"
      +}
  2. First observed

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: discloses the write target (a stored compile task), the external data flow to emem.dev for measurement and independent signing, the privacy boundary ('Operator and supplier identity are not forwarded upstream'), and the async task-handle pattern. It also surfaces cost and refund behavior (5 credits, +1 per additional plot, auto-refund on failure, other tools free), which the annotations cannot express.

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?

Dense but front-loaded: the write behavior, upstream flow and read-back pointer come first, with cost/policy details trailing. Every sentence carries operational information, though the final cost sentence is long and could be split for easier scanning.

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?

Given a rich output schema and strong annotations, the description covers the remaining agent-critical gaps: async task-handle workflow, the read-back tool, upstream data exposure, the no-filing boundary, user confirmation, and the credit cost/refund model. Nothing material is missing for correct invocation.

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 only 20% across 5 nested parameters. The description names what is forwarded upstream (plot geometry, HS code, country, quantity) and that operator/supplier details are stored, which adds some meaning, but it says nothing about producer, harvest_window, additional_plots, or the credit-per-plot implications of the additional_plots array. Baseline 3 for partial compensation of a low-coverage 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?

States a specific verb and resource ('Compile and sign an Annex II Due Diligence Statement') and immediately scopes it as an async compile step distinct from its read counterpart eudr_get_dds. An agent can distinguish it from siblings like eudr_export_statement or eudr_get_dds without opening the schema.

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 routes the agent: 'Returns a task handle; read the outcome with eudr_get_dds', and adds the precondition 'Confirm the details with the user first.' It also clarifies scope with 'Nothing is filed with any authority', which tells the agent what this tool does NOT do versus the filing-related siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.