Skip to main content
Glama
Sign In
Ariadne Nexus

Ariadne Nexus

by dotlink-ops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Institutional RWA Clearing Take-Rate & Bridge Fee Calculator

calculate_clearing_fee
Read-onlyIdempotent

Estimate institutional RWA clearing take-rates, cross-chain bridge tolls, SaaS fees, and net annual clearing costs by membership tier before syndicating a vault or choosing a billing tier.

Instructions

Calculates institutional RWA clearing house take-rates (in basis points and USD), cross-chain settlement bridge tolls, platform SaaS subscription fees, and net annual clearing cost projections across Ariadne Nexus membership tiers. Use when: estimating monthly or annual clearing fees, basis-point take-rates, and cross-chain bridge settlement costs before syndicating an RWA vault or selecting an institutional billing tier. Do not use when: provisioning an API key or generating a live Stripe checkout session (use provision_agent_key instead), or valuing bond CUSIPs (use get_cusip_valuation instead). Behavior: Free, open-access, read-only deterministic calculator ($0.00 USD; requires no apiKey or paymentToken and performs no external network calls or billing mutations).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calculate_clearing_fee"
  }
}

Input Schema

NameRequiredDescriptionDefault
tierNoInstitutional membership tier governing base SaaS fee and clearing take-rate bps discount (e.g., "QUANT_PRO", "INSTITUTIONAL_GOLD", "SOVEREIGN_PRIME"; default: "QUANT_PRO").QUANT_PRO
billing_intervalNoSubscription billing cycle used to calculate platform base fee discounts ("monthly" or "annual"; default: "monthly").monthly
bridge_volume_usdNoProjected monthly cross-chain bridge settlement volume (Base / Solana / Tempo USDC) in USD (e.g., 2500000 for $2.5M/month; default: 2500000).
clearing_volume_usdNoProjected monthly gross RWA transaction volume settled through the clearing house in USD (e.g., 10000000 for $10M/month; default: 10000000).

Output Schema

NameRequiredDescriptionDefault
tierYesSelected institutional membership tier identifier.
tierNameNoHuman-readable institutional tier title.
bridgeFeeUsdYesMonthly cross-chain bridge fee in USD.
bridgeTollBpsNoApplied cross-chain bridge settlement toll in basis points.
billingIntervalNoApplied billing interval.
bridgeVolumeUsdNoMonthly cross-chain bridge volume in USD.
clearingVolumeUsdYesMonthly RWA clearing volume in USD.
baseSubscriptionUsdNoRecurring platform subscription fee in USD.
clearingTakeRateBpsNoApplied clearing take-rate in basis points (1 bp = 0.01%).
clearingTakeRateUsdYesMonthly clearing take-rate fee in USD.
annualizedRunRateUsdNoAnnualized 12-month total clearing and platform fee projection in USD.
totalMonthlyRevenueUsdYesTotal combined monthly platform + clearing + bridge fee in USD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.3

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, but the description adds practical context the annotations cannot express: the tool is free ($0.00 USD), requires no apiKey or paymentToken, and makes no external network calls or billing mutations. For a fee/billing-adjacent tool, that auth-and-cost disclosure is exactly the information an agent needs to avoid misrouting a paid provisioning flow.

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?

Front-loaded with the verb and output set, then cleanly segmented into 'Use when', 'Do not use when', and 'Behavior' blocks. Every sentence carries routing, scoping, or cost/auth information; 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?

With an output schema present, return values need no explanation, and the description covers purpose, routing, prerequisites, and cost. For a zero-required-param, deterministic calculator with full schema coverage, nothing needed to invoke it correctly is missing.

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% with enum values and defaults fully documented, so the schema carries the parameter burden and baseline 3 applies. The description only gestures at tiers and basis points without adding units, ranges, or interaction semantics beyond the schema; note the param description's example value 'SOVEREIGN_PRIME' does not appear in the enum, but that is a schema-side inconsistency, not a gap the description was obligated to fix.

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 opening sentence names a specific verb (Calculates) plus four concrete outputs: clearing take-rates in bps and USD, cross-chain bridge tolls, SaaS subscription fees, and net annual clearing cost projections. This is unmistakably distinct from siblings like provision_agent_key or get_cusip_valuation, which the description also names explicitly.

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 provides an explicit 'Use when' clause (estimating monthly/annual clearing fees, bps take-rates, bridge settlement costs before syndicating a vault or choosing a billing tier) and an explicit 'Do not use when' clause that routes to two named alternative tools. 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.

Deploy Server

Other Tools