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_agent_micro_pay

Executes real-time on-chain USDC micro-payments per plot or batch for autonomous EUDR verification, removing human checkout.

Instructions

Executes autonomous real-time on-chain USDC micro-settlement per plot or batch. Human checkout is excluded.

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": {
      "agent_id": "<agent_id>",
      "num_plots": "<num_plots>",
      "tx_hash": "<tx_hash>",
      "sender_wallet": "<sender_wallet>"
    },
    "name": "eudr_agent_micro_pay"
  }
}

Input Schema

NameRequiredDescriptionDefault
chainNoBlockchain network for USDC micro-payment.Base (Low Gas $0.01)
tx_hashYesOn-chain transaction hash proving USDC transfer to deposit wallet.
agent_idYesUnique autonomous agent identifier or wallet address.
num_plotsYesNumber of plots to verify ($0.05 USDC / plot).
sender_walletYesAgent smart wallet or EOA address.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.5
    • changedInput schema / properties / num_plots / description
      Previous value: -"Number of plots to verify ($0.10 USDC / plot)."New value: +"Number of plots to verify ($0.05 USDC / plot)."
  2. Addedv0.1.1

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description must carry the behavioral burden. It usefully implies that settlement is bound to an existing on-chain transfer (via the tx_hash requirement) and that no human checkout occurs, but it omits idempotency, what happens if the tx_hash is invalid or already consumed, whether the on-chain transfer is re-verified, and the irreversibility of the settlement.

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 short sentences, front-loaded with the action and resource, with the exclusion constraint placed second. Nothing is redundant and every clause carries information.

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

Completeness2/5

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

This is a payment-settling mutation with five parameters, no annotations, and no output schema, so the description should explain what a successful call returns and how failures surface. It says nothing about return values, error behavior, or whether a repeat call with the same tx_hash double-settles, leaving significant gaps for a financial operation.

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%, so all five parameters including the chain enum are already documented, warranting the baseline of 3. The description adds only marginal meaning beyond that, contributing the 'per plot or batch' framing that maps loosely to num_plots but no format or validation detail.

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?

States a specific verb ('Executes') and resource ('autonomous real-time on-chain USDC micro-settlement') with a clear unit of scope ('per plot or batch'). An agent can tell this is a settlement-recording operation rather than a payment-link or escrow tool, though it never names the closest siblings (eudr_agent_eip3009_pay, eudr_confirm_payment) to differentiate explicitly.

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

Usage Guidelines3/5

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

'Human checkout is excluded' implicitly scopes the tool to fully autonomous agent flows, which is a useful negative condition. However, there is no explicit guidance on when to choose this over eudr_agent_eip3009_pay, eudr_confirm_payment, or eudr_create_payment_order, so the agent must infer routing from names alone.

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