Skip to main content
Glama
Sign In
EUDR Compliance & TRACES-NT Agent

EUDR Compliance & TRACES-NT Agent

by nohosa001-pixel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

eudr_create_payment_order

Creates an on-chain USDC payment order for EUDR SaaS subscriptions with budget guardrails, returning deposit address, amount, invoice number, and QR payload.

Instructions

Creates an on-chain USDC payment order for SaaS plan subscription with budget guardrails. Returns deposit wallet address, amount, invoice number, and QR payload.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "plan_tier": "<plan_tier>",
      "company_name": "<company_name>",
      "contact_email": "<contact_email>"
    },
    "name": "eudr_create_payment_order"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNoBlockchain network for USDC payment.Base (Low Gas $0.01)
plan_tierYesSubscription tier to purchase.
vat_numberNoOptional EU VAT number.
company_nameYesLegal company name.
contact_emailYesContact email for invoice delivery.
billing_countryNoCountry of tax registration.
max_budget_usdcNoOptional AI Agent safety budget cap. Raises error if order amount exceeds this ceiling.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.5
    • changedInput schema / properties / plan_tier / enum
      Previous value: -[
-  "PRO",
-  "ENTERPRISE",
-  "STARTER"
-]New value: +[
+  "PRO",
+  "ENTERPRISE"
+]
  2. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full burden, and it does clarify the operation's outcome by enumerating the returned fields (deposit address, amount, invoice number, QR payload), which usefully implies funds are sent to a deposit address rather than charged directly. It omits key behavioral facts for a financial mutation: whether creating an order reserves or moves funds, whether it requires authentication/API credentials, how long an order stays valid, and whether it is idempotent on repeat calls. The budget-ceiling failure mode is only documented in the schema, not the description.

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, zero filler: the action and its scope come first and the return payload second. Every clause carries information an agent needs, and the size is well matched to a 7-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, listing the return fields is genuinely valuable and compensates for part of the gap. However, for a fund-generating mutation with no annotations, the description leaves out sequencing with eudr_confirm_payment, order expiry, and whether payment is actually executed at creation time, which are material 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 100%, with enums for chain and plan_tier, so the schema already does the heavy lifting and the baseline of 3 applies. The description's phrase 'budget guardrails' lightly echoes max_budget_usdc but adds no format, currency, or interaction detail beyond what the parameter description already says.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Creates') on a specific resource ('on-chain USDC payment order') and scopes it to 'SaaS plan subscription' with 'budget guardrails', which separates it from escrow and micro-payment siblings. It stops short of naming any sibling it is not, so an agent must still infer the boundary versus eudr_generate_pay_link or eudr_agent_micro_pay.

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

Usage Guidelines2/5

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

Nothing states when to choose this over the many adjacent payment tools (eudr_generate_pay_link, eudr_agent_micro_pay, eudr_create_agent_escrow), nor what to do after the order is created (e.g. whether eudr_confirm_payment is the required next step). The only usage signal is the implicit 'subscription plan' scope, which the agent has to extract on its own.

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

Deploy Server

Other Tools