aradia-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

execute_procurement_order

Submits Aradia DGX hardware procurement orders for direct autonomous payment or generates a human co-sign approval packet when an agent hits its spend cap.

Instructions

[PURPOSE]: Submits a procurement order for physical Aradia DGX hardware settling via autonomous treasury (BTC, Lightning, USDT, Stripe MPP) OR generating an Agent Proposal / Human Co-Sign approval packet (mode: 'propose_to_human'). [WHEN TO USE]: Call when an agent is authorized to purchase directly or when an agent hits a spend cap and needs a pre-staged CFO 1-click approval URL. [WHEN NOT TO USE]: Do not use for preliminary quote modeling without intent to procure. [SIDE EFFECTS & BEHAVIOR]: Direct mode generates binding payment links or invoices. Propose_to_human mode generates a non-binding Executive Procurement Packet.

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": {
      "hardware_tier": "<hardware_tier>",
      "customer_email": "<customer_email>",
      "payment_method": "<payment_method>"
    },
    "name": "execute_procurement_order"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No	direct = settle now; propose_to_human = Agent Proposal / Human Co-Sign mode, returns Executive Procurement Packet with 1-click human_approval_url (nothing charged until human pays).	direct
`quantity`	No	The number of appliance nodes to purchase.
`po_number`	No	Optional purchase order number.
`sla_active`	No	Whether SLA is active.
`sla_monthly`	No	Monthly SLA cost.
`customer_name`	No	Name of the AI Agent, Operator, or Administrator executing the order.
`hardware_tier`	Yes	The hardware tier being purchased.
`customer_email`	Yes	Email address of the purchasing administrator or target billing point.
`payment_method`	Yes	The preferred settlement method.
`customer_company`	No	Company, DAO, or Organization name associated with this hardware deployment.
`partner_ref_code`	No	Optional 4-character referral code.
`monthly_api_spend_usd`	No	Current monthly public-cloud API spend, used for the packet break-even calculation.

Output Schema

Name	Required	Description
`amount_usd`	Yes	Total purchase order amount in USD.
`invoice_id`	No	Unique invoice ID or Stripe PaymentIntent ID.
`payment_url`	No	Direct checkout URL for settlement.
`payment_method`	No	Selected payment method rail.
`payment_details`	No	Array of destination wallet addresses and exact crypto amounts for M2M settlement.

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.1.3Nov 12, 2026

changedInput schema / properties / customer_company / description

Previous value: -"Legal company, DAO, medical clinic, or law practice deploying the hardware."New value: +"Company, DAO, or Organization name associated with this hardware deployment."

changedInput schema / properties / customer_email / description

Previous value: -"Valid RFC 5322 email address of the purchasing administrator, executive, or treasury controller where order receipts and delivery tracking are dispatched."New value: +"Email address of the purchasing administrator or target billing point."

changedInput schema / properties / customer_name / description

Previous value: -"Operating name of the purchasing agent, executive, or IT administrator."New value: +"Name of the AI Agent, Operator, or Administrator executing the order."

changedInput schema / properties / hardware_tier / description

Previous value: -"Target hardware platform tier: 'spark' ($15,125 USD), 'station' ($194,093 USD), or 'b200' ($505,500 USD)."New value: +"The hardware tier being purchased."

addedInput schema / properties / mode

Added value: +{
+  "default": "direct",
+  "description": "direct = settle now; propose_to_human = Agent Proposal / Human Co-Sign mode, returns Executive Procurement Packet with 1-click human_approval_url (nothing charged until human pays).",
+  "enum": [
+    "direct",
+    "propose_to_human"
+  ],
+  "type": "string"
+}

addedInput schema / properties / monthly_api_spend_usd

Added value: +{
+  "description": "Current monthly public-cloud API spend, used for the packet break-even calculation.",
+  "type": "number"
+}

changedInput schema / properties / partner_ref_code / description

Previous value: -"Optional 4-character referral code (e.g. '5FYVQ') to route 10% hardware bounty to a referring partner."New value: +"Optional 4-character referral code."

changedInput schema / properties / payment_method / description

Previous value: -"Selected settlement rail: 'stripe_mpp' (fiat via Shared Payment Token), 'btcpay_crypto' (raw on-chain BTC, Lightning BOLT11, or USDT-TRON addresses), 'stripe_fiat' (hosted credit card checkout), or 'stripe_invoice' (formal enterprise wire invoice)."New value: +"The preferred settlement method."

changedInput schema / properties / payment_method / enum

Previous value: -[
-  "stripe_mpp",
-  "btcpay_crypto",
-  "btcpay_btc",
-  "btcpay_usdc_base",
-  "stripe_fiat",
-  "stripe_invoice"
-]New value: +[
+  "stripe_mpp",
+  "btcpay_crypto",
+  "btcpay_btc",
+  "stripe_fiat"
+]

changedInput schema / properties / po_number / description

Previous value: -"Optional corporate purchase order number for institutional accounting."New value: +"Optional purchase order number."

changedInput schema / properties / quantity / description

Previous value: -"Number of turnkey physical appliance nodes to purchase. Integer between 1 and 99. Defaults to 1."New value: +"The number of appliance nodes to purchase."

removedInput schema / properties / sla_active / default
```
Removed value: -false
```

changedInput schema / properties / sla_active / description

Previous value: -"Whether to attach recurring monthly Managed SLA Support upon hardware delivery."New value: +"Whether SLA is active."

addedInput schema / properties / sla_monthly

Added value: +{
+  "description": "Monthly SLA cost.",
+  "type": "number"
+}

Changed12 schema fields changedv0.1.1Sep 13, 2026

addedInput schema / properties / customer_company

Added value: +{
+  "description": "Legal company, DAO, medical clinic, or law practice deploying the hardware.",
+  "type": "string"
+}

addedInput schema / properties / customer_email / description

Added value: +"Valid RFC 5322 email address of the purchasing administrator, executive, or treasury controller where order receipts and delivery tracking are dispatched."

addedInput schema / properties / customer_name

Added value: +{
+  "description": "Operating name of the purchasing agent, executive, or IT administrator.",
+  "type": "string"
+}

addedInput schema / properties / hardware_tier / description

Added value: +"Target hardware platform tier: 'spark' ($15,125 USD), 'station' ($194,093 USD), or 'b200' ($505,500 USD)."

addedInput schema / properties / hardware_tier / enum

Added value: +[
+  "spark",
+  "station",
+  "b200"
+]

addedInput schema / properties / partner_ref_code

Added value: +{
+  "description": "Optional 4-character referral code (e.g. '5FYVQ') to route 10% hardware bounty to a referring partner.",
+  "type": "string"
+}

addedInput schema / properties / payment_method / description

Added value: +"Selected settlement rail: 'stripe_mpp' (fiat via Shared Payment Token), 'btcpay_crypto' (raw on-chain BTC, Lightning BOLT11, or USDT-TRON addresses), 'stripe_fiat' (hosted credit card checkout), or 'stripe_invoice' (formal enterprise wire invoice)."

addedInput schema / properties / payment_method / enum

Added value: +[
+  "stripe_mpp",
+  "btcpay_crypto",
+  "btcpay_btc",
+  "btcpay_usdc_base",
+  "stripe_fiat",
+  "stripe_invoice"
+]

addedInput schema / properties / po_number

Added value: +{
+  "description": "Optional corporate purchase order number for institutional accounting.",
+  "type": "string"
+}

addedInput schema / properties / quantity

Added value: +{
+  "default": 1,
+  "description": "Number of turnkey physical appliance nodes to purchase. Integer between 1 and 99. Defaults to 1.",
+  "type": "integer"
+}

addedInput schema / properties / sla_active

Added value: +{
+  "default": false,
+  "description": "Whether to attach recurring monthly Managed SLA Support upon hardware delivery.",
+  "type": "boolean"
+}

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "amount_usd": {
+      "description": "Total purchase order amount in USD.",
+      "type": "number"
+    },
+    "invoice_id": {
+      "description": "Unique invoice ID or Stripe PaymentIntent ID.",
+      "type": "string"
+    },
+    "payment_details": {
+      "description": "Array of destination wallet addresses and exact crypto amounts for M2M settlement.",
+      "type": "array"
+    },
+    "payment_method": {
+      "description": "Selected payment method rail.",
+      "type": "string"
+    },
+    "payment_url": {
+      "description": "Direct checkout URL for settlement.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "amount_usd"
+  ],
+  "type": "object"
+}

First observedv0.1.0Sep 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the write/external nature is known. The description goes further by disclosing the consequence asymmetry: direct mode creates binding payment links or invoices, while propose_to_human is explicitly non-binding until a human pays — critical context for a money-moving tool. It stops short of covering idempotency, failure/refund behavior, or required authorization scopes.

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?

Three labeled blocks put purpose, trigger, and side effects in a predictable scan order with no filler prose. The bracketed section headers ([PURPOSE], [WHEN TO USE]) consume space that plain sentences could use, but they materially speed parsing of a dense 12-parameter, money-moving tool.

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

Completeness4/5

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

For a 12-parameter mutation with an output schema and annotations, the description covers the two execution modes and their side effects, which is the main ambiguity an agent faces. Remaining gaps (authorization requirements, behavior on payment failure, whether repeated calls create duplicate orders) are real but secondary given the rich schema and existing output schema.

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 coverage is 100%, including enum descriptions for mode and payment_method, so the schema carries the parameter burden. The description's mention of BTC, Lightning, USDT and Stripe MPP loosely echoes the payment_method enum rather than adding new syntax or constraint detail. Baseline 3 applies.

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 first block names a specific verb and resource ('Submits a procurement order') and immediately splits it into two well-defined behaviors (direct settlement vs. propose_to_human packet generation), listing the settlement rails. An agent can distinguish this from query_hardware_specs or calculate_roi without opening any 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?

Explicit WHEN TO USE ('agent is authorized to purchase directly or hits a spend cap') and WHEN NOT TO USE ('preliminary quote modeling without intent to procure'), which routes the agent to the modeling sibling instead. Both the positive and negative conditions are stated, which is rare and valuable.

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

Deploy Server