Autonomous Model Context Protocol interface for querying on-premise NVIDIA DGX private AI hardware specs, modeling CapEx token ROI, executing M2M procurement, and onboarding into the Aradia Partner Program.
Scored across 6 tools
Each tool targets a clearly distinct resource and action: specs vs. ROI vs. order execution vs. order tracking vs. partner onboarding vs. partner stats. The descriptions explicitly steer away from common confusions, such as query_hardware_specs vs. calculate_roi and execute_procurement_order vs. track_order_status.
All names use consistent snake_case and begin with a clear verb (calculate, execute, onboard, query, track). A few names add an extra noun phrase, such as execute_procurement_order and track_order_status, but the overall verb_noun pattern remains readable and predictable.
Six tools is well-scoped for a hardware procurement and partner program surface. Each tool covers a distinct stage or query type without obvious redundancy or bloat.
The core lifecycle is covered: hardware discovery, ROI modeling, order execution, order tracking, partner onboarding, and partner analytics. Minor operational gaps remain, such as order cancellation/modification or listing past orders, but agents can still complete the primary workflows.
[PURPOSE]: Calculates CapEx payback timeline and token savings comparing on-premise Aradia hardware against recurring cloud LLM API expenditures. [WHEN TO USE]: Use to generate mathematical financial justification reports for human operators or CFOs. [WHEN NOT TO USE]: Do not use if API spend is unknown or zero. For raw specs without financial modeling, call query_hardware_specs. [SIDE EFFECTS]: None (pure mathematical calculation).
| Name | Required | Description | Default |
|---|---|---|---|
| sla_active | No | Set true to measure break-even against the full 5-Yr outlay (CapEx + 60 months of Managed SLA), matching the /pricing/ Payback Matrix SLA-ON mode. Default false (pure CapEx). | |
| target_tier | Yes | Target hardware tier to evaluate: spark ($15,125), station ($194,093), or b200 ($505,500). | |
| monthly_api_spend_usd | Yes | Current or estimated monthly cloud LLM API spend in USD (must be greater than 0). |
| Name | Required | Description |
|---|---|---|
| cost_usd | Yes | |
| sla_active | No | |
| target_system | Yes | |
| break_even_months | Yes | Months until cumulative cloud spend equals the break-even basis: turnkey price (pure CapEx) or CapEx + 60 months of SLA (sla_active=true). |
| five_year_outlay_usd | No | Break-even basis: turnkey price, or CapEx + 60 months of SLA when sla_active=true. |
| checkout_approval_url | No | Pre-staged 1-click human approval checkout URL (nothing charged until a human pays). |
| five_year_cloud_spend_usd | No | 5-year comparison baseline: monthly spend × 60. |
| five_year_net_savings_usd | No | 5-year net dollar savings vs. cloud (positive favors Aradia CapEx). |
| human_justification_report | Yes | Boardroom-ready 5-Year TCO & Compliance Executive Memo (financial position, Section 179 tax note, Heppner/HIPAA/Reg S-P posture, approval URL). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context by stating this is a pure mathematical calculation with no side effects and by specifying the API-spend validity constraint. It does not need to explain return values because an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with bracketed sections for purpose, usage, exclusions, and side effects. Every sentence carries decision-relevant information, with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter financial calculation tool, the definition covers purpose, when to use it, when not to use it, the alternative sibling, and side effects. Because the input schema is fully described and an output schema exists, no further return-format or parameter detail is required for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter meanings, including target_tier enum values and prices, SLA mode, and monthly_api_spend_usd constraints, are already fully documented in the schema. The description reinforces the spend constraint but does not add parameter-level meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: calculating CapEx payback timeline and token savings comparing on-premise Aradia hardware against cloud LLM API spend. It clearly distinguishes this financial modeling tool from the sibling query_hardware_specs by explicitly routing raw-spec requests there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('generate mathematical financial justification reports for human operators or CFOs') and when-not-to-use guidance ('Do not use if API spend is unknown or zero'). It also names the alternative tool to use for raw specs without financial modeling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[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.
| 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. |
| Name | Required | Description |
|---|---|---|
| amount_usd | Yes | |
| invoice_id | No | |
| payment_url | No | |
| payment_method | No | |
| payment_details | No |
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.
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.
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.
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.
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.
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.
[PURPOSE]: Registers an autonomous AI agent or human operator into the Aradia Partner Program to earn 10% hardware bounties ($1,512 to $50,550 USD) and 10% recurring monthly SLA commissions. [WHEN TO USE]: Call ONCE when an agent or human operator wants to register as an affiliate partner to earn commissions and receive a ?ref= tracking ID. [WHEN NOT TO USE]: Do NOT call to purchase equipment (use execute_procurement_order). Do NOT call if you already have a partner code (use query_partner_stats). [SIDE EFFECTS]: Creates an external Stripe Express Connected Account entity, registers a 4-character code in Aradia's ledger, and triggers an account onboarding URL. Non-destructive.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | ISO 3166-1 alpha-2 country code for banking payouts (default: US). | US |
| entity_name | Yes | Operating name of the AI Agent, Operator, or Corporate Entity. | |
| contact_email | Yes | Email address to receive the Stripe Express onboarding verification link. |
| Name | Required | Description |
|---|---|---|
| ref_code | Yes | Unique 4-character referral code |
| partner_id | No | Stripe connected account ID |
| referral_url | Yes | Attributed referral link |
| onboarding_url | Yes | Stripe Express verification link |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses concrete side effects: creation of an external Stripe Express Connected Account, registration of a 4-character ledger code, and triggering an onboarding URL. It also explicitly states 'Non-destructive', matching the destructiveHint=false annotation and adding concrete context beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured with labeled sections (PURPOSE, WHEN TO USE, WHEN NOT TO USE, SIDE EFFECTS) and contains zero filler. Every sentence contributes decision-relevant information, and key constraints are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, output schema present, annotations available, 5 siblings), the description covers all necessary context: what it does, when to use it, when not to use it, and what side effects occur. With an output schema present, return-value details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 three parameters (country, entity_name, contact_email). The description does not add extra parameter-level meaning, but the baseline of 3 applies because the schema carries the full burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Registers') and resource ('Aradia Partner Program'), and immediately clarifies the tool's business purpose (earning bounties and SLA commissions). It also distinguishes itself from siblings by naming execute_procurement_order and query_partner_stats in the WHEN NOT TO USE section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE ('Call ONCE when...') and WHEN NOT TO USE rules, including two named alternatives and conditions that route to them. An agent can decide to call this tool without any inferential gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Retrieves physical compute specs, VRAM limits (128GB GB10 (Spark), 748GB GB300 (Station), 1,440GB B200 Rack), and continuous batching concurrency limits for Aradia DGX systems. [WHEN TO USE]: Call during initial discovery to evaluate hardware sizing, VRAM fit, and multi-agent capacity. [WHEN NOT TO USE]: Do not use for financial payback modeling (use calculate_roi) or order submission (use execute_procurement_order). [SIDE EFFECTS]: None (pure read-only query).
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Target hardware platform tier. If omitted, returns all tiers. |
| Name | Required | Description |
|---|---|---|
| specs | Yes | Hardware specifications and VRAM limits per tier |
| pricing | Yes | Flat-rate turnkey and SLA pricing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the '[SIDE EFFECTS]: None (pure read-only query)' line largely restates structured data. It adds useful scoping context (this is a discovery-stage sizing query, not a mutation), but says nothing about latency, caching, or result shape beyond what the output schema covers. With annotations carrying the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Bracketed section labels front-load purpose, routing rules, and side effects in four short lines with zero filler. Optimal for scanning during tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return-value explanation is unnecessary. Combined with perfect schema coverage and clear annotations, an agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single enum-typed 'tier' parameter whose description already covers the omit-to-return-all-tiers behavior. The description adds no tier-specific guidance. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Retrieves) and a precise resource (physical compute specs, VRAM limits, batching concurrency limits) scoped to Aradia DGX systems. Concrete figures (128GB Spark, 748GB Station, 1,440GB B200 Rack) let an agent immediately distinguish it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit '[WHEN TO USE]' (initial discovery, sizing, VRAM fit, multi-agent capacity) and '[WHEN NOT TO USE]' that names the two alternatives and their conditions (calculate_roi for payback modeling, execute_procurement_order for ordering). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Queries real-time performance analytics, attributed referral counts, and commission payouts for an active Aradia partner node. [WHEN TO USE]: Use to monitor your earned affiliate revenue, check referral click activity, or verify payout status. [WHEN NOT TO USE]: Do not use if you have not registered yet (use onboard_partner first). [SIDE EFFECTS]: None (pure read-only query against sovereign partner ledger).
| Name | Required | Description | Default |
|---|---|---|---|
| ref_code | Yes | Your unique 4-character partner referral code (e.g. 5FYVQ). |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| ref_code | Yes | |
| earnings_usd | No | |
| partner_name | No | |
| referral_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explicitly stating there are no side effects and describing the operation as a 'pure read-only query against sovereign partner ledger', reinforcing safety and data-source context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear labels for purpose, usage, exclusions, and side effects. Every section serves a distinct decision-making need, and the text is compact without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only query with an output schema and strong annotations, the description covers prerequisites, use cases, and exclusions. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents the ref_code parameter clearly with an example. The description does not add much additional meaning about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: querying real-time performance analytics, referral counts, and commission payouts for a partner node. This differentiates it from sibling tools like query_hardware_specs and onboard_partner through concrete resource and output scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit WHEN TO USE and WHEN NOT TO USE sections give clear conditions for selecting this tool. The description also names the alternative (onboard_partner) for unregistered users, which is exactly the kind of routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[PURPOSE]: Tracks the real-time fulfillment, staging QA burn-in, and delivery status of an existing hardware procurement order. [WHEN TO USE]: Use to monitor the operational status of an existing order after calling execute_procurement_order. [WHEN NOT TO USE]: Do not use to place a new order (use execute_procurement_order). [SIDE EFFECTS]: None (pure read-only query against staging records).
| Name | Required | Description | Default |
|---|---|---|---|
| order_id | Yes | The invoice ID or checkout session ID returned when the order was placed. |
| Name | Required | Description |
|---|---|---|
| tier | No | |
| status | Yes | Current fulfillment state: pending, verified, staging_qa, shipped |
| order_id | Yes | |
| staging_phase | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already declare readOnlyHint=true and destructiveHint=false, the description adds valuable behavioral context: it is a pure read-only query against staging records and has no side effects. This aligns with and reinforces the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly organized into labeled sections with no filler. Each section earns its place: purpose, usage, non-usage, and side effects are all addressed in a compact, scannable format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so the description does not need to explain return values. It covers what the tool does, when to use it, when not to use it, and its side-effect profile, making it fully sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 order_id. The description adds context by explaining it is the ID returned when the order was placed via execute_procurement_order, which helps the agent understand the parameter's origin beyond just its type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('tracks') and names the exact resources: fulfillment, staging QA burn-in, and delivery status of an existing hardware procurement order. It also clearly distinguishes the tool from the sibling execute_procurement_order by stating it is for existing orders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit WHEN TO USE and WHEN NOT TO USE sections, including the exact condition (after calling execute_procurement_order) and the alternative tool to use for new orders. This leaves no ambiguity for an agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
execute_procurement_order2 fields changedInput schema / properties / payment_method / descriptionPrevious 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."Input schema / properties / payment_method / enumPrevious value: -[
- "stripe_mpp",
- "btcpay_crypto",
- "btcpay_btc",
- "stripe_fiat",
- "stripe_invoice"
-]New value: +[
+ "stripe_mpp",
+ "btcpay_crypto",
+ "btcpay_btc",
+ "stripe_fiat"
+]calculate_roi4 fields changedOutput schema / properties / checkout_approval_urlAdded value: +{
+ "description": "Pre-staged 1-click human approval checkout URL (nothing charged until a human pays).",
+ "type": "string"
+}Output schema / properties / five_year_cloud_spend_usdAdded value: +{
+ "description": "5-year comparison baseline: monthly spend × 60.",
+ "type": "number"
+}Output schema / properties / five_year_net_savings_usdAdded value: +{
+ "description": "5-year net dollar savings vs. cloud (positive favors Aradia CapEx).",
+ "type": "number"
+}Output schema / properties / human_justification_report / descriptionAdded value: +"Boardroom-ready 5-Year TCO & Compliance Executive Memo (financial position, Section 179 tax note, Heppner/HIPAA/Reg S-P posture, approval URL)."execute_procurement_order1 field changedInput schema / properties / payment_method / enumPrevious 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"
+]calculate_roi4 fields changedInput schema / properties / sla_activeAdded value: +{
+ "description": "Set true to measure break-even against the full 5-Yr outlay (CapEx + 60 months of Managed SLA), matching the /pricing/ Payback Matrix SLA-ON mode. Default false (pure CapEx).",
+ "type": "boolean"
+}Output schema / properties / break_even_months / descriptionAdded value: +"Months until cumulative cloud spend equals the break-even basis: turnkey price (pure CapEx) or CapEx + 60 months of SLA (sla_active=true)."Output schema / properties / five_year_outlay_usdAdded value: +{
+ "description": "Break-even basis: turnkey price, or CapEx + 60 months of SLA when sla_active=true.",
+ "type": "number"
+}Output schema / properties / sla_activeAdded value: +{
+ "type": "boolean"
+}execute_procurement_order2 fields changedInput schema / properties / modeAdded 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"
+}Input schema / properties / monthly_api_spend_usdAdded value: +{
+ "description": "Your current monthly public-cloud API spend. Used in the packet for the break-even months calculation.",
+ "type": "number"
+}aradia_partner_onboardcalculate_roi6 fields changedInput schema / properties / monthly_api_spend_usd / descriptionPrevious value: -"The requesting agent's current average monthly spend on cloud LLM APIs."New value: +"Current or estimated monthly cloud LLM API spend in USD (must be greater than 0)."Input schema / properties / target_tier / descriptionPrevious value: -"The desired Aradia hardware tier."New value: +"Target hardware tier to evaluate: spark ($15,125), station ($194,093), or b200 ($505,500)."Output schema / properties / break_even_months / descriptionRemoved value: -"Calculated payback period in months"Output schema / properties / cost_usd / descriptionRemoved value: -"Turnkey hardware cost in USD"Output schema / properties / human_justification_report / descriptionRemoved value: -"Formatted CapEx justification report"Output schema / properties / target_system / descriptionRemoved value: -"Name of the target DGX appliance"execute_procurement_order16 fields changedInput schema / properties / customer_company / descriptionPrevious value: -"Company, DAO, or Organization name associated with this hardware deployment."New value: +"Deploying company, firm, or entity name."Input schema / properties / customer_email / descriptionPrevious value: -"Email address of the purchasing administrator or target billing point."New value: +"Billing email of the purchasing administrator or treasury manager."Input schema / properties / customer_name / descriptionPrevious value: -"Name of the AI Agent, Operator, or Administrator executing the order."New value: +"Name of the purchasing agent or executive."Input schema / properties / hardware_tier / descriptionPrevious value: -"The hardware tier being purchased."New value: +"Hardware tier: spark ($15,125), station ($194,093), or b200 ($505,500)."Input schema / properties / partner_ref_code / descriptionPrevious 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."Input schema / properties / payment_method / descriptionPrevious 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)."Input schema / properties / po_number / descriptionPrevious value: -"Optional purchase order number for reference."New value: +"Optional corporate purchase order number."Input schema / properties / quantity / descriptionPrevious value: -"The number of appliance nodes to purchase."New value: +"Number of appliance nodes to purchase (1-99)."Input schema / properties / sla_active / descriptionPrevious value: -"Whether SLA is active for this order."New value: +"Whether to attach recurring monthly Managed SLA Support upon delivery."Input schema / properties / sla_monthly / descriptionPrevious value: -"Monthly SLA cost if active."New value: +"Monthly SLA rate ($1,500 for Spark, $5,000 for Station, $12,500 for B200)."Output schema / properties / amount_usd / descriptionRemoved value: -"Total purchase order amount in USD"Output schema / properties / invoice_id / descriptionRemoved value: -"Generated invoice or payment intent ID"Output schema / properties / payment_details / descriptionRemoved value: -"Raw destination addresses and amounts for crypto settlement"Output schema / properties / payment_method / descriptionRemoved value: -"Chosen payment rail"Output schema / properties / payment_url / descriptionRemoved value: -"Settlement URL"Output schema / requiredAdded value: +[
+ "amount_usd"
+]onboard_partnerquery_hardware_specs2 fields changedInput schema / properties / tier / descriptionPrevious value: -"Filter by specific hardware tier. Leave blank for full catalog."New value: +"Target hardware platform tier. If omitted, returns all tiers."Output schema / properties / messageRemoved value: -{
- "description": "Operational notice",
- "type": "string"
-}query_partner_statstrack_order_statusaradia_partner_onboardcalculate_roiexecute_procurement_orderquery_hardware_specs
Add one secure layer between your agents and this server.