intel

wallet_risk

Requires a ChainHelix API key as bearer token, or 5 cents per call paid over Binance b402 in USDT, USDC, USD1 or U on BNB Smart Chain, or over x402 in USDC on the Base network. Risk profile of one wallet address across chains: risk score, mixer funding and source, dormancy, transaction count and value, protocols used, bridge count, flagged status, plus its recent bridge, mixer and transfer events. Public onchain behaviour only

Input Schema

TableJSON Schema

Name	Required	Description	Default
`chain`	No
`address`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`meta`	No
`source`	No
`address`	Yes
`receipt`	No
`profiled`	Yes
`profiles`	No
`recentEvents`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 21, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"New value: +"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"

Changed1 schema field changedSep 19, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"New value: +"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"

Changed1 schema field changedSep 19, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4"New value: +"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"

Changed3 schema fields changedSep 19, 2026

addedInput schema / x-aliases

Added value: +{
+  "address": [
+    "Address"
+  ]
+}

addedInput schema / x-lexicon

Added value: +{
+  "bundleSha256": "c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4",
+  "name": "ChainHelix Agentic Lexicon",
+  "resolve": "lexicon_resolve",
+  "spec": "lexicon_spec",
+  "version": "0.1.0"
+}

addedInput schema / x-vocab

Added value: +{
+  "address": "onchain.addressApi",
+  "chain": "onchain.chain"
+}

Changed1 schema field changedSep 7, 2026
- addedOutput schema / properties / source
```
Added value: +{
+  "type": [
+    "string",
+    "null"
+  ]
+}
```

Changed2 schema fields changedSep 5, 2026

addedOutput schema / properties / meta

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "contentHash": {
+      "type": "string"
+    },
+    "generated": {
+      "type": "number"
+    },
+    "priceUsd": {
+      "type": "number"
+    },
+    "validUntil": {
+      "type": "number"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / receipt

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "bytes": {
+      "type": "number"
+    },
+    "covers": {
+      "type": "string"
+    },
+    "issuedAt": {
+      "type": "number"
+    },
+    "lookup": {
+      "type": "string"
+    },
+    "network": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "nonce": {
+      "type": "string"
+    },
+    "seq": {
+      "type": "number"
+    },
+    "settleTx": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "sha256": {
+      "type": "string"
+    },
+    "tool": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

AddedAug 24, 2026

TDQS

B3.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses meaningful constraints: authentication via bearer token or per-call payment rails, scope limited to public onchain behaviour, and the specific risk data returned. It does not explicitly state read-only/no state changes or rate limits, but the observational nature is strongly implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Both sentences contain useful information, but the payment detail is front-loaded before the tool's purpose, delaying the 'what does this do' signal. The second sentence is information-dense with the field list, which earns its place, but the overall structure is serviceable rather than exemplary.

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?

An output schema exists, so return-value documentation is already handled. The description adds auth/payment requirements, the all-chains scope, and a detailed enumeration of the risk signals. The main missing context is clearer parameter semantics, but the overall definition is largely complete for invocation.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'address' is a wallet address and says the profile is 'across chains,' which hints at the chain parameter, but it never explains the chain parameter's role, whether it narrows results, or how the returned data changes when omitted. This is a significant gap.

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 clearly identifies the resource ('one wallet address') and enumerates the risk-profile outputs in detail: risk score, mixer funding, dormancy, transaction stats, protocols, bridge count, flagged status, and recent events. It lacks a strong verb and does not explicitly distinguish it from sibling tools, so it stops short of a 5.

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?

No guidance is given on when to use this tool versus alternatives such as screened_payer, buyer_clearance, or victim_flow. The payment/auth requirements are preconditions, not usage criteria. 'Public onchain behaviour only' is a scope note, but it does not help an agent decide between competing tools.

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

All intel tools Inspect

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

Need Help?