ARADIA | sovereign agentic systems

execute_procurement_order

[PURPOSE]: Submits a binding procurement order for physical turnkey AI hardware. Returns actionable programmatic payment parameters for immediate 100% upfront settlement via BTCPay Crypto or Stripe MPP Fiat. [CO-SIGN MODE]: Set "mode":"propose_to_human" when your human operator must approve the expenditure. This pre-stages a real payable Stripe Checkout session and returns an Executive Procurement Packet (ROI/break-even summary, U.S. v. Heppner privilege-waiver compliance memo, agent partner bounty, and a 1-click human_approval_url) — nothing is charged until the human pays. Drop the URL into your operator's Slack/email/WhatsApp. [WHEN TO USE]: Call when human authorization or agent budget is verified to execute a binding purchase order, or with mode=propose_to_human for co-sign handoff. [WHEN NOT TO USE]: Do not use for price quotes (use query_hardware_specs) or ROI estimates (use calculate_roi). Do not use to check order status (use track_order_status). [SIDE EFFECTS]: Creates an official order record, generates an immutable invoice or payment intent, reserves staging capacity, and writes a session record. Non-destructive.

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	Number of appliance nodes to purchase (1-99).
`po_number`	No	Optional corporate purchase order number.
`sla_active`	No	Whether to attach recurring monthly Managed SLA Support upon delivery.
`sla_monthly`	No	Monthly SLA rate ($1,500 for Spark, $5,000 for Station, $12,500 for B200).
`customer_name`	No	Name of the purchasing agent or executive.
`hardware_tier`	Yes	Hardware tier: spark ($15,125), station ($194,093), or b200 ($505,500).
`customer_email`	Yes	Billing email of the purchasing administrator or treasury manager.
`payment_method`	Yes	Settlement method: stripe_mpp (Fiat Shared Payment Token), btcpay_crypto (BTC/LN/USDT-TRON), stripe_fiat (Card). Wire-invoice procurement runs through the human checkout flow (pricing -> checkout -> billing address) on aradia.com, not via the agent API.
`customer_company`	No	Deploying company, firm, or entity name.
`partner_ref_code`	No	Optional 4-character referral code (e.g. 5FYVQ) to route 10% commission.
`monthly_api_spend_usd`	No	Your current monthly public-cloud API spend. Used in the packet for the break-even months calculation.

Output Schema

Name	Required	Description	Default
`amount_usd`	Yes
`invoice_id`	No
`payment_url`	No
`payment_method`	No
`payment_details`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 26, 2026

changedInput schema / properties / payment_method / description

Previous value: -"Settlement method: stripe_mpp (Fiat Shared Payment Token), btcpay_crypto (BTC/LN/USDT), stripe_fiat (Card), stripe_invoice (Wire invoice)."New value: +"Settlement method: stripe_mpp (Fiat Shared Payment Token), btcpay_crypto (BTC/LN/USDT-TRON), stripe_fiat (Card). Wire-invoice procurement runs through the human checkout flow (pricing -> checkout -> billing address) on aradia.com, not via the agent API."

changedInput schema / properties / payment_method / enum

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

Changed1 schema field changedOct 24, 2026

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",
+  "stripe_invoice"
+]

Changed2 schema fields changedOct 24, 2026

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": "Your current monthly public-cloud API spend. Used in the packet for the break-even months calculation.",
+  "type": "number"
+}

Changed16 schema fields changedSep 8, 2026

changedInput schema / properties / customer_company / description

Previous value: -"Company, DAO, or Organization name associated with this hardware deployment."New value: +"Deploying company, firm, or entity name."

changedInput schema / properties / customer_email / description

Previous value: -"Email address of the purchasing administrator or target billing point."New value: +"Billing email of the purchasing administrator or treasury manager."

changedInput schema / properties / customer_name / description

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

changedInput schema / properties / hardware_tier / description

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

changedInput schema / properties / partner_ref_code / description

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

changedInput schema / properties / payment_method / description

Previous value: -"The preferred settlement method: (a) 'stripe_mpp' for fiat via Shared Payment Token (SPT), (b) 'btcpay_crypto' for raw on-chain BTC/LN/USDT JSON settlement, (c) 'btcpay_usdc_base' for USDC, (d) 'stripe_fiat' for Stripe Checkout URL, (e) 'stripe_invoice' for formal wire invoice."New value: +"Settlement method: stripe_mpp (Fiat Shared Payment Token), btcpay_crypto (BTC/LN/USDT), stripe_fiat (Card), stripe_invoice (Wire invoice)."

changedInput schema / properties / po_number / description

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

changedInput schema / properties / quantity / description

Previous value: -"The number of appliance nodes to purchase."New value: +"Number of appliance nodes to purchase (1-99)."

changedInput schema / properties / sla_active / description

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

changedInput schema / properties / sla_monthly / description

Previous value: -"Monthly SLA cost if active."New value: +"Monthly SLA rate ($1,500 for Spark, $5,000 for Station, $12,500 for B200)."

removedOutput schema / properties / amount_usd / description
```
Removed value: -"Total purchase order amount in USD"
```
removedOutput schema / properties / invoice_id / description
```
Removed value: -"Generated invoice or payment intent ID"
```

removedOutput schema / properties / payment_details / description

Removed value: -"Raw destination addresses and amounts for crypto settlement"

removedOutput schema / properties / payment_method / description
```
Removed value: -"Chosen payment rail"
```
removedOutput schema / properties / payment_url / description
```
Removed value: -"Settlement URL"
```
addedOutput schema / required
```
Added value: +[
+  "amount_usd"
+]
```

First observedAug 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: it declares the order is binding, describes the side effects of creating an official record, immutable invoice or payment intent, staging reservation, and session write. It also clarifies that propose_to_human pre-stages checkout without charging until human payment, which is important for a mutating procurement tool.

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 front-loaded with the purpose and organized into labeled sections for co-sign mode, when to use, when not to use, and side effects. Despite its length, every section carries decision-relevant information for a high-stakes purchase tool.

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 complexity, output schema, and annotation coverage, the description is complete enough for an agent to choose and invoke the tool correctly. It covers purpose, co-sign behavior, exclusions, and side effects, while the output schema handles return-value detail.

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 the schema already documents all 12 parameters in detail. The description adds context for mode and payment behavior, but it does not materially explain the remaining parameters beyond what the schema provides, so the baseline 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 description states a specific verb and resource: submitting a binding procurement order for physical turnkey AI hardware. It also distinguishes this from sibling tools by explicitly naming query_hardware_specs, calculate_roi, and track_order_status for adjacent tasks.

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?

It gives explicit WHEN TO USE and WHEN NOT TO USE sections, including the co-sign handoff case with mode=propose_to_human. The alternatives for price quotes, ROI estimates, and order status are named directly.

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

All ARADIA | sovereign agentic systems tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?