Contract
input_schema.json
{
"type": "object",
"required": [
"address"
],
"properties": {
"chain": {
"enum": [
"ethereum",
"polygon",
"bsc",
"avalanche",
"arbitrum",
"optimism",
"fantom",
"base"
],
"type": "string",
"default": "ethereum",
"description": "Chain filter. Can be ethereum, polygon, bsc, avalanche, arbitrum, optimism, fantom, or base. Example: ethereum. Defaults to \"ethereum\"."
},
"limit": {
"type": "integer",
"default": 20,
"maximum": 100,
"minimum": 1,
"description": "Results per page. Example: 20. Defaults to 20."
},
"order": {
"enum": [
"asc",
"desc"
],
"type": "string",
"default": "desc",
"description": "Sort order. The cursor-paginated upstream feed only supports desc correctly; unsupported values are rejected by the handler for correctness. Example: desc. Defaults to \"desc\"."
},
"before": {
"type": "integer",
"maximum": 9007199254740991,
"minimum": 0,
"description": "Cursor for efficient deep pagination: return transactions strictly older than this Unix-seconds timestamp (exclusive). Pass the timestamp of the last item from the previous page; if items may share a second, pass that timestamp + 1 and de-duplicate on tx_hash. Unlike offset (which walks the feed), the number of upstream fetches is bounded by limit and independent of how far back you page. Mutually exclusive with offset. Example: 1704067200."
},
"offset": {
"type": "integer",
"default": 0,
"maximum": 9007199254740991,
"minimum": 0,
"description": "Pagination offset. This feed is cursor-paginated upstream and only the most recent ~1000 transactions are reachable; a larger offset returns an empty page with meta.empty_reason rather than an error. For deep history prefer the before cursor -- its upstream cost is bounded by limit and independent of depth, whereas a large offset is emulated by walking the whole feed. Example: 0. Defaults to 0."
},
"address": {
"type": "string",
"minLength": 1,
"description": "Wallet address — must be a raw 0x-prefixed hex address, not an ENS name. Example: 0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045."
},
"include": {
"type": "string",
"minLength": 1,
"description": "Comma-separated enrichments to attach to each item. Currently valid: labels -- adds from_label and to_label fields with entity information for each counterparty address. Example: labels."
},
"sort_by": {
"enum": [
"timestamp",
"value"
],
"type": "string",
"default": "timestamp",
"description": "Field to sort results by. The cursor-paginated upstream feed only supports timestamp correctly; unsupported values are rejected by the handler for correctness. Example: timestamp. Defaults to \"timestamp\"."
}
},
"additionalProperties": false
}output_schema.json
{
"type": "object",
"required": [
"results"
],
"properties": {
"results": {
"type": "array",
"items": {
"type": "object",
"required": [
"tx_hash",
"from_address",
"to_address",
"value",
"timestamp"
],
"properties": {
"value": {
"type": "string",
"description": "Native token value as a decimal string."
},
"tx_hash": {
"type": "string",
"description": "Transaction hash."
},
"tx_type": {
"type": "string",
"description": "One of send, receive, swap, approve when the upstream classifier resolves a type; absent otherwise (not all transactions get one)."
},
"to_label": {
"type": "object",
"required": [
"address",
"labels",
"entity_name",
"entity_type"
],
"properties": {
"labels": {
"type": "array",
"items": {
"type": "object",
"required": [
"label",
"confidence"
],
"properties": {
"label": {
"type": "string"
},
"confidence": {
"type": "number"
}
},
"additionalProperties": true
}
},
"address": {
"type": "string"
},
"entity_name": {
"type": "string"
},
"entity_type": {
"type": "string"
}
},
"description": "Same shape as from_label above (see that field's description for the full writeup) -- present only when include=labels AND to_address matched a known entity, not guaranteed even then.",
"additionalProperties": true
},
"timestamp": {
"type": "integer",
"description": "Unix seconds."
},
"from_label": {
"type": "object",
"required": [
"address",
"labels",
"entity_name",
"entity_type"
],
"properties": {
"labels": {
"type": "array",
"items": {
"type": "object",
"required": [
"label",
"confidence"
],
"properties": {
"label": {
"type": "string"
},
"confidence": {
"type": "number"
}
},
"additionalProperties": true
}
},
"address": {
"type": "string"
},
"entity_name": {
"type": "string"
},
"entity_type": {
"type": "string"
}
},
"description": "Present only when include=labels AND the address matched a known entity in the upstream label database -- not guaranteed even then: a real widening call (include=labels, WETH contract as one counterparty) returned an item whose to_address matched WETH's own contract with no to_label at all, alongside other items in the same response that did carry labels. When present: address echoes the same value as from_address; labels is an ARRAY of tag entries (plural because an address can carry multiple label tags -- every real sample gathered so far carried exactly one, so this is a schema-shape allowance, not an observed case), each with label (a short tag string, e.g. \"Hot Wallet\", \"UniswapV2Router02\") and confidence (a 0-1 score; every real sample observed across 5 calibration calls was exactly 1 -- variance has not been observed but the field is typed as a general number, not locked to 1). entity_name and entity_type identify the counterparty at the entity level; entity_type values actually observed: cex, dex, stablecoin, blockchain-infra -- not an exhaustive enum, more may exist upstream.",
"additionalProperties": true
},
"to_address": {
"type": "string"
},
"from_address": {
"type": "string"
}
},
"additionalProperties": true
}
}
},
"description": "Wallet transactions, narrowed from the provider's `output.data` array and wrapped as `{results: [...]}`. tx_type is not always present -- the upstream classifier does not always resolve a type for a given transaction.",
"additionalProperties": true
}Pricing
Every real charge, itemised. A model that quietly omits one is a slow financial leak, so nothing here is rolled up, and a charge that only applies to some inputs says so rather than being added in.
Prices in this catalog are the provider's own list price, not your bill: Omnial MCP charges provider cost plus a platform markup on top, so what you are charged is higher than the figure shown. For the exact amount a specific call will cost, run omnial_execute with dry_run: true; that number includes the markup and is what we hold while the call runs. It is a quote, not a cap on the charge.
| Charge | Rate |
|---|---|
Per call Flat, regardless of what comes back | $0.01638 |
- Cost basis
- Not recorded
This tool's catalog entry does not record how its final bill is determined, so we will not tell you whether its cost is fixed before the call or reported by the provider afterwards. Either way what is held is a quote rather than a cap: you are charged what the call actually costs, bounded at 2x the quote.
- Updated
- Sep 8, 2026