aradia-mcp-server

Official

Overview Schema Source Related Servers Discussions Admin

execute_procurement_order

Commit funds to procure turnkey NVIDIA DGX AI hardware, settling upfront via crypto or fiat. Call only after hardware sizing and budget authorization are confirmed.

Instructions

[PURPOSE]: Submits a binding procurement order for physical turnkey private AI hardware (NVIDIA DGX systems) with 100% upfront settlement via BTCPay Server crypto (BTC, Lightning, USDT) or Stripe MPP fiat. [WHEN TO USE]: Call ONLY after hardware sizing has been verified and human or agent budget authorization is confirmed to commit funds for physical appliance procurement. [WHEN NOT TO USE]: Do NOT call to explore prices or VRAM capacities (use query_hardware_specs). Do NOT call to model token savings (use calculate_roi). Do NOT call to inspect past orders (use track_order_status). [PREREQUISITES]: Confirm customer_email and select valid hardware_tier and payment_method. Review CapEx payback via calculate_roi prior to execution. [SIDE EFFECTS & BEHAVIOR]: Irreversible financial mutation. Generates an immutable checkout session or cryptographic invoice, reserves physical inventory in the Staging Studio, and registers an order record. Non-destructive (destructiveHint=false). [FAILURE MODES]: Invoices expire after 30 minutes if unpaid with zero financial liability.

Input Schema

TableJSON Schema

Name	Required	Description
`quantity`	No	Number of turnkey physical appliance nodes to purchase. Integer between 1 and 99. Defaults to 1.
`po_number`	No	Optional corporate purchase order number for institutional accounting.
`sla_active`	No	Whether to attach recurring monthly Managed SLA Support upon hardware delivery.
`customer_name`	No	Operating name of the purchasing agent, executive, or IT administrator.
`hardware_tier`	Yes	Target hardware platform tier: 'spark' ($15,125 USD), 'station' ($194,093 USD), or 'b200' ($505,500 USD).
`customer_email`	Yes	Valid RFC 5322 email address of the purchasing administrator, executive, or treasury controller where order receipts and delivery tracking are dispatched.
`payment_method`	Yes	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).
`customer_company`	No	Legal company, DAO, medical clinic, or law practice deploying the hardware.
`partner_ref_code`	No	Optional 4-character referral code (e.g. '5FYVQ') to route 10% hardware bounty to a referring partner.

Output Schema

TableJSON 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.

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.7/5.0

Behavior5/5

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

While annotations declare readOnlyHint=false and destructiveHint=false, the description adds critical behavioral context beyond this: it describes the irreversibility of the financial mutation, the creation of immutable checkout sessions/invoices, inventory reservation, order record registration, and invoice expiration behavior (30 minutes). This is rich transparency that annotations alone do not provide.

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 structured with labeled sections (PURPOSE, WHEN TO USE, WHEN NOT TO USE, PREREQUISITES, SIDE EFFECTS & BEHAVIOR, FAILURE MODES) that are front-loaded and information-dense. Every sentence earns its place with no filler.

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 of a financial mutation tool with 9 parameters, the description covers purpose, usage boundaries, prerequisites, behavioral side effects, and failure modes. An output schema exists, so return values need not be explained. The coverage is complete for an agent to invoke correctly.

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 thoroughly documents all parameters including enums and pricing tiers. The description adds prerequisite mentions (customer_email, hardware_tier, payment_method) but no additional syntax or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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 purpose section states a specific verb (submits) and resource (binding procurement order) with concrete scope (physical turnkey private AI hardware, settlement rails). It clearly distinguishes itself from siblings like query_hardware_specs and track_order_status by naming them as alternatives for different 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?

The description explicitly lists when to use (only after hardware sizing verified and budget authorization confirmed) and when not to use, naming three specific sibling tools with the corresponding tasks they should be used for instead. This is textbook usage guidance.

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

Deploy Server