Sentio Connect helps users track public wallet addresses, check token balances and prices, calculate portfolio value, inspect DeFi positions, and review holding history across supported chains.
Scored across 10 tools
Each tool has a clearly distinct purpose: wallet-address CRUD, wallet balances, portfolio totals, DeFi positions, position history, token-balance history, spot price, and historical price. Overlaps in returned valuation data are resolved by explicit descriptions and consistent scoping (single wallet vs aggregate, spot vs historical, balances vs DeFi positions).
All tools use a consistent snake_case verb_noun pattern, with predictable verbs such as add, remove, list, and get. The naming is uniform across address management, balance, position, and pricing tools.
Ten tools is well-scoped for a crypto portfolio and pricing server, with each tool earning its place. The set covers address management, current valuations, DeFi positions, histories, and spot/historical prices without excessive surface area.
Core lifecycle coverage is strong: tracked-wallet add/list/remove, wallet balances, portfolio value, DeFi positions, position history, token-balance history, and spot/historical token prices. Minor gaps remain, such as no aggregate historical portfolio-value tool or supported-chain/protocol metadata, but agents can work around these.
Track a wallet address for this account, so every other tool (balances, portfolio value, DeFi positions) starts covering it. Accepts a 0x EVM address, a .eth ENS name (resolved to an address before saving) or a 64-hex Sui address. A wallet covers every supported chain of its kind — Ethereum, Optimism, BNB Chain, Monad, Base, Arbitrum, Avalanche for an EVM address or ENS name; Sui for a Sui address — and picks up newly supported chains automatically; the result lists them in chains. Idempotent: an address already tracked comes back as its existing entry, flagged alreadyTracked, instead of being duplicated.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| added | Yes | |
| chains | Yes | |
| family | Yes | |
| address | Yes | |
| ensName | No | |
| createdAt | Yes | |
| alreadyTracked | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint and destructiveHint=false, and the description adds real context beyond that: ENS names are resolved to an address before saving, a wallet fans out across all chains of its kind and picks up new ones automatically, and the response carries `chains` and an `alreadyTracked` flag for the duplicate case.
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?
Four sentences, each doing distinct work: purpose and effect, accepted formats, chain coverage, duplicate handling. The most decision-relevant information comes first and there is no filler.
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?
A one-parameter mutation tool with an output schema — the schema covers the return shape, yet the description still names the salient response fields (`chains`, `alreadyTracked`), so an agent knows what to expect without opening the output schema.
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 0% and the schema only declares a bare string with maxLength 255, so the description carries the full burden — and it does, enumerating the three accepted forms (0x EVM address, .eth ENS name, 64-hex Sui address) and what each one expands to chain-wise.
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 (track) and resource (wallet address) and immediately explains the downstream effect on balances, portfolio value and DeFi position tools, which cleanly distinguishes it from list_wallet_addresses and remove_wallet_address.
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 'so every other tool... starts covering it' gives an implicit ordering cue (add before querying), and the idempotency note tells the agent it is safe to re-add. It never states an explicit when-not condition or names remove_wallet_address as the counterpart, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How the size of one DeFi position changed over the last 24h or 7d, as a series of USD values. Identify the position from a get_defi_positions row: address is the wallet, chain the position's chain id (a numeric EVM chain id, or sui_mainnet), protocol its protocolId, label its label and group its id (labels can repeat within a protocol — e.g. one 'Lending' row per market — and group picks the right one). Values are the position's size at today's prices (the portfolio API does not reprice past states), so the curve shows deposits, withdrawals, accrued debt and rewards — not price moves. range is 24h (13 points · every 2h) or 7d (15 points · every 12h). Each point is one historical portfolio scan, so this call is slow (tens of seconds) — use it for one position at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui | |
| group | No | ||
| label | Yes | ||
| range | No | 24h | |
| address | Yes | ||
| protocol | Yes |
| Name | Required | Description |
|---|---|---|
| range | Yes | |
| points | Yes | |
| target | Yes | |
| valuation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety, but the description adds far more: latency in tens of seconds, that values use today's prices rather than repricing past states, so the curve reflects flows not price moves, and that each point is one historical portfolio scan. These are non-obvious traits an agent needs before calling.
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?
Front-loads what the tool returns, then identification, then semantics, then the latency caveat – a sensible order with no filler. It is dense and long, but nearly every clause carries information the agent could not get from the schema.
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?
Given six parameters, low schema coverage, and an output schema that already documents return shape, the description covers identification, cost, and interpretation. The only minor gap is that it does not state behavior when group is omitted despite being non-required, nor what an insufficient-data window returns.
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 coverage is only 17%, so the description carries the burden and does: it maps address/chain/protocol/label/group to the corresponding fields of a get_defi_positions row, explains that numeric EVM chain ids or sui_mainnet are valid, and clarifies group disambiguates repeated labels like per-market 'Lending' rows. It also gives the range semantics (24h = 13 points every 2h, 7d = 15 points every 12h).
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+resource and the exact quantity returned: how the size of one DeFi position changed over 24h/7d as a series of USD values. It also distinguishes itself from get_defi_positions by positioning that tool as the source of the identifying row rather than a substitute.
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?
Explicitly says to use it for one position at a time because each call is slow (tens of seconds), and tells the agent to derive identifiers from a get_defi_positions row. It stops short of an explicit 'do not use this for current size / use get_defi_positions instead' exclusion, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cross-chain DeFi positions (lending, staking, LPs, rewards) — lending markets, liquid staking, LP pools and more, across every chain the Sentio portfolio API covers (EVM chains for a 0x EVM address, Sui for a 64-hex Sui address). Pass address for one wallet, or pass no arguments to get the positions of every wallet you track in a single call. Each position carries its chain id. A wallet with an error could not be read at all. Across every tracked wallet, each wallet is read from its latest stored portfolio sample (the Sentio API samples tracked wallets hourly): such an entry says source: "sample" and gives its time as asOf. A wallet without a recent sample, and any Sui wallet (its stored history covers fewer protocols), is scanned live (source: "live"). For one wallet's current state, ask for it by address. An aggregate answers within about 40 s: a wallet it could not re-read in time is answered from its last live read of the past 15 minutes when there is one (asOf says when), and otherwise comes back with pending: true, partial: true and no figures, and the total is marked partial. Its scan keeps running, so asking again in a minute usually returns it — do not report a pending wallet as empty. The Sentio portfolio API answers within about 25 s: when it stops a scan before reading everything, or a chain or protocol read fails (for example the wallet token-balance provider), the result (and each affected entry) carries partial: true and missing lists the chains and protocols not read. Its values are then incomplete and can be too low or too high (an unread position is left out; a debt left unpriced overstates a net value) — say so, and retry later or ask for fewer chains rather than reporting them as complete.
| Name | Required | Description | Default |
|---|---|---|---|
| address | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the sample-vs-live read model, the ~40 s aggregate and ~25 s API budgets, the meaning of source/asOf, and the semantics of error, pending, partial, and missing. It even warns that partial values can be too low or too high and why (unpriced debt overstates net value). That is exactly the operational context an agent needs to interpret results correctly.
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 clause, but everything after arrives as one dense paragraph mixing scope, read model, timeouts, and partial-failure semantics. Every sentence is substantive, yet the pending/partial explanation is restated at multiple points and would be far easier to act on if split by mode (single vs aggregate).
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 tool with an output schema and rich annotations, the description supplies everything the schema cannot: which chains map to which address form, how samples differ from live scans, what partial/pending mean, and how the agent should report incomplete results. Nothing material for a correct invocation or interpretation 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?
The single address parameter has 0% schema description coverage, so the description carries the burden and does so: it specifies that an EVM 0x address yields EVM-chain results while a 64-hex Sui address yields Sui results. It also clarifies the parameter is optional by describing the no-argument aggregate behavior. It does not state format validation or what happens if a malformed address is passed.
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 clause names a specific verb and resource (cross-chain DeFi positions) and enumerates the position types covered — lending, staking, LPs, rewards — which lets an agent separate it from get_wallet_balances or get_portfolio_value. It also scopes the chains covered (EVM for 0x, Sui for 64-hex). It stops short of naming a sibling tool to use instead (e.g. get_defi_position_history for past state), so it is clear but not fully differentiated.
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 routing between the two modes: 'Pass address for one wallet, or pass no arguments to get the positions of every wallet you track'. It also gives concrete failure-handling guidance ('do not report a pending wallet as empty', 'retry later or ask for fewer chains'). No explicit exclusions or named alternative tools, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total USD value across every wallet address you track: wallet token balances plus DeFi positions (lending, staking, LPs, rewards — net of debt), with the split as walletValue + defiValue = totalValue, overall and per address and chain. Receipt and LP tokens a DeFi position already counts are not also counted as wallet balances. Rows cover the chains each address holds something on. A row whose walletValue is null is a chain where the address holds DeFi positions but whose wallet balances the connector does not read. A row with an error could not be read at all. Across every tracked wallet, each wallet is read from its latest stored portfolio sample (the Sentio API samples tracked wallets hourly): such an entry says source: "sample" and gives its time as asOf. A wallet without a recent sample, and any Sui wallet (its stored history covers fewer protocols), is scanned live (source: "live"). For one wallet's current state, ask for it by address. An aggregate answers within about 40 s: a wallet it could not re-read in time is answered from its last live read of the past 15 minutes when there is one (asOf says when), and otherwise comes back with pending: true, partial: true and no figures, and the total is marked partial. Its scan keeps running, so asking again in a minute usually returns it — do not report a pending wallet as empty. The Sentio portfolio API answers within about 25 s: when it stops a scan before reading everything, or a chain or protocol read fails (for example the wallet token-balance provider), the result (and each affected entry) carries partial: true and missing lists the chains and protocols not read. Its values are then incomplete and can be too low or too high (an unread position is left out; a debt left unpriced overstates a net value) — say so, and retry later or ask for fewer chains rather than reporting them as complete.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| partial | No | |
| addresses | Yes | |
| defiValue | Yes | |
| totalValue | Yes | |
| walletValue | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare read-only, open-world, idempotent, non-destructive behavior. The description goes far beyond that, disclosing hourly Sentio sampling, live-scan fallback, ~40s aggregate and ~25s API timing, partial/pending semantics, asOf/source fields, and how missing or errored entries should be interpreted.
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 description is front-loaded and every sentence conveys a behavioral trait, but it is a single dense paragraph that runs long for a zero-parameter tool with an output schema. It could be shortened or split into sections without losing meaning.
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?
Given the tool's output complexity — aggregate totals, per-address and per-chain rows, partial flags, sampling behavior, and error handling — the description is complete enough for an agent to interpret results and handle pending or partial responses. The output schema exists, so the return-value detail is supplementary rather than mandatory.
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?
With zero input parameters, there is no parameter surface to document, so the baseline is 4. The description appropriately spends no time on parameter syntax, instead directing single-wallet use to a different call.
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?
Opens with a specific verb and resource: 'Total USD value across every wallet address you track', and immediately defines what is included (wallet balances plus DeFi positions, net of debt). It also distinguishes the aggregate scope from a single-wallet query ('For one wallet's current state, ask for it by address'), so an agent can separate it from per-address siblings.
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?
Provides clear context for aggregate portfolio retrieval and explicitly routes single-wallet current-state requests to an address-based query. It does not name sibling tools such as get_wallet_balances or get_defi_positions, and the advice to 'ask for fewer chains' is not actionable because this tool has no chain parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How the USD value of one wallet token changed over the last 24h or 7d, as hourly points each valued at that instant's price (the amount held and price are not reported). A chain's native coin and its wrapped twin (ETH, WETH, ...) are read the slower way instead — one historical portfolio scan per point on a coarser grid, with the amount and price reported. Identify the holding from a get_wallet_balances row: address is the wallet, chain its chain id (a numeric EVM chain id, or sui_mainnet), symbol the token symbol and token the contract address (omit token for an EVM chain's native coin; on Sui token is required — the coin type, SUI's included). range is 24h (13 points · every 2h) or 7d (15 points · every 12h). Ordinary tokens are one stored-history read and fast; native and wrapped coins take tens of seconds. Use it for one holding at a time.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui | |
| range | No | 24h | |
| token | No | ||
| symbol | Yes | ||
| address | Yes |
| Name | Required | Description |
|---|---|---|
| range | Yes | |
| points | Yes | |
| target | Yes | |
| valuation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds substantial behavioral detail beyond annotations: ordinary tokens are a fast stored-history read, native and wrapped coins use a slower coarser portfolio scan, and timing can be tens of seconds.
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 description is dense but well-structured: it starts with the core endpoint result, then explains the native/wrapped exception, parameter identification, range semantics, and performance. Every sentence carries useful information for correctly invoking this relatively complex tool.
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?
Given five parameters, low schema description coverage, and an output schema, the description covers the missing invocation context thoroughly. It explains how to identify the holding, chain/token edge cases, time ranges, performance differences, and even return-value semantics where they differ by token type.
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 only 20%, but the description compensates by explaining address as the wallet, chain as a numeric EVM chain id or sui_mainnet, symbol as token symbol, and token as contract address with special native-coin and Sui rules. It also explains range as 24h with 13 two-hour points or 7d with 15 twelve-hour points.
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 metric and scope: how the USD value of one wallet token changed over 24h or 7d, with hourly points valued at each instant's price. It also distinguishes ordinary tokens from native/wrapped coins and tells the agent this is for one holding at a time, which is enough to separate it from sibling balance and price tools.
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 description gives clear usage context: identify the holding from a get_wallet_balances row, use it for one holding at a time, omit token for an EVM native coin, and require token on Sui. It does not explicitly name when to prefer siblings such as get_token_history_price, so it falls short of full when/when-not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical USD prices for one token at 1–100 requested timestamps, without a wallet or tracked holding. Identify the token by symbol (e.g. ETH, SUI) or address + chain (one of 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui; contract address on EVM, coin type on Sui). Pass timestamps as ISO 8601 date-times with Z or a timezone offset. Returns available price samples with their actual timestamps, which may differ from the requested instants; check those timestamps before using a quote. Missing samples are omitted, and an empty prices array means no historical prices were found, never a zero price.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain id: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui | |
| symbol | No | ||
| address | No | ||
| timestamps | Yes |
| Name | Required | Description |
|---|---|---|
| prices | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, and the description adds genuinely non-obvious behavior: returned sample timestamps may differ from the requested instants, missing samples are silently omitted, and an empty prices array means 'not found' rather than a zero price. That last clause prevents a real misinterpretation an agent would otherwise make.
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?
Front-loaded with the core capability and packed with useful detail in a tight paragraph with no filler sentences. It does re-enumerate all eight chain ids verbatim from the schema, which is the one redundant stretch.
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 read-only, single-token lookup with an output schema present, everything an agent needs is covered: token identification, timestamp format, request limits, timestamp-fidelity caveat, and empty-result semantics. No material gap remains.
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?
With 25% schema coverage, the description must compensate: symbol vs. address+chain is disambiguated, address is clarified as a contract address on EVM versus a coin type on Sui, and the 1–100 timestamp bound is stated. The chain enum list and ISO 8601 requirement are largely repeats of what the schema already encodes, keeping it from a 5.
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 (historical USD prices for one token at 1–100 timestamps) and immediately scopes it away from wallet-bound siblings with 'without a wallet or tracked holding'. An agent can tell this apart from get_token_price and get_token_balance_history without opening 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?
Explains how to identify the token (symbol, or address + chain) and the required timestamp format, and warns to verify the returned timestamps before quoting. It gives clear context but never explicitly names an alternative sibling (e.g. get_token_price for a current quote) or states when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USD spot price for a token, by symbol (e.g. ETH, SUI) or by token address + chain (one of 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui): a contract address on EVM chains, a coin type such as 0x2::sui::SUI on Sui.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain id: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui | |
| symbol | No | ||
| address | No |
| Name | Required | Description |
|---|---|---|
| price | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds that the price is a USD spot quote and specifies the accepted address formats per chain (EVM contract vs Sui coin type), but says nothing about behavior on unknown symbols, missing params, or stale/unavailable pricing.
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?
Front-loaded with the core purpose, and the chain-id enumeration earns its place because it maps to an opaque numeric enum. The single long sentence with nested parentheticals is dense but not padded.
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; given that, the description covers both lookup modes, the currency, and the two address syntaxes across chain families. The only residual gap is the simultaneous symbol+address case, which is minor for a read-only price lookup.
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 coverage is only 33% (symbol and address are undescribed in the schema), and the description compensates well: it gives symbol examples (ETH, SUI) and explains that address means an EVM contract address or a Sui coin type like 0x2::sui::SUI. It does not clarify the interaction rule when both symbol and address are passed.
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+resource+scope: 'USD spot price for a token'. The word 'spot' implicitly separates it from the historical sibling get_token_history_price, but neither that tool nor any other sibling is named, so the differentiation is left for the agent to infer.
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 implied by the two lookup modes (symbol, or address+chain), but there is no explicit 'use this when', no exclusion of get_token_history_price, and no statement about what to do if neither symbol nor address is supplied despite zero required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Native coin + token balances valued in USD, read from the Sentio portfolio API. address is a 0x EVM address, or a 64-hex Sui address for sui_mainnet. chain is one chain id or a list of them (each one of 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui; one wallet is either EVM or Sui, so a list stays within one of those). Pass address + one chain for that wallet on that chain; address + a list of chains for the same wallet on each of them in one call; address alone for every chain of the address's kind (Ethereum, Optimism, BNB Chain, Monad, Base, Arbitrum, Avalanche for an EVM address; Sui for a Sui address); or no arguments for every wallet address you track, listing the chains each one holds tokens on. Token addresses are contract addresses on EVM chains and coin types (0x…::sui::SUI) on Sui. Across every tracked wallet, each wallet is read from its latest stored portfolio sample (the Sentio API samples tracked wallets hourly): such an entry says source: "sample" and gives its time as asOf. A wallet without a recent sample, and any Sui wallet (its stored history covers fewer protocols), is scanned live (source: "live"). For one wallet's current state, ask for it by address. An aggregate answers within about 40 s: a wallet it could not re-read in time is answered from its last live read of the past 15 minutes when there is one (asOf says when), and otherwise comes back with pending: true, partial: true and no figures, and the total is marked partial. Its scan keeps running, so asking again in a minute usually returns it — do not report a pending wallet as empty. The Sentio portfolio API answers within about 25 s: when it stops a scan before reading everything, or a chain or protocol read fails (for example the wallet token-balance provider), the result (and each affected entry) carries partial: true and missing lists the chains and protocols not read. Its values are then incomplete and can be too low or too high (an unread position is left out; a debt left unpriced overstates a net value) — say so, and retry later or ask for fewer chains rather than reporting them as complete.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | One or more chain ids, all EVM or all Sui: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui | |
| address | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description wisely spends its budget on non-obvious behavior: stored hourly samples (source: "sample", asOf) vs live scans, ~40 s aggregate budget, ~25 s Sentio timeout, and what `pending: true`, `partial: true` and `missing` mean. It even warns that a pending wallet is not empty and that partial values may be too high or too low.
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?
Purpose is front-loaded and every sentence carries operational information, so the length is largely justified for four distinct call modes plus partial-result handling. However, the call-mode and partial-result discussion runs together in dense prose, making it harder to scan than a short enumerated list would be.
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 and only two optional parameters, the description covers everything an agent needs to call it correctly and interpret degraded responses. Failure modes, latency, and caching are all accounted for.
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 coverage is only 50% and `address` has no schema description at all, but the description fully compensates: '0x EVM address, or a 64-hex Sui address for sui_mainnet'. It also defines the cross-field constraint that an address and its chain list must be the same family (all EVM or all Sui), which appears nowhere in the 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?
Opens with a specific verb+resource: 'Native coin + token balances valued in USD, read from the Sentio portfolio API.' That scope is concrete enough for an agent to know it returns balance figures, not history or DeFi positions. It never explicitly names the sibling it should be preferred over (get_portfolio_value, get_token_balance_history), so separation is inferred rather than stated.
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?
Gives explicit invocation recipes — 'Pass address + one chain', 'address alone for every chain', 'no arguments for every wallet address you track' — and directional advice such as 'For one wallet's current state, ask for it by address' and 'retry later or ask for fewer chains'. It stops short of routing the agent to a sibling tool for any scenario, which keeps it out of 5 territory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The wallet addresses you track. Each one covers every supported chain of its kind (EVM or Sui), listed in chains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| addresses | Yes |
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 without description help. The description adds genuine semantic context — that chains are per-address and enumerated in a `chains` field — but says nothing about scoping, ordering, or what an empty result means. Decent additive value, not rich.
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 short sentences, front-loaded with the resource and immediately followed by the important chain-grouping nuance. The first sentence is an elliptical fragment ('The wallet addresses you track.') but nothing is wasted.
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 zero inputs, an output schema, and full annotation coverage, very little burden remains on the description, and it covers the one non-obvious behavior (one address covering all EVM or all Sui chains). Only minor gaps remain, such as scoping to the caller's own wallet and empty-list behavior.
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?
Zero parameters, so per the baseline this starts at 4. The description's mention of `chains` refers to returned data (covered by the output schema) rather than inputs, so no parameter meaning is added or needed.
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 the resource precisely — the caller's tracked wallet addresses — and adds that each entry spans every supported chain of its kind (EVM or Sui). The verb is only implied by the name/title rather than stated in the description, but the sibling set (add_wallet_address, remove_wallet_address) makes the read/list role unambiguous.
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?
There is no explicit when-to-use or when-not-to-use guidance, and neither sibling (add_wallet_address / remove_wallet_address) is referenced. Usage is strongly implied by the zero-parameter, read-only nature of the call, but the agent must infer the routing rather than being told it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop tracking a wallet address for this account, on every chain it covers, so balances, portfolio value and DeFi positions no longer include it. Accepts a 0x EVM address, a .eth ENS name (resolved before matching) or a Sui address. Returns the removed entry; fails with "not tracked" when the address is not tracked. Only affects this account's own tracked-address list.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
| Name | Required | Description |
|---|---|---|
| address | Yes | |
| ensName | No | |
| removed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=true; the description adds real value on top by naming what is destroyed (balances, portfolio value, DeFi positions), the all-chains blast radius, the error behavior, and the account-level blast radius ("Only affects this account's own tracked-address list"). Minor gap: with idempotentHint=true an agent might expect a no-op repeat, but the description says a repeat call errors — that nuance could be spelled out rather than omitted.
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?
Three sentences, each load-bearing and front-loaded with the action; scope, inputs, return and failure are packed in without filler.
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?
A destructive single-param mutation with an output schema: the description covers the side effects, input formats, error case and account scoping. An agent has everything needed to invoke it correctly and warn the user about consequences.
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 coverage is 0% (only type and maxLength=255), so the description must carry the load — and it does, enumerating three accepted forms: 0x EVM, .eth ENS (resolved before matching), and Sui addresses. It omits checksum/case-sensitivity or malformed-address behavior, so not fully exhaustive.
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?
Specific verb+resource ("Stop tracking a wallet address") with explicit scope ("on every chain it covers") and the downstream effect on balances, portfolio value and DeFi positions. Clearly the inverse of add_wallet_address and distinct from list_wallet_addresses.
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 context is clear: remove an address the user no longer wants tracked, with the failure condition ("not tracked") spelled out. It does not explicitly name add_wallet_address as the counterpart action, so a small inference remains, but no wrong-tool ambiguity is created.
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.
add_wallet_address9 fields changedInput schema / properties / chainRemoved value: -{
- "description": "Chain id: 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui",
- "oneOf": [
- {
- "enum": [
- "1"
- ],
- "title": "Ethereum",
- "type": "string"
- },
- {
- "enum": [
- "56"
- ],
- "title": "BNB Chain",
- "type": "string"
- },
- {
- "enum": [
- "8453"
- ],
- "title": "Base",
- "type": "string"
- },
- {
- "enum": [
- "42161"
- ],
- "title": "Arbitrum",
- "type": "string"
- },
- {
- "enum": [
- "sui_mainnet"
- ],
- "title": "Sui",
- "type": "string"
- }
- ],
- "type": "string"
-}Output schema / properties / addedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / alreadyTrackedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / chainsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "chainName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "chain",
+ "chainName"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / createdAtAdded value: +{
+ "type": "number"
+}Output schema / properties / familyAdded value: +{
+ "enum": [
+ "evm",
+ "sui"
+ ],
+ "type": "string"
+}Output schema / properties / idAdded value: +{
+ "type": "string"
+}Output schema / properties / trackedRemoved value: -{
- "items": {
- "additionalProperties": false,
- "properties": {
- "added": {
- "type": "boolean"
- },
- "address": {
- "type": "string"
- },
- "alreadyTracked": {
- "type": "boolean"
- },
- "chain": {
- "type": "string"
- },
- "chainName": {
- "type": "string"
- },
- "createdAt": {
- "type": "number"
- },
- "id": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "chain",
- "address",
- "createdAt",
- "added",
- "alreadyTracked",
- "chainName"
- ],
- "type": "object"
- },
- "type": "array"
-}Output schema / requiredPrevious value: -[
- "tracked",
- "address"
-]New value: +[
+ "id",
+ "family",
+ "address",
+ "chains",
+ "createdAt",
+ "added",
+ "alreadyTracked"
+]get_defi_position_history1 field changedInput schema / properties / chain / descriptionPrevious value: -"Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui"New value: +"Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui"get_token_balance_history1 field changedInput schema / properties / chain / descriptionPrevious value: -"Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui"New value: +"Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui"get_token_history_priceget_token_price2 fields changedInput schema / properties / chain / descriptionPrevious value: -"Chain id: 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui"New value: +"Chain id: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui"Input schema / properties / chain / oneOfPrevious value: -[
- {
- "enum": [
- "1"
- ],
- "title": "Ethereum",
- "type": "string"
- },
- {
- "enum": [
- "56"
- ],
- "title": "BNB Chain",
- "type": "string"
- },
- {
- "enum": [
- "8453"
- ],
- "title": "Base",
- "type": "string"
- },
- {
- "enum": [
- "42161"
- ],
- "title": "Arbitrum",
- "type": "string"
- },
- {
- "enum": [
- "sui_mainnet"
- ],
- "title": "Sui",
- "type": "string"
- }
-]New value: +[
+ {
+ "enum": [
+ "1"
+ ],
+ "title": "Ethereum",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "10"
+ ],
+ "title": "Optimism",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "56"
+ ],
+ "title": "BNB Chain",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "143"
+ ],
+ "title": "Monad",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "8453"
+ ],
+ "title": "Base",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "42161"
+ ],
+ "title": "Arbitrum",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "43114"
+ ],
+ "title": "Avalanche",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "sui_mainnet"
+ ],
+ "title": "Sui",
+ "type": "string"
+ }
+]get_wallet_balances2 fields changedInput schema / properties / chain / anyOfPrevious value: -[
- {
- "description": "Chain id: 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui",
- "oneOf": [
- {
- "enum": [
- "1"
- ],
- "title": "Ethereum",
- "type": "string"
- },
- {
- "enum": [
- "56"
- ],
- "title": "BNB Chain",
- "type": "string"
- },
- {
- "enum": [
- "8453"
- ],
- "title": "Base",
- "type": "string"
- },
- {
- "enum": [
- "42161"
- ],
- "title": "Arbitrum",
- "type": "string"
- },
- {
- "enum": [
- "sui_mainnet"
- ],
- "title": "Sui",
- "type": "string"
- }
- ],
- "title": "One chain",
- "type": "string"
- },
- {
- "items": {
- "description": "Chain id: 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui",
- "oneOf": [
- {
- "enum": [
- "1"
- ],
- "title": "Ethereum",
- "type": "string"
- },
- {
- "enum": [
- "56"
- ],
- "title": "BNB Chain",
- "type": "string"
- },
- {
- "enum": [
- "8453"
- ],
- "title": "Base",
- "type": "string"
- },
- {
- "enum": [
- "42161"
- ],
- "title": "Arbitrum",
- "type": "string"
- },
- {
- "enum": [
- "sui_mainnet"
- ],
- "title": "Sui",
- "type": "string"
- }
- ],
- "type": "string"
- },
- "maxItems": 5,
- "minItems": 1,
- "title": "Several chains",
- "type": "array"
- }
-]New value: +[
+ {
+ "description": "Chain id: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui",
+ "oneOf": [
+ {
+ "enum": [
+ "1"
+ ],
+ "title": "Ethereum",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "10"
+ ],
+ "title": "Optimism",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "56"
+ ],
+ "title": "BNB Chain",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "143"
+ ],
+ "title": "Monad",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "8453"
+ ],
+ "title": "Base",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "42161"
+ ],
+ "title": "Arbitrum",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "43114"
+ ],
+ "title": "Avalanche",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "sui_mainnet"
+ ],
+ "title": "Sui",
+ "type": "string"
+ }
+ ],
+ "title": "One chain",
+ "type": "string"
+ },
+ {
+ "items": {
+ "description": "Chain id: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui",
+ "oneOf": [
+ {
+ "enum": [
+ "1"
+ ],
+ "title": "Ethereum",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "10"
+ ],
+ "title": "Optimism",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "56"
+ ],
+ "title": "BNB Chain",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "143"
+ ],
+ "title": "Monad",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "8453"
+ ],
+ "title": "Base",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "42161"
+ ],
+ "title": "Arbitrum",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "43114"
+ ],
+ "title": "Avalanche",
+ "type": "string"
+ },
+ {
+ "enum": [
+ "sui_mainnet"
+ ],
+ "title": "Sui",
+ "type": "string"
+ }
+ ],
+ "type": "string"
+ },
+ "maxItems": 8,
+ "minItems": 1,
+ "title": "Several chains",
+ "type": "array"
+ }
+]Input schema / properties / chain / descriptionPrevious value: -"One or more chain ids, all EVM or all Sui: 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui"New value: +"One or more chain ids, all EVM or all Sui: 1 Ethereum, 10 Optimism, 56 BNB Chain, 143 Monad, 8453 Base, 42161 Arbitrum, 43114 Avalanche, sui_mainnet Sui"list_wallet_addresses4 fields changedOutput schema / properties / addresses / items / properties / chainRemoved value: -{
- "type": "string"
-}Output schema / properties / addresses / items / properties / chainsAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "chainName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "chain",
+ "chainName"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / addresses / items / properties / familyAdded value: +{
+ "enum": [
+ "evm",
+ "sui"
+ ],
+ "type": "string"
+}Output schema / properties / addresses / items / requiredPrevious value: -[
- "id",
- "chain",
- "address",
- "createdAt"
-]New value: +[
+ "id",
+ "family",
+ "address",
+ "chains",
+ "createdAt"
+]remove_wallet_address6 fields changedInput schema / properties / chainRemoved value: -{
- "description": "Chain id: a numeric EVM chain id, or sui_mainnet; tracked chains are 1 Ethereum, 56 BNB Chain, 8453 Base, 42161 Arbitrum, sui_mainnet Sui",
- "type": "string"
-}Output schema / properties / removed / additionalPropertiesAdded value: +falseOutput schema / properties / removed / itemsRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "chain": {
- "type": "string"
- },
- "chainName": {
- "type": "string"
- },
- "createdAt": {
- "type": "number"
- },
- "id": {
- "type": "string"
- }
- },
- "required": [
- "id",
- "chain",
- "address",
- "createdAt",
- "chainName"
- ],
- "type": "object"
-}Output schema / properties / removed / propertiesAdded value: +{
+ "address": {
+ "type": "string"
+ },
+ "chains": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "chainName": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "chain",
+ "chainName"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "createdAt": {
+ "type": "number"
+ },
+ "family": {
+ "enum": [
+ "evm",
+ "sui"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ }
+}Output schema / properties / removed / requiredAdded value: +[
+ "id",
+ "family",
+ "address",
+ "chains",
+ "createdAt"
+]Output schema / properties / removed / typePrevious value: -"array"New value: +"object"get_defi_positions1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "asOf": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "positions": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "chain": {
- "type": "string"
- },
- "components": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amountRaw": {
- "type": "string"
- },
- "decimals": {
- "type": "number"
- },
- "kind": {
- "enum": [
- "asset",
- "debt",
- "reward"
- ],
- "type": "string"
- },
- "priceUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "symbol": {
- "type": "string"
- },
- "valueUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "kind",
- "symbol",
- "address",
- "decimals",
- "amountRaw",
- "priceUsd",
- "valueUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "displayLabel": {
- "type": "string"
- },
- "id": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "label": {
- "type": "string"
- },
- "marketId": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "valueUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chain",
- "id",
- "marketId",
- "label",
- "displayLabel",
- "valueUsd",
- "components"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "protocols": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "assetUsd": {
- "type": "number"
- },
- "chains": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "debtUsd": {
- "type": "number"
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "rewardUsd": {
- "type": "number"
- },
- "totalUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chains",
- "totalUsd",
- "assetUsd",
- "debtUsd",
- "rewardUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValueUsd": {
- "type": "number"
- }
- },
- "required": [
- "address",
- "totalValueUsd",
- "asOf",
- "protocols",
- "positions"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "addresses": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "asOf": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "positions": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "chain": {
- "type": "string"
- },
- "components": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amountRaw": {
- "type": "string"
- },
- "decimals": {
- "type": "number"
- },
- "kind": {
- "enum": [
- "asset",
- "debt",
- "reward"
- ],
- "type": "string"
- },
- "priceUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "symbol": {
- "type": "string"
- },
- "valueUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "kind",
- "symbol",
- "address",
- "decimals",
- "amountRaw",
- "priceUsd",
- "valueUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "displayLabel": {
- "type": "string"
- },
- "id": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "label": {
- "type": "string"
- },
- "marketId": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "valueUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chain",
- "id",
- "marketId",
- "label",
- "displayLabel",
- "valueUsd",
- "components"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "protocols": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "assetUsd": {
- "type": "number"
- },
- "chains": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "debtUsd": {
- "type": "number"
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "rewardUsd": {
- "type": "number"
- },
- "totalUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chains",
- "totalUsd",
- "assetUsd",
- "debtUsd",
- "rewardUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValueUsd": {
- "type": "number"
- }
- },
- "required": [
- "address",
- "totalValueUsd",
- "asOf",
- "protocols",
- "positions"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValueUsd": {
- "type": "number"
- }
- },
- "required": [
- "totalValueUsd",
- "addresses"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "asOf": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "error": {
+ "type": "string"
+ },
+ "missing": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "chain",
+ "protocolId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "const": true,
+ "type": "boolean"
+ },
+ "pending": {
+ "const": true,
+ "type": "boolean"
+ },
+ "positions": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "components": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amountRaw": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "kind": {
+ "enum": [
+ "asset",
+ "debt",
+ "reward"
+ ],
+ "type": "string"
+ },
+ "priceUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "kind",
+ "symbol",
+ "address",
+ "decimals",
+ "amountRaw",
+ "priceUsd",
+ "valueUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "displayLabel": {
+ "type": "string"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "marketId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chain",
+ "id",
+ "marketId",
+ "label",
+ "displayLabel",
+ "valueUsd",
+ "components"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "protocols": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "assetUsd": {
+ "type": "number"
+ },
+ "chains": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "debtUsd": {
+ "type": "number"
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "rewardUsd": {
+ "type": "number"
+ },
+ "totalUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chains",
+ "totalUsd",
+ "assetUsd",
+ "debtUsd",
+ "rewardUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "enum": [
+ "sample",
+ "live"
+ ],
+ "type": "string"
+ },
+ "totalValueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "address",
+ "totalValueUsd",
+ "asOf",
+ "protocols",
+ "positions"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "addresses": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "asOf": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "error": {
+ "type": "string"
+ },
+ "missing": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "chain",
+ "protocolId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "const": true,
+ "type": "boolean"
+ },
+ "pending": {
+ "const": true,
+ "type": "boolean"
+ },
+ "positions": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "components": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amountRaw": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "kind": {
+ "enum": [
+ "asset",
+ "debt",
+ "reward"
+ ],
+ "type": "string"
+ },
+ "priceUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "kind",
+ "symbol",
+ "address",
+ "decimals",
+ "amountRaw",
+ "priceUsd",
+ "valueUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "displayLabel": {
+ "type": "string"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "marketId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chain",
+ "id",
+ "marketId",
+ "label",
+ "displayLabel",
+ "valueUsd",
+ "components"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "protocols": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "assetUsd": {
+ "type": "number"
+ },
+ "chains": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "debtUsd": {
+ "type": "number"
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "rewardUsd": {
+ "type": "number"
+ },
+ "totalUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chains",
+ "totalUsd",
+ "assetUsd",
+ "debtUsd",
+ "rewardUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "source": {
+ "enum": [
+ "sample",
+ "live"
+ ],
+ "type": "string"
+ },
+ "totalValueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "address",
+ "totalValueUsd",
+ "asOf",
+ "protocols",
+ "positions"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "const": true,
+ "type": "boolean"
+ },
+ "totalValueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalValueUsd",
+ "addresses"
+ ],
+ "type": "object"
+ }
+]get_portfolio_value6 fields changedOutput schema / properties / addresses / items / properties / asOfAdded value: +{
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / addresses / items / properties / missingAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "chain",
+ "protocolId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / properties / addresses / items / properties / partialAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / addresses / items / properties / pendingAdded value: +{
+ "const": true,
+ "type": "boolean"
+}Output schema / properties / addresses / items / properties / sourceAdded value: +{
+ "enum": [
+ "sample",
+ "live"
+ ],
+ "type": "string"
+}Output schema / properties / partialAdded value: +{
+ "const": true,
+ "type": "boolean"
+}get_wallet_balances1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "chain": {
- "type": "string"
- },
- "chainName": {
- "type": "string"
- },
- "tokens": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amount": {
- "type": "string"
- },
- "decimals": {
- "type": "number"
- },
- "price": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "symbol": {
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "symbol",
- "address",
- "decimals",
- "amount",
- "price",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValue": {
- "type": "number"
- }
- },
- "required": [
- "chain",
- "chainName",
- "address",
- "totalValue",
- "tokens"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "addresses": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "chain": {
- "type": "string"
- },
- "chainName": {
- "type": "string"
- },
- "error": {
- "type": "string"
- },
- "tokens": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amount": {
- "type": "string"
- },
- "decimals": {
- "type": "number"
- },
- "price": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "symbol": {
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "symbol",
- "address",
- "decimals",
- "amount",
- "price",
- "value"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValue": {
- "type": "number"
- }
- },
- "required": [
- "chain",
- "chainName",
- "address",
- "totalValue",
- "tokens"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValue": {
- "type": "number"
- }
- },
- "required": [
- "totalValue",
- "addresses"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "chainName": {
+ "type": "string"
+ },
+ "missing": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "chain",
+ "protocolId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "const": true,
+ "type": "boolean"
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amount": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "price": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "symbol",
+ "address",
+ "decimals",
+ "amount",
+ "price",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalValue": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "chain",
+ "chainName",
+ "address",
+ "totalValue",
+ "tokens"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "addresses": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "asOf": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "chain": {
+ "type": "string"
+ },
+ "chainName": {
+ "type": "string"
+ },
+ "error": {
+ "type": "string"
+ },
+ "missing": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "chain",
+ "protocolId"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "const": true,
+ "type": "boolean"
+ },
+ "pending": {
+ "const": true,
+ "type": "boolean"
+ },
+ "source": {
+ "enum": [
+ "sample",
+ "live"
+ ],
+ "type": "string"
+ },
+ "tokens": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amount": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "price": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "symbol",
+ "address",
+ "decimals",
+ "amount",
+ "price",
+ "value"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalValue": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "chain",
+ "chainName",
+ "address",
+ "totalValue",
+ "tokens"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "partial": {
+ "const": true,
+ "type": "boolean"
+ },
+ "totalValue": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalValue",
+ "addresses"
+ ],
+ "type": "object"
+ }
+]add_wallet_address9 fields changedInput schema / properties / chain / defaultRemoved value: -"1"Output schema / properties / addedRemoved value: -{
- "type": "boolean"
-}Output schema / properties / alreadyTrackedRemoved value: -{
- "type": "boolean"
-}Output schema / properties / chainRemoved value: -{
- "type": "string"
-}Output schema / properties / chainNameRemoved value: -{
- "type": "string"
-}Output schema / properties / createdAtRemoved value: -{
- "type": "number"
-}Output schema / properties / idRemoved value: -{
- "type": "string"
-}Output schema / properties / trackedAdded value: +{
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "added": {
+ "type": "boolean"
+ },
+ "address": {
+ "type": "string"
+ },
+ "alreadyTracked": {
+ "type": "boolean"
+ },
+ "chain": {
+ "type": "string"
+ },
+ "chainName": {
+ "type": "string"
+ },
+ "createdAt": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "chain",
+ "address",
+ "createdAt",
+ "added",
+ "alreadyTracked",
+ "chainName"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+}Output schema / requiredPrevious value: -[
- "id",
- "chain",
- "address",
- "createdAt",
- "added",
- "alreadyTracked",
- "chainName"
-]New value: +[
+ "tracked",
+ "address"
+]get_portfolio_value6 fields changedOutput schema / properties / addresses / items / properties / defiValueAdded value: +{
+ "type": "number"
+}Output schema / properties / addresses / items / properties / walletValueAdded value: +{
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / addresses / items / requiredPrevious value: -[
- "chain",
- "chainName",
- "address",
- "totalValue",
- "tokens"
-]New value: +[
+ "chain",
+ "chainName",
+ "address",
+ "totalValue",
+ "tokens",
+ "walletValue",
+ "defiValue"
+]Output schema / properties / defiValueAdded value: +{
+ "type": "number"
+}Output schema / properties / walletValueAdded value: +{
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "totalValue",
- "addresses"
-]New value: +[
+ "totalValue",
+ "walletValue",
+ "defiValue",
+ "addresses"
+]get_defi_position_history2 fields changedInput schema / properties / groupAdded value: +{
+ "maxLength": 300,
+ "minLength": 1,
+ "type": "string"
+}Output schema / properties / target / properties / groupIdAdded value: +{
+ "type": "string"
+}get_defi_positions1 field changedOutput schema / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "asOf": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "positions": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "chain": {
- "type": "string"
- },
- "components": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amountRaw": {
- "type": "string"
- },
- "decimals": {
- "type": "number"
- },
- "kind": {
- "enum": [
- "asset",
- "debt",
- "reward"
- ],
- "type": "string"
- },
- "priceUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "symbol": {
- "type": "string"
- },
- "valueUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "kind",
- "symbol",
- "address",
- "decimals",
- "amountRaw",
- "priceUsd",
- "valueUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "label": {
- "type": "string"
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "valueUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chain",
- "label",
- "valueUsd",
- "components"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "protocols": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "assetUsd": {
- "type": "number"
- },
- "chains": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "debtUsd": {
- "type": "number"
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "rewardUsd": {
- "type": "number"
- },
- "totalUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chains",
- "totalUsd",
- "assetUsd",
- "debtUsd",
- "rewardUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValueUsd": {
- "type": "number"
- }
- },
- "required": [
- "address",
- "totalValueUsd",
- "asOf",
- "protocols",
- "positions"
- ],
- "type": "object"
- },
- {
- "additionalProperties": false,
- "properties": {
- "addresses": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "type": "string"
- },
- "asOf": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "positions": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "chain": {
- "type": "string"
- },
- "components": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "address": {
- "anyOf": [
- {
- "type": "string"
- },
- {
- "type": "null"
- }
- ]
- },
- "amountRaw": {
- "type": "string"
- },
- "decimals": {
- "type": "number"
- },
- "kind": {
- "enum": [
- "asset",
- "debt",
- "reward"
- ],
- "type": "string"
- },
- "priceUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- },
- "symbol": {
- "type": "string"
- },
- "valueUsd": {
- "anyOf": [
- {
- "type": "number"
- },
- {
- "type": "null"
- }
- ]
- }
- },
- "required": [
- "kind",
- "symbol",
- "address",
- "decimals",
- "amountRaw",
- "priceUsd",
- "valueUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "label": {
- "type": "string"
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "valueUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chain",
- "label",
- "valueUsd",
- "components"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "protocols": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "assetUsd": {
- "type": "number"
- },
- "chains": {
- "items": {
- "type": "string"
- },
- "type": "array"
- },
- "debtUsd": {
- "type": "number"
- },
- "protocolId": {
- "type": "string"
- },
- "protocolName": {
- "type": "string"
- },
- "rewardUsd": {
- "type": "number"
- },
- "totalUsd": {
- "type": "number"
- }
- },
- "required": [
- "protocolId",
- "protocolName",
- "chains",
- "totalUsd",
- "assetUsd",
- "debtUsd",
- "rewardUsd"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValueUsd": {
- "type": "number"
- }
- },
- "required": [
- "address",
- "totalValueUsd",
- "asOf",
- "protocols",
- "positions"
- ],
- "type": "object"
- },
- "type": "array"
- },
- "totalValueUsd": {
- "type": "number"
- }
- },
- "required": [
- "totalValueUsd",
- "addresses"
- ],
- "type": "object"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "asOf": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "positions": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "components": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amountRaw": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "kind": {
+ "enum": [
+ "asset",
+ "debt",
+ "reward"
+ ],
+ "type": "string"
+ },
+ "priceUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "kind",
+ "symbol",
+ "address",
+ "decimals",
+ "amountRaw",
+ "priceUsd",
+ "valueUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "displayLabel": {
+ "type": "string"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "marketId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chain",
+ "id",
+ "marketId",
+ "label",
+ "displayLabel",
+ "valueUsd",
+ "components"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "protocols": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "assetUsd": {
+ "type": "number"
+ },
+ "chains": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "debtUsd": {
+ "type": "number"
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "rewardUsd": {
+ "type": "number"
+ },
+ "totalUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chains",
+ "totalUsd",
+ "assetUsd",
+ "debtUsd",
+ "rewardUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalValueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "address",
+ "totalValueUsd",
+ "asOf",
+ "protocols",
+ "positions"
+ ],
+ "type": "object"
+ },
+ {
+ "additionalProperties": false,
+ "properties": {
+ "addresses": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "type": "string"
+ },
+ "asOf": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "positions": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "chain": {
+ "type": "string"
+ },
+ "components": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "address": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "amountRaw": {
+ "type": "string"
+ },
+ "decimals": {
+ "type": "number"
+ },
+ "kind": {
+ "enum": [
+ "asset",
+ "debt",
+ "reward"
+ ],
+ "type": "string"
+ },
+ "priceUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "symbol": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "kind",
+ "symbol",
+ "address",
+ "decimals",
+ "amountRaw",
+ "priceUsd",
+ "valueUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "displayLabel": {
+ "type": "string"
+ },
+ "id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "label": {
+ "type": "string"
+ },
+ "marketId": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "valueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chain",
+ "id",
+ "marketId",
+ "label",
+ "displayLabel",
+ "valueUsd",
+ "components"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "protocols": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "assetUsd": {
+ "type": "number"
+ },
+ "chains": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "debtUsd": {
+ "type": "number"
+ },
+ "protocolId": {
+ "type": "string"
+ },
+ "protocolName": {
+ "type": "string"
+ },
+ "rewardUsd": {
+ "type": "number"
+ },
+ "totalUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "protocolId",
+ "protocolName",
+ "chains",
+ "totalUsd",
+ "assetUsd",
+ "debtUsd",
+ "rewardUsd"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalValueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "address",
+ "totalValueUsd",
+ "asOf",
+ "protocols",
+ "positions"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totalValueUsd": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "totalValueUsd",
+ "addresses"
+ ],
+ "type": "object"
+ }
+]add_wallet_addressget_defi_position_historyget_defi_positionsget_portfolio_valueget_token_balance_historyget_token_priceget_wallet_balanceslist_wallet_addressesremove_wallet_addressRead-only access to your own crypto portfolio across 11+ exchanges and 20+ chains: holdings, full history, FIFO cost basis and P&L, fees and income. Ask Claude or ChatGPT about your portfolio; the connector can never trade, move funds or act as a login.
Analyse crypto wallets (EVM, Solana, Bitcoin) and compare DeFi lending, borrowing and pool rates.
Multi-chain wallet intelligence: balances, transactions, ENS, OFAC screening across 7 chains.
Historical crypto wallet holdings, valuations and CSV exports. OAuth; paid own-wallet scans.
Add one secure layer between your agents and this server.
