Deterministic pre-trade risk checks for AI agents on Robinhood Chain. Returns allow/warn/deny.
Scored across 6 tools
check_token_safety, get_supported_assets, simulate_balance, and verify_audit_trail each target a clearly distinct operation. evaluate_trade and evaluate_trade_paid share the same core purpose and could be momentarily confused, but the descriptions clearly distinguish them by tier ceiling and x402 payment gating.
All six tools follow a consistent snake_case verb_noun pattern (check_, evaluate_, get_, simulate_, verify_). The _paid suffix on evaluate_trade_paid is a predictable variant rather than a convention break.
Six tools is well-scoped for a focused pre-trade risk layer, with each tool covering a distinct capability (safety check, tiered evaluation, registry, simulation, audit). No filler or redundant tools.
The surface covers the core workflow: safety check, tiered trade evaluation, asset registry, balance simulation, and audit verification. Minor gaps remain, such as no explicit way to query account tier/rate-limit status outside of a paid call, but agents can work around this.
Honeypot / contract safety check for any ERC-20 token.
Returns a severity classification (safe / warn / danger), the specific
risk factors detected, and the result of a simulated sell. When
severity=danger, the next evaluate_trade for the same contract is
automatically denied regardless of any other checks.
This is a heuristic bytecode + simulation check, not a formal audit. Use it before trading unknown tokens, memecoins, or any contract that is absent from the official Robinhood Chain registry. It is safe to call repeatedly; no transaction is ever sent.
| Name | Required | Description | Default |
|---|---|---|---|
| contract_address | Yes | Token contract address (0x...). |
| Name | Required | Description |
|---|---|---|
| error | No | If present, the check failed. Do not assume 'safe'. |
| detail | No | |
| guidance | No | |
| severity | No | Overall classification. |
| risk_factors | No | Specific issues detected. |
| sell_simulation_ok | No | Whether a simulated sell succeeded. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, open-world, but the description adds substantial behavior beyond them: the auto-deny cascade on the next evaluate_trade for the same contract, the fact that this is a heuristic bytecode+simulation check rather than a formal audit, and that no transaction is ever sent. These are exactly the traits an agent cannot infer from the annotation block.
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 purpose is front-loaded in the first line, followed by return-shape, cascade behavior, scope caveat, and usage condition — each sentence carries distinct information with no redundancy.
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?
An output schema exists, so return-value documentation is not required, yet the description still previews the classification and risk factors. For a one-parameter read-only check, 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single required contract_address parameter, so the schema already fully documents it. The description adds no format, chain, or validation detail beyond what the schema provides, making the baseline 3 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 opening line states a specific verb and resource — a honeypot/contract safety check for ERC-20 tokens — and the following sentence enumerates exactly what is returned (severity classification, risk factors, simulated sell result). This is clearly distinguishable from siblings like evaluate_trade or verify_audit_trail.
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 concrete usage conditions ('use it before trading unknown tokens, memecoins, or any contract absent from the official Robinhood Chain registry') and explains the downstream consequence for evaluate_trade when severity=danger. It lacks an explicit when-not-to-use statement, but the routing context is clear enough that an agent knows when to reach for it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | "buy" or "sell". | |
| asset | Yes | Asset symbol, e.g. NVDA, AAPL, TSLA, USDG. | |
| amount | Yes | Quantity in token units — NOT a pre-computed USD value. | |
| wallet | Yes | EVM wallet address (0x...) the trade would execute from. | |
| request_id | No | Optional idempotency key. | |
| contract_address | Yes | Token contract address (0x...). Must match the official registry address for that symbol, or the trade is denied as a suspected fake token. | |
| max_slippage_bps | No | Max slippage in basis points (default 100). |
| Name | Required | Description |
|---|---|---|
| tier | No | Tier the wallet was evaluated at (1-3). |
| error | No | If present, no verdict was produced. Treat as a hard stop; do not execute the trade. |
| detail | No | Human-readable detail accompanying `error`, if any. |
| reasons | No | Human-readable reasons. Entries prefixed with 'ADVISORY:' are non-blocking context; all other entries drove the decision. |
| decision | No | Final verdict. 'deny' is a hard stop. |
| guidance | No | Suggested next step accompanying `error`, if any. |
| audit_seq | No | Monotonic sequence number of this decision. |
| price_usd | No | Asset price used for the valuation. |
| audit_hash | No | SHA-256 hash chaining this decision. |
| request_id | No | Echoed idempotency key, if provided. |
| risk_score | No | Composite risk score from 0 (safe) to 100 (blocked). |
| price_source | No | Where the price came from. |
| max_trade_usd | No | USD ceiling for this tier. |
| calculated_notional_usd | No | USD value of the proposed trade. |
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.
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.
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.
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.
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.
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.
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.
Call WITHOUT payment_proof → the tool returns a
PaymentRequiredOutput describing the on-chain payment
(network, asset, amount, payTo, resource).
Settle the payment on-chain using an x402-capable client. The facilitator returns a proof string.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| side | Yes | "buy" or "sell". | |
| asset | Yes | Asset symbol, e.g. NVDA, AAPL, TSLA, USDG. | |
| amount | Yes | Quantity in token units. | |
| wallet | Yes | EVM wallet address (0x...) the trade would execute from. | |
| request_id | No | Optional idempotency key. | |
| payment_proof | No | x402 payment proof from the facilitator. Omit on the first call to receive the payment challenge. | |
| contract_address | Yes | Token contract address (0x...). | |
| max_slippage_bps | No | Max slippage in basis points (default 100). |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
List every asset in the guardrail's official Robinhood Chain registry, with its canonical contract address.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| error | No | If present, the registry was unreachable. |
| assets | No | Registered assets. |
| detail | No | |
| guidance | No |
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.
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.
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.
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.
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.
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 a wallet's ERC-20 balance after a hypothetical trade using eth_call state override. Read-only: no transaction is ever sent.
| Name | Required | Description | Default |
|---|---|---|---|
| delta | Yes | Signed amount (negative = spend). | |
| holder | Yes | Wallet address whose balance is simulated (0x...). | |
| decimals | No | Token decimals (default 18). | |
| token_address | Yes | ERC-20 contract address (0x...). |
| Name | Required | Description |
|---|---|---|
| after | No | Balance after. |
| delta | No | Signed change. |
| error | No | If present, the simulation failed. |
| before | No | Balance before. |
| detail | No | |
| guidance | No |
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.
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.
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.
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.
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.
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 the tamper-evident audit trail for a wallet's past guardrail decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many recent records to verify (1-1000, default 100). | |
| wallet | Yes | EVM wallet address (0x...). |
| Name | Required | Description |
|---|---|---|
| error | No | If present, verification could not run. |
| detail | No | |
| healthy | No | True only if every record's hash matches and the chain is unbroken. |
| guidance | No | |
| records_checked | No | Number of records verified. |
| first_broken_seq | No | Sequence number of the first broken link, if any. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_token_safety4 fields changedOutput schema / properties / detailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / guidanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / severity / defaultAdded value: +"danger"Output schema / requiredRemoved value: -[
- "severity"
-]evaluate_trade10 fields changedOutput schema / properties / calculated_notional_usd / defaultAdded value: +0Output schema / properties / decision / defaultAdded value: +"deny"Output schema / properties / detailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Human-readable detail accompanying `error`, if any."
+}Output schema / properties / guidanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null,
+ "description": "Suggested next step accompanying `error`, if any."
+}Output schema / properties / max_trade_usd / defaultAdded value: +0Output schema / properties / price_source / defaultAdded value: +"unavailable"Output schema / properties / price_usd / defaultAdded value: +0Output schema / properties / risk_score / defaultAdded value: +100Output schema / properties / tier / defaultAdded value: +1Output schema / requiredRemoved value: -[
- "decision",
- "reasons",
- "tier",
- "max_trade_usd",
- "calculated_notional_usd",
- "price_usd",
- "price_source",
- "risk_score"
-]evaluate_trade_paid1 field changedOutput schema / properties / result / anyOfPrevious 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"
+ }
+]get_supported_assets2 fields changedOutput schema / properties / detailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / guidanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}simulate_balance2 fields changedOutput schema / properties / detailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / guidanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}verify_audit_trail4 fields changedOutput schema / properties / detailAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / guidanceAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ],
+ "default": null
+}Output schema / properties / healthy / defaultAdded value: +falseOutput schema / requiredRemoved value: -[
- "healthy"
-]evaluate_trade_paidcheck_token_safetyevaluate_tradeget_supported_assetssimulate_balanceverify_audit_trailDeterministic decision guardrail for AI agents and bots. Verifies pre-trade economics (long-only).
Risk preflight for AI Agent tool actions and Polymarket settlement and execution checks.
Compliance, risk, tax and audit checks for AI trading agents: pre-trade, sizing, wash sales, Reg BI.
AI risk officer: private trading theses, evidence, exit criteria and decision history. No execution.
Add one secure layer between your agents and this server.
