Loading ToolBench
Model Context Protocol server providing access to Tatum's comprehensive blockchain API across 130+ networks with 13 tools
The server defines 13 tools with reasonable naming conventions (all start with action verbs like get_, check_, gateway_). However, there are significant gaps in schema completeness, parameter descriptions, and output documentation. Many tools accept string parameters that should be enums (e.g., chain, transactionTypes, tokenTypes). Parameter descriptions exist but are often generic. Most critically, output schemas are not documented anywhere in the provided source code, LLMs cannot predict what fields these tools return. Error handling is minimal. The server relies on STDIO transport, which caps protocol readiness severely. Overall, this is a fair-quality server with clear intent but incomplete production-grade polish.
Check if a blockchain address is flagged as malicious.
Check if a wallet owns a specific token or NFT.
Execute blockchain RPC calls through Tatum's gateway infrastructure. Supports both JSON-RPC and REST API calls depending on the blockchain. For JSON-RPC methods, use simple method names like 'getblockcount' or 'eth_getBalance'. For REST calls, use full HTTP method and path like 'POST /getnowblock'. Parameters should be provided as an array for JSON-RPC or object for REST calls.
Get a list of all supported blockchain networks available through Tatum's RPC gateways
Get supported RPC methods for a specific blockchain chain
Get block number closest to a given time or timestamp.
No output schemas documented. Tools return data from Tatum APIs, but the source code provides zero documentation of what fields LLMs should expect. This forces LLMs to hallucinate response structure and makes tool composition fragile.
String parameters that should be enums. 'chain' is passed as a free-form string in 10+ tools (e.g., 'ethereum-mainnet', 'bitcoin-mainnet') with only example values in descriptions. This invites hallucinated chain names. 'transactionTypes', 'tokenTypes', 'transactionSubtype', and 'sort' all have known enum values but are defined as strings without enum constraints.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 64 | - | v1 |
Get current exchange rate for a specific cryptocurrency symbol.
Fetch metadata of NFTs or multitokens by token address and IDs.
Get all addresses owning a specific NFT, multitoken, or ERC-20.
Get metadata for any token, including NFTs and multitokens.
Get all transactions for a wallet with optional filters.
Get native wallet balances at specific time or block.
Get detailed portfolio of native, fungible, and NFT tokens for a wallet.
Pagination support present but incomplete. Tools like get_transaction_history, get_wallet_portfolio, get_owners accept pageSize and offset but descriptions don't clarify max allowed pageSize, default behavior, or whether results are guaranteed complete. No mention of cursor-based pagination for Tezos.
Parameter descriptions lack specificity. Examples: 'The blockchain to work with' (repeated in 10+ tools) doesn't explain valid values or format. 'Parameters for the RPC method' is vague, LLMs won't know whether params are positional or keyed. 'The option to select only specific token types' uses 'option' language instead of directive.
No error recovery guidance. Tools have no documented error cases or recovery paths. The verify-tools.mjs script tests happy paths only. An LLM calling gateway_execute_rpc with an invalid method gets no hint about what went wrong or what to try next.
Tool descriptions contain example values. e.g., gateway_get_supported_methods lists 'bitcoin-mainnet', 'ethereum-mainnet', etc. as examples in the description. LLMs may reuse these literally instead of looking them up via gateway_get_supported_chains. Examples belong in enum constraints or discovery tools, not descriptions.
Ambiguous parameter dependencies undocumented. In get_wallet_balance_by_time, either 'blockNumber', 'time', or 'unix' can be passed, but the description doesn't specify which takes precedence or whether they're mutually exclusive. In get_transaction_history, blockFrom and blockTo have implicit range logic ('blockFrom + 1000') not stated in the description.
No indication of result limits or pagination defaults. get_wallet_portfolio, get_owners, get_transaction_history don't document what 'default pageSize' is or maximum items returned. Without these bounds, LLMs may expect 10,000 results in a single call.
No tool annotations. Tools have 'Risk: READ_ONLY' noted in the spec, but the source code shows no readOnlyHint or toolAnnotations in the tool definitions. MCP SDK v0.5.0 supports annotations, they should be present.