Skip to main content
Glama

Collar Guardrail — Pre-Trade Risk Layer

by io.github.aiguardrail
OverviewDiscussionsAdmin

Server Details

Deterministic pre-trade risk checks for AI agents on Robinhood Chain. Returns allow/warn/deny.

Ownership verified
Status
Healthy
Uptime
100.0% over 23 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Server Listing
Collar Guardrail

TDQS

A3.9/5.0

Scored across 6 tools

Disambiguation4/5

evaluate_trade and evaluate_trade_paid are closely related, but the tier ceilings ($5k vs $25k), rate limits, and x402 payment flow make the boundary clear. The remaining four tools target distinct operations (contract safety, asset registry, balance simulation, audit verification) with no real overlap.

Naming Consistency5/5

Every tool uses a consistent snake_case verb_noun pattern (check_token_safety, evaluate_trade, get_supported_assets, simulate_balance, verify_audit_trail). The _paid suffix is a predictable modifier rather than a convention break.

Tool Count5/5

Six tools is well-scoped for a pre-trade risk layer, with each tool earning its place. Nothing feels padded or missing at the count level.

Completeness4/5

The surface covers the core risk workflow: token safety, tiered trade evaluation, asset registry, balance simulation, and audit verification. Minor gaps exist, such as no direct query for a specific past decision or status/health check of the guardrail, but agents can work around these.

Available Tools

6 tools
check_token_safetyCheck Token SafetyB
Read-onlyIdempotent
Inspect

Honeypot / contract safety check for any ERC-20 token.

ParametersJSON Schema
NameRequiredDescriptionDefault
contract_addressYesToken contract address (0x...).

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoIf present, the check failed. Do not assume 'safe'.
detailNo
guidanceNo
severityNoOverall classification.
risk_factorsNoSpecific issues detected.
sell_simulation_okNoWhether a simulated sell succeeded.

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds only that this is a honeypot/contract-risk evaluation, with no detail on latency, rate limits, what risk dimensions are checked, or whether results are cached. With annotations carrying the burden, a 3 reflects modest added context.

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?

A single front-loaded sentence with no filler; the core action leads and the scope qualifier follows. It is efficiently sized, though the slash construction 'Honeypot / contract safety check' is slightly ambiguous about whether these are two distinct checks or one combined verdict.

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

Completeness3/5

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

An output schema exists, so return values need not be explained, and with one fully-documented parameter the tool is callable as written. However, for a risk-assessment tool the description gives no sense of what the verdict covers (honeypot only, or taxes, ownership, liquidity too) or which chain's addresses are valid, leaving interpretation of results partly to the agent.

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% and the single parameter (contract_address) is already documented as 'Token contract address (0x...)'. The description's 'any ERC-20 token' reinforces the expected input type but adds no format, chain, or validation detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair: a safety/honeypot check scoped to ERC-20 token contracts, which is meaningfully more specific than the bare tool name. The sibling tools (evaluate_trade, simulate_balance, verify_audit_trail) are clearly different operations, so an agent can distinguish this without opening the schema, though the description never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as the paid sibling evaluate_trade_paid. The only usage signal is the phrase 'for any ERC-20 token', which implicitly excludes non-ERC-20 assets but does not tell the agent when this check should be run.

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

evaluate_tradeEvaluate Trade (Free)A
Read-onlyIdempotent
Inspect

Pre-trade risk check for a proposed trade. Call this BEFORE executing any trade and treat a "deny" decision as a hard stop.

Evaluated at a fixed Tier 1 ceiling ($5,000 notional). For higher limits, use evaluate_trade_paid (Tier 2, $25,000) which settles an x402 payment on-chain.

ParametersJSON Schema
NameRequiredDescriptionDefault
sideYes"buy" or "sell".
assetYesAsset symbol, e.g. NVDA, AAPL, TSLA, USDG.
amountYesQuantity in token units — NOT a pre-computed USD value.
walletYesEVM wallet address (0x...) the trade would execute from.
request_idNoOptional idempotency key.
contract_addressYesToken contract address (0x...). Must match the official registry address for that symbol, or the trade is denied as a suspected fake token.
max_slippage_bpsNoMax slippage in basis points (default 100).

Output Schema

ParametersJSON Schema
NameRequiredDescription
tierNoTier the wallet was evaluated at (1-3).
errorNoIf present, no verdict was produced. Treat as a hard stop; do not execute the trade.
detailNoHuman-readable detail accompanying `error`, if any.
reasonsNoHuman-readable reasons. Entries prefixed with 'ADVISORY:' are non-blocking context; all other entries drove the decision.
decisionNoFinal verdict. 'deny' is a hard stop.
guidanceNoSuggested next step accompanying `error`, if any.
audit_seqNoMonotonic sequence number of this decision.
price_usdNoAsset price used for the valuation.
audit_hashNoSHA-256 hash chaining this decision.
request_idNoEchoed idempotency key, if provided.
risk_scoreNoComposite risk score from 0 (safe) to 100 (blocked).
price_sourceNoWhere the price came from.
max_trade_usdNoUSD ceiling for this tier.
calculated_notional_usdNoUSD value of the proposed trade.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuine extra context beyond that: the $5,000 Tier 1 evaluation ceiling, the hard-stop semantics of a deny, and the fact that the paid variant settles an x402 payment on-chain.

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?

Two tight paragraphs with zero filler. The critical directive (call before executing; deny is a hard stop) is front-loaded ahead of the tier/alternative details.

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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. The description supplies everything else an agent needs: timing, hard-stop behavior, limit ceiling, and the correct routing to the paid sibling.

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 all seven parameters (including the amount-is-token-quantity and contract-address-registry warnings) are already documented in the schema. The description adds no per-parameter syntax or format detail, so the baseline 3 applies. The tier ceiling it mentions is decision context, not parameter semantics.

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?

States a specific verb and resource ('pre-trade risk check for a proposed trade') and immediately distinguishes itself from the sibling evaluate_trade_paid by naming the Tier 1 $5,000 ceiling. An agent can tell exactly what this does and how it differs from its paid counterpart.

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 ('call this BEFORE executing any trade'), an outcome rule ('treat a "deny" decision as a hard stop'), and a named alternative with the condition that selects it ('for higher limits, use evaluate_trade_paid'). 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.

evaluate_trade_paidEvaluate Trade (x402 Paid, Tier 2)A
Read-onlyIdempotent
Inspect

Pre-trade risk check gated by an x402 payment. Evaluated as COLR Tier 2: $25,000 notional ceiling, 10/25 per-minute rate limits. No COLR holdings are required — the on-chain payment is the credential.

FLOW

  1. Call WITHOUT payment_proof → the tool returns a PaymentRequiredOutput describing the on-chain payment (network, asset, amount, payTo, resource).

  2. Settle the payment on-chain using an x402-capable client. The facilitator returns a proof string.

  3. Call again with payment_proof=<proof> → the tool forwards the proof to the guardrail's x402-paid endpoint and returns a full EvaluateTradeOutput with tier=2.

ParametersJSON Schema
NameRequiredDescriptionDefault
sideYes"buy" or "sell".
assetYesAsset symbol, e.g. NVDA, AAPL, TSLA, USDG.
amountYesQuantity in token units.
walletYesEVM wallet address (0x...) the trade would execute from.
request_idNoOptional idempotency key.
payment_proofNox402 payment proof from the facilitator. Omit on the first call to receive the payment challenge.
contract_addressYesToken contract address (0x...).
max_slippage_bpsNoMax slippage in basis points (default 100).

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly, idempotent, non-destructive). The description adds real behavioral context they cannot convey: the exact notional ceiling ($25,000), per-minute rate limits, the fact that no COLR holdings are required, and the full challenge/settle/retry payment lifecycle. This is genuinely more than the annotations provide.

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?

The purpose and tier constraints are front-loaded in the first paragraph, and the numbered FLOW is well-structured for a multi-call protocol. It is slightly verbose in places (restating the tier twice), but nearly every sentence earns its place given the two-step payment dance.

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?

An output schema exists, so return values need not be spelled out, and the description still names the two response shapes (PaymentRequiredOutput, EvaluateTradeOutput with tier=2) to connect the flow to its outputs. Combined with full parameter coverage and the safety annotations, an agent has everything needed to invoke it 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 parameters are already fully documented. The description's payment_proof explanation largely restates what the schema already says ('Omit on the first call to receive the payment challenge'), and the tier/rate details are tool-level constraints rather than parameter semantics, so this sits at the baseline.

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: 'Pre-trade risk check gated by an x402 payment.' It then pins the exact service tier ('COLR Tier 2') and its limits, which cleanly distinguishes this paid variant from the free `evaluate_trade` sibling without needing to open either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The FLOW section gives unambiguous when-to-use guidance for the two call modes (omit `payment_proof` to get the challenge, then resend with the proof), which is essential for a two-step tool. It stops short of explicitly naming `evaluate_trade` as the free alternative, so the paid-vs-free routing choice is only implied by 'the on-chain payment is the credential.'

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

get_supported_assetsGet Supported AssetsA
Read-onlyIdempotent
Inspect

List every asset in the guardrail's official Robinhood Chain registry, with its canonical contract address.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoIf present, the registry was unreachable.
assetsNoRegistered assets.
detailNo
guidanceNo

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered without the description's help. The description adds that the registry is 'official' and addresses are 'canonical' (a trust/authority signal), but says nothing about list volatility, caching, or registry maintenance — modest additive value over the annotation baseline.

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?

A single sentence that front-loads the action and the scope, with the returned data named at the end. No filler, nothing repeated from the schema or annotations.

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?

For a zero-parameter, read-only enumeration tool with an output schema covering the return shape and annotations covering safety/idempotency, the description supplies everything an agent needs to call it correctly. The remaining question of when to use it belongs to the usage dimension, not completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly presents it as an unfiltered full-list operation, consistent with the empty schema.

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?

States a specific verb ('List') and a precisely scoped resource ('every asset in the guardrail's official Robinhood Chain registry'), plus the key returned field (canonical contract address). None of the siblings (check_token_safety, evaluate_trade, simulate_balance, verify_audit_trail) perform enumeration, so the tool is unambiguously distinguishable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: an agent can infer this is the lookup to run before checking a token or evaluating a trade, but the description never says when to call it, that it is the prerequisite/discovery step, or that it takes no arguments. No alternatives or exclusions are named, so this stays at minimum-viable.

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

simulate_balanceSimulate BalanceA
Read-onlyIdempotent
Inspect

Simulate a wallet's ERC-20 balance after a hypothetical trade using eth_call state override. Read-only: no transaction is ever sent.

ParametersJSON Schema
NameRequiredDescriptionDefault
deltaYesSigned amount (negative = spend).
holderYesWallet address whose balance is simulated (0x...).
decimalsNoToken decimals (default 18).
token_addressYesERC-20 contract address (0x...).

Output Schema

ParametersJSON Schema
NameRequiredDescription
afterNoBalance after.
deltaNoSigned change.
errorNoIf present, the simulation failed.
beforeNoBalance before.
detailNo
guidanceNo

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the description's 'Read-only: no transaction is ever sent' largely restates structured data. It adds some value by naming the mechanism (state override via eth_call), but says nothing about what the simulation ignores (gas, transfer fees, allowances, non-ERC-20 inputs) or failure behavior.

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?

Two sentences, front-loaded with the purpose and scope, zero filler. The safety qualifier is attached to the same breath as the mechanism rather than padding a separate paragraph.

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?

With an output schema present, the description need not explain return values, and it correctly covers what the tool computes and that nothing is broadcast. The remaining gap is the relationship to evaluate_trade and the assumptions the simulation makes, which a 4-param tool could reasonably state.

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% and all four parameters carry descriptions, including the signed semantics of 'delta' and the decimals default, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond that, which is the baseline 3 case.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Simulate a wallet's ERC-20 balance') and adds the mechanism ('eth_call state override'), which is unusually precise for an agent trying to understand what the tool actually computes. It does not, however, explicitly contrast itself with the closest-looking sibling, evaluate_trade, so an agent must infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'after a hypothetical trade' implies the usage context, and the read-only note implies it is safe for speculative checks, but there is no explicit when-to-use, when-not-to-use, or named alternative among check_token_safety / evaluate_trade / evaluate_trade_paid. Usage is implied rather than stated.

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

verify_audit_trailVerify Audit TrailA
Read-onlyIdempotent
Inspect

Verify the tamper-evident audit trail for a wallet's past guardrail decisions.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many recent records to verify (1-1000, default 100).
walletYesEVM wallet address (0x...).

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorNoIf present, verification could not run.
detailNo
healthyNoTrue only if every record's hash matches and the chain is unbroken.
guidanceNo
records_checkedNoNumber of records verified.
first_broken_seqNoSequence number of the first broken link, if any.

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare the operation read-only, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds the meaningful detail that the trail is 'tamper-evident' (i.e., integrity verification), but says nothing about what a failed verification yields or the cost of a large limit.

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?

A single front-loaded sentence with no filler; the verb, object and scope all appear immediately. It is efficient, though it leaves room for one more clause that would have added routing or result context.

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?

With an output schema handling return values and annotations covering the safety profile, the description only needs to convey intent, which it does. The one gap is what verification failure or the limit's practical meaning implies, but nothing critical for a correct call 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%: the schema documents both wallet (EVM address) and limit (1-1000, default 100). The description contributes no additional meaning about either parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb (verify) and resource (tamper-evident audit trail), plus the scope: a wallet's past guardrail decisions. It is clearly distinct from siblings like check_token_safety and evaluate_trade, though it never explicitly names what separates it from them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the phrase 'for a wallet's past guardrail decisions' suggests when it is relevant, but there is no explicit statement of when to reach for this tool versus simulating or evaluating. No exclusions or prerequisites are given.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 6 tool updates
    • Changedcheck_token_safety4 fields changed
      • addedOutput schema / properties / detail
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedOutput schema / properties / guidance
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedOutput schema / properties / severity / default
        Added value: +"danger"
      • removedOutput schema / required
        Removed value: -[
-  "severity"
-]
    • Changedevaluate_trade10 fields changed
      • addedOutput schema / properties / calculated_notional_usd / default
        Added value: +0
      • addedOutput schema / properties / decision / default
        Added value: +"deny"
      • addedOutput schema / properties / detail
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Human-readable detail accompanying `error`, if any."
+}
      • addedOutput schema / properties / guidance
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Suggested next step accompanying `error`, if any."
+}
      • addedOutput schema / properties / max_trade_usd / default
        Added value: +0
      • addedOutput schema / properties / price_source / default
        Added value: +"unavailable"
      • addedOutput schema / properties / price_usd / default
        Added value: +0
      • addedOutput schema / properties / risk_score / default
        Added value: +100
      • addedOutput schema / properties / tier / default
        Added value: +1
      • removedOutput schema / required
        Removed value: -[
-  "decision",
-  "reasons",
-  "tier",
-  "max_trade_usd",
-  "calculated_notional_usd",
-  "price_usd",
-  "price_source",
-  "risk_score"
-]
    • Changedevaluate_trade_paid1 field changed
      • changedOutput schema / properties / result / anyOf
        Previous value: -[
-  {
-    "description": "Result of a pre-trade risk check.",
-    "properties": {
-      "audit_hash": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "SHA-256 hash chaining this decision."
-      },
-      "audit_seq": {
-        "anyOf": [
-          {
-            "type": "integer"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Monotonic sequence number of this decision."
-      },
-      "calculated_notional_usd": {
-        "description": "USD value of the proposed trade.",
-        "type": "number"
-      },
-      "decision": {
-        "description": "Final verdict. 'deny' is a hard stop.",
-        "enum": [
-          "allow",
-          "warn",
-          "deny"
-        ],
-        "type": "string"
-      },
-      "error": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "If present, no verdict was produced. Treat as a hard stop; do not execute the trade."
-      },
-      "max_trade_usd": {
-        "description": "USD ceiling for this tier.",
-        "type": "number"
-      },
-      "price_source": {
-        "description": "Where the price came from.",
-        "enum": [
-          "oracle",
-          "uniswap_v4",
-          "fallback_default",
-          "unavailable"
-        ],
-        "type": "string"
-      },
-      "price_usd": {
-        "description": "Asset price used for the valuation.",
-        "type": "number"
-      },
-      "reasons": {
-        "description": "Human-readable reasons. Entries prefixed with 'ADVISORY:' are non-blocking context; all other entries drove the decision.",
-        "items": {
-          "type": "string"
-        },
-        "type": "array"
-      },
-      "request_id": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "default": null,
-        "description": "Echoed idempotency key, if provided."
-      },
-      "risk_score": {
-        "description": "Composite risk score from 0 (safe) to 100 (blocked).",
-        "type": "integer"
-      },
-      "tier": {
-        "description": "Tier the wallet was evaluated at (1-3).",
-        "type": "integer"
-      }
-    },
-    "required": [
-      "decision",
-      "reasons",
-      "tier",
-      "max_trade_usd",
-      "calculated_notional_usd",
-      "price_usd",
-      "price_source",
-      "risk_score"
-    ],
-    "type": "object"
-  },
-  {
-    "description": "x402 payment challenge returned when no proof is supplied.\n\nThe client is expected to settle this payment on-chain and retry the\ntool with the resulting proof carried in `payment_proof`.",
-    "properties": {
-      "amount": {
-        "description": "Amount in asset base units (6 decimals for USDG).",
-        "type": "string"
-      },
-      "asset": {
-        "description": "USDG contract address.",
-        "type": "string"
-      },
-      "description": {
-        "description": "Human-readable purpose.",
-        "type": "string"
-      },
-      "error": {
-        "default": null,
-        "type": "null"
-      },
-      "max_timeout_seconds": {
-        "description": "Payment validity window in seconds.",
-        "type": "integer"
-      },
-      "network": {
-        "description": "CAIP-2 network id, e.g. eip155:4663.",
-        "type": "string"
-      },
-      "pay_to": {
-        "description": "Recipient address for the payment.",
-        "type": "string"
-      },
-      "resource": {
-        "description": "Resource URL the payment unlocks.",
-        "type": "string"
-      },
-      "status": {
-        "const": "payment_required",
-        "default": "payment_required",
-        "type": "string"
-      },
-      "tier_granted": {
-        "description": "Tier the paid proof grants (2 for x402 paid access).",
-        "type": "integer"
-      }
-    },
-    "required": [
-      "network",
-      "asset",
-      "amount",
-      "pay_to",
-      "resource",
-      "description",
-      "max_timeout_seconds",
-      "tier_granted"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "description": "Result of a pre-trade risk check.",
+    "properties": {
+      "audit_hash": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "SHA-256 hash chaining this decision."
+      },
+      "audit_seq": {
+        "anyOf": [
+          {
+            "type": "integer"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Monotonic sequence number of this decision."
+      },
+      "calculated_notional_usd": {
+        "default": 0,
+        "description": "USD value of the proposed trade.",
+        "type": "number"
+      },
+      "decision": {
+        "default": "deny",
+        "description": "Final verdict. 'deny' is a hard stop.",
+        "enum": [
+          "allow",
+          "warn",
+          "deny"
+        ],
+        "type": "string"
+      },
+      "detail": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Human-readable detail accompanying `error`, if any."
+      },
+      "error": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "If present, no verdict was produced. Treat as a hard stop; do not execute the trade."
+      },
+      "guidance": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Suggested next step accompanying `error`, if any."
+      },
+      "max_trade_usd": {
+        "default": 0,
+        "description": "USD ceiling for this tier.",
+        "type": "number"
+      },
+      "price_source": {
+        "default": "unavailable",
+        "description": "Where the price came from.",
+        "enum": [
+          "oracle",
+          "uniswap_v4",
+          "fallback_default",
+          "unavailable"
+        ],
+        "type": "string"
+      },
+      "price_usd": {
+        "default": 0,
+        "description": "Asset price used for the valuation.",
+        "type": "number"
+      },
+      "reasons": {
+        "description": "Human-readable reasons. Entries prefixed with 'ADVISORY:' are non-blocking context; all other entries drove the decision.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "request_id": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "default": null,
+        "description": "Echoed idempotency key, if provided."
+      },
+      "risk_score": {
+        "default": 100,
+        "description": "Composite risk score from 0 (safe) to 100 (blocked).",
+        "type": "integer"
+      },
+      "tier": {
+        "default": 1,
+        "description": "Tier the wallet was evaluated at (1-3).",
+        "type": "integer"
+      }
+    },
+    "type": "object"
+  },
+  {
+    "description": "x402 payment challenge returned when no proof is supplied.\n\nThe client is expected to settle this payment on-chain and retry the\ntool with the resulting proof carried in `payment_proof`.",
+    "properties": {
+      "amount": {
+        "description": "Amount in asset base units (6 decimals for USDG).",
+        "type": "string"
+      },
+      "asset": {
+        "description": "USDG contract address.",
+        "type": "string"
+      },
+      "description": {
+        "description": "Human-readable purpose.",
+        "type": "string"
+      },
+      "error": {
+        "default": null,
+        "type": "null"
+      },
+      "max_timeout_seconds": {
+        "description": "Payment validity window in seconds.",
+        "type": "integer"
+      },
+      "network": {
+        "description": "CAIP-2 network id, e.g. eip155:4663.",
+        "type": "string"
+      },
+      "pay_to": {
+        "description": "Recipient address for the payment.",
+        "type": "string"
+      },
+      "resource": {
+        "description": "Resource URL the payment unlocks.",
+        "type": "string"
+      },
+      "status": {
+        "const": "payment_required",
+        "default": "payment_required",
+        "type": "string"
+      },
+      "tier_granted": {
+        "description": "Tier the paid proof grants (2 for x402 paid access).",
+        "type": "integer"
+      }
+    },
+    "required": [
+      "network",
+      "asset",
+      "amount",
+      "pay_to",
+      "resource",
+      "description",
+      "max_timeout_seconds",
+      "tier_granted"
+    ],
+    "type": "object"
+  }
+]
    • Changedget_supported_assets2 fields changed
      • addedOutput schema / properties / detail
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedOutput schema / properties / guidance
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • Changedsimulate_balance2 fields changed
      • addedOutput schema / properties / detail
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedOutput schema / properties / guidance
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
    • Changedverify_audit_trail4 fields changed
      • addedOutput schema / properties / detail
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedOutput schema / properties / guidance
        Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}
      • addedOutput schema / properties / healthy / default
        Added value: +false
      • removedOutput schema / required
        Removed value: -[
-  "healthy"
-]
  2. 1 tool update
    • Addedevaluate_trade_paid
  3. 5 tool updates
    • First observedcheck_token_safety
    • First observedevaluate_trade
    • First observedget_supported_assets
    • First observedsimulate_balance
    • First observedverify_audit_trail

Related MCP Connectors

Related MCP Servers

  • RiskPilot

    dushaorighthere
    A
    license
    A
    quality
    B
    maintenance
    Enables AI hosts to propose crypto trades that are checked by a deterministic risk engine, returning LONG, SHORT, or NO_TRADE decisions with refusals and an auditable paper-fill trail.
    3
    MIT

  • agentrisk

    trycoin-ai
    A
    license
    Not graded
    quality
    B
    maintenance
    Provides risk guardrails for AI trading agents by analyzing portfolio risk, checking trades against policies, and generating risk policies.
    68 PyPI
    2
    MIT

  • riskstate-mcp

    Riskstate
    A
    license
    A
    quality
    B
    maintenance
    Deterministic risk governance for crypto trading agents. 5-level policy engine with position sizing, leverage limits, and trade blocking. One tool: get_risk_policy. Supports BTC and ETH.
    4
    39 npm
    1
    MIT
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