DPX — Institutional Cross-Border Settlement

mercury.ach_authorize

Destructive

Screen an ACH payment through the DPX compliance oracle before execution. Runs FATF R16, GENIUS Act, MiCA, and AML checks against the recipient. Returns APPROVED / FLAGGED / BLOCKED with full compliance reasoning.

Use this tool BEFORE every ACH payment via mercury.send. ACH is hard to reverse — compliance pre-screening prevents blocked transactions and BSA/AML exposure.

Workflow:

mercury.ach_authorize (screen only, autoExecute:false) → review decision
If APPROVED → set autoExecute:true to send, or call mercury.send directly
If FLAGGED → manual review required before proceeding
If BLOCKED → do not proceed

Input Schema

TableJSON Schema

Name	Required	Description
`note`	No	Payment memo / note (optional).
`amount`	Yes	Payment amount in USD.
`purpose`	No	Payment purpose category (optional — required by Mercury for domesticWire, recommended for ACH). E.g. "Vendor", "Contractor", "Expenses".
`accountId`	Yes	Source Mercury account ID (from mercury.accounts).
`autoExecute`	No	If true and compliance returns APPROVED, immediately sends the ACH payment. Default false — screen first, execute separately.
`recipientId`	Yes	Mercury saved recipient ID (from mercury.send / POST /mercury/recipients).
`externalMemo`	No	External memo / reference visible to recipient (optional).
`recipientName`	Yes	Legal name of the recipient entity or individual — used for compliance screening.
`idempotencyKey`	No	Idempotency key for safe retries. Auto-generated if omitted.

Output Schema

TableJSON Schema

Name	Required	Description
`tier`	No	Compliance tier — FAST_PATH, STANDARD, ENHANCED, or HOLD.
`_next`	No	Guidance on next action.
`reason`	No	Human-readable decision summary.
`decision`	No	Compliance decision.
`executed`	No	True if autoExecute:true and ACH was sent.
`mercuryId`	No	Mercury transaction ID (present when executed).
`authorized`	No	True if compliance approved the payment.
`compliance`	No	Full compliance oracle response including framework attestations.
`requiresReview`	No	True when decision is FLAGGED — manual review required.

TDQS

A4.9/5.0

Behavior5/5

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

The description discloses key behavioral traits beyond the annotations: the tool is a compliance pre-screen, returns one of three statuses, and can optionally auto-execute the payment if approved. It also warns that ACH is hard to reverse, implying irreversible consequences. The annotations (destructiveHint:true, readOnlyHint:false) align, and the description adds context about regulatory exposure (BSA/AML). No contradiction.

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?

The description is compact yet complete: two paragraphs and a bulleted workflow. Every sentence serves a purpose—purpose, usage context, regulatory details, return values, and step-by-step workflow. No fluff or redundancy. The structure front-loads the key action and then provides structured guidance.

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 the tool's complexity (9 parameters, multiple sibling tools like mercury.send and compliance.pep_screen), the description is fully self-contained. It explains the compliance checks, the three possible outcomes, the workflow, and how it integrates with mercury.send. The guaranteed output schema covers return value structure, so the description appropriately focuses on behavior and decision logic.

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?

The input schema has 100% description coverage, so baseline is 3. The description adds value by explaining the workflow intent behind autoExecute (default false, screen first), clarifying that recipientName is used for compliance screening, and noting that accountId comes from mercury.accounts. This enhances agent understanding of how parameters drive the tool's behavior beyond raw schema definitions.

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 clearly states the tool screens an ACH payment through the DPX compliance oracle. It specifies the action ('Screen'), the resource ('ACH payment'), and the compliance checks performed (FATF R16, GENIUS Act, MiCA, AML). The purpose is distinct from sibling tools like mercury.send (which actually sends the payment) and compliance.pep_screen (which screens individuals, not payments).

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?

The description explicitly states when to use the tool: 'before every ACH payment via mercury.send.' It provides a full workflow: screen with autoExecute:false, review the decision, then proceed based on status (APPROVED → send, FLAGGED → manual review, BLOCKED → do not proceed). This clearly differentiates it from mercury.send and gives actionable guidance.

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

All DPX — Institutional Cross-Border Settlement tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, especially within their domains (e.g., analytics, compliance, ESG, forecasting). However, a few tools like route and stability.stablecoin_route or settlement.quote and fx.cost_certainty may cause confusion despite distinct descriptions, and the large number of intelligence tools (cascade, aftershock, contagion, etc.) could lead to misselection without careful reading.

Naming Consistency3/5

Naming follows a domain prefix pattern (e.g., agent.kya_register, settlement.quote, esg.score), which provides some structure. However, inconsistencies exist: some tools use underscores (batch_settle, flow_check), others are single words (route), and the mix of verb_noun and noun_verb styles (e.g., compliance.pep_screen vs market.fx) reduces predictability.

Tool Count3/5

At 71 tools, the server is very broad in scope, covering compliance, ESG, forecasting, intelligence, treasury management, and more. While each tool seems justified for the complex institutional domain, the sheer number may overwhelm agents and makes the set feel bloated. A more focused scope or tighter tool grouping would improve appropriateness.

Completeness4/5

The tool surface is remarkably comprehensive for cross-border settlement, covering end-to-end workflow from quoting, FX analysis, compliance screening, ESG scoring, forecasting, and multiple payment rails (Mercury, Ramp, SWIFT). Minor gaps exist (e.g., no tool to update a settlement after execution), but core operations are well-covered, and the addition of integration and audit trails enhances completeness.

Resources

Need Help?