| Tool | What it returns |
|---|
| ① Web tools — search, read and act |
web_search | Search the live web and get ranked results with title, URL, snippet and published date. When to use: an agent needs current facts, news or links that are not on chain - 'what is the BTC fee market saying today', 'recent Zcash governance proposals', 'find the docs page for X'. Use it before web_fetch, then fetch the one URL that looks authoritative |
web_fetch | Fetch one public web page and return its readable text as clean markdown or plain text, with navigation, scripts, headers and footers stripped. When to use: you have a specific URL (from web_search or the user) and need what the page actually says - 'read this article', 'summarise this docs page', 'turn this URL into markdown' |
web_screenshot | Capture a screenshot of one public web page as an image (JPEG) plus metadata. When to use: visual layout matters - a dashboard, chart, UI state, or 'what does this page look like' |
web_map | Discover the URLs of one site - sitemap first, then same-host links from the homepage. When to use: you need the list of pages a site exposes before fetching a few of them |
web_fetch_batch | Fetch up to 5 public URLs in one call and return each page's title, engine and a short snippet (first ~1200 characters), so an agent can triage several links quickly. When to use: search returned several candidate pages and you want a first pass over all of them; then call web_fetch on the ones worth reading in full |
web_feed | Read an RSS or Atom feed and return its latest items. When to use: the user wants the latest posts/news from a site that publishes a feed, or you found a feed URL and want headlines plus links |
web_metadata | Extract a page's structured metadata: Open Graph, Twitter cards, canonical URL, language and JSON-LD. When to use: you need the title/description/author/image of a page, or JSON-LD structured data for a product/article, without reading the whole page |
web_crawl | Crawl one site's same-host pages starting from a URL (depth 1-2, at most 20 pages) and return each page's title, URL and readable text. When to use: you need several pages from one site (docs section, news index, product list) and web_map alone is not enough |
web_extract | Extract structured data from one public page: tables (headers + rows), JSON-LD blocks, and Open Graph/Twitter/canonical/language metadata. When to use: the page has tables or schema.org JSON-LD you need as data, without an LLM |
web_act | Drive a real Chromium browser on one public page: click, type, press keys, scroll, wait for selectors, then return the resulting text (and optionally a screenshot and JSON XHR responses). When to use: the page needs interaction before its content appears (cookie banners, tabs, 'load more', form submit) and web_fetch/web_crawl cannot see it |
web_crawl_async | Submit a same-host crawl as an asynchronous job and return a job_id immediately. When to use: you need more than a couple of pages and cannot hold a long HTTP request; submit here, then poll web_crawl_job until status is done, failed or cancelled |
web_crawl_job | Check or cancel an asynchronous crawl job created by web_crawl_async. When to use: after web_crawl_async, poll with action=status until status is done/failed/cancelled; use action=cancel to stop a running job |
web_extract_schema | Extract a page's structured data into a named schema's common fields (no LLM): article, product, event, faq, recipe, course, organization, local_business, breadcrumb, dataset or job_posting. When to use: you need fields (title/author/date, price/currency/availability, event dates, FAQ Q&A, recipe ingredients, org address) rather than raw markdown or tables |
web_diff | Fetch a page now and compare it with the previous snapshot of the same URL, returning whether it changed and a unified diff (no LLM). When to use: monitoring a page for updates - prices, docs, policy pages, SEO titles/meta; first call stores the baseline, later calls return added/removed lines |
web_monitor_set | Create a scheduled change monitor for one public URL: the server re-fetches the page on an interval, stores a new snapshot and records a diff event whenever the readable text changes. When to use: the user wants to be told when a page changes (price, docs, policy page, job post, release notes) and cannot poll it themselves; also for handing off 'watch this for me' |
web_monitor_list | List the scheduled change monitors owned by the calling IP, with latest/next check time, last title or error, and the 5 most recent change events. When to use: after web_monitor_set, poll this instead of re-fetching the page; or to show the user what is currently being watched |
web_monitor_delete | Delete one scheduled change monitor owned by the calling IP (its event history is removed too). When to use: the user no longer needs to watch a page, or the per-IP monitor limit was reached |
| ② Trends & market intelligence |
prediction_market_odds | Live implied probabilities from prediction markets (Polymarket primary, Manifold fallback). When to use: 'what does the market think will happen', event odds, election/crypto/macro probabilities |
crypto_trending | Crypto attention and market context: CoinGecko trending coins, top markets, DeFi TVL and Fear & Greed. When to use: what is trending in crypto, which tokens are moving, risk appetite, TVL leaders |
| ③ Overview & chain status |
list_chains | List every chain on the RobotBase roster with its state. When to use: the user asks which chains are supported, which nodes are online, or where to start |
chain_status | Live run-time state of one chain's node. When to use: is this chain's node synced, healthy or lagging; what is its height, peer count, mempool depth or client version |
robotbase_services | Live availability of every service behind the RobotBase gateway: the chain nodes, Web3 Agent Hub, AITOKENS and MCP itself. When to use: an overall platform health check, or finding which service is down |
robotbase_capabilities | Per-chain capability, retention boundary and fee model. When to use: before promising that some query is possible, or when a tool refused a query as out of range |
| ③ Bitcoin (BTC) — settlement verification & fees |
btc_get_mempool_state | Bitcoin mempool depth, capacity load and a busy/normal verdict. When to use: deciding whether now is a good moment to settle on-chain, or how large the backlog is |
btc_get_fee_rates | Bitcoin fee rates for confirmation targets, plus the mempool floor. When to use: pricing a Bitcoin transaction, or deciding when a sweep will confirm cheaply |
btc_get_transaction | Look up one Bitcoin transaction by txid - the core settlement check. When to use: has this payment arrived, which block is it in, how many confirmations does it have |
btc_get_block | Bitcoin block summary by height or hash; omit both for the chain tip. When to use: an overview of a block, or confirming which block a payment landed in |
btc_get_address | Balance and activity of a Bitcoin address, with no key involved. When to use: reconciling a merchant wallet, or checking whether an address received funds and how active it is |
btc_get_network_stats | Bitcoin network and node state: difficulty, network hashrate, total transactions processed and the current tx/s rate, protocol version, peer connections, relay fee, mempool size, uptime and which indexes (txindex) are synced on our node. When to use: macro questions about Bitcoin - how much hashrate secures it, how fast the chain is moving, or whether our node's indexes are complete |
broadcast_raw_transaction | Relay an already-signed raw transaction to the network through our own full node (non-custodial: we never see a private key). When to use: an agent signed a transaction locally and wants a high-availability broadcast path into the Bitcoin network |
| ④ Ethereum (ETH) — settlement, fees and contract reads |
eth_get_block | One Ethereum block by number, tag (latest/finalized/safe) or hash: timestamp, transaction count, gas used against the limit, base fee, block builder and size. When to use: block-level context - how full is Ethereum right now, when a block was produced, what the base fee was, or which builder produced it |
eth_read_contract | Read-only (eth_call) against any Ethereum contract, executed by our own Reth node. ERC-20 helpers balanceOf / allowance / decimals / symbol / name / totalSupply are built in; any other function can be called by passing its 4-byte `selector` plus ABI-encoded `parameter`. Nothing is signed or written. When to use: an agent needs an on-chain value without trusting a third-party API - a USDT/USDC balance, token decimals, an allowance, or any view function |
eth_get_logs | Ethereum event logs over a block range, optionally filtered by contract address and event signature, with ERC-20 Transfer logs decoded (token, from, to, amount). When to use: find transfers or contract events in a window - 'who moved this token in the last N blocks', or watch a contract's activity without an indexer |
eth_get_transaction | Ethereum transaction check by hash: success or reverted, gas used, fee paid, confirmations, whether the block is finalized, and any ERC-20 transfers decoded from the receipt logs (token, from, to, amount). When to use: did this ETH or ERC-20 payment actually settle, is it irreversible, who paid whom and how much |
eth_get_account | Ethereum account state from our own node: ETH balance, nonce, and whether the address is a contract. When to use: balance and account type before sizing a transfer, or telling an EOA from a contract |
eth_get_fee_rates | Ethereum fee market from our own Reth node: current and next base fee, priority-fee percentiles over the last blocks, and the estimated ETH cost of a plain transfer and of an ERC-20 transfer. When to use: pricing an Ethereum transaction, or deciding what tip gets included quickly |
| ⑤ Tron — settlement, risk and contract reads |
tron_check_address_risk | TRON address risk intelligence: judicial and black-market labels, account profile and a 0-100 safety score. When to use: before accepting USDT from a counterparty - OTC settlement, merchant payout, or any agent that must not receive tainted funds; also to sanity-check an address you are about to pay |
tron_verify_usdt_transfer | TRC-20 USDT settlement check by transaction id: did it land, is it irreversible, how much, from and to whom. When to use: an agent or a merchant must confirm a USDT payment before releasing value - this is the settlement check that closes an automated trade loop |
tron_get_current_block | The current (tip) TRON block: number, id, parent, timestamp, transaction count and a breakdown by contract type, plus the producing witness. When to use: how busy TRON is right now, what is in the block being produced, who produced it |
tron_get_transaction | One Tron transaction by txid: success or reverted, energy used, the call it made, and - this is the important part - any TRC-20 transfers decoded from the receipt logs (token, from, to, amount). When to use: did this USDT payment really land, for how much, from whom, and is it finalized |
tron_get_account | TRON account state read straight off our own node: TRX balance, whether the account is activated, energy and bandwidth (used / limit), whether it is a witness, and account age. When to use: TRX balance and resource state before sizing a transfer, or checking whether an address exists on chain |
tron_read_contract | Read-only (constant) call against any TRON contract, executed by our own node. TRC-20 helpers balanceOf / allowance / decimals / symbol / name / totalSupply are built in; any other function can be called with a raw selector plus ABI-encoded parameter. No state is changed and no key is involved. When to use: an agent needs an on-chain value without trusting a third-party API - USDT balance of an address, token decimals, an allowance, or any view function |
tron_get_block | One Tron block by height or block id, read from our own node: producer, timestamp, transaction count split by contract type, and the tx ids in it. When to use: inspect a specific block, or confirm which block a transaction landed in |
tron_get_node_status | TRON node state from our own java-tron full node: tip height, finalized (solidity) height and how far solidity lags, peers, client version, transactions in the tip block. When to use: is the TRON node we operate synced and healthy, and how far behind is the finalized state |
tron_get_contract | TRON contract metadata: name, creator, whether its ABI is published on chain, the function list, code hash and whether it looks like a TRC-20. When to use: before calling a contract, or to tell an unverified contract from a published one |
tron_get_chain_economics | TRON chain economics straight off our node: energy price (sun per energy unit), transaction fee, account creation fee, witness pay per block, total energy and bandwidth limits, maintenance interval and the next maintenance time, unfreeze delay. When to use: working out what a transaction will actually cost in TRX, or how TRON's resource market is currently priced |
tron_list_witnesses | TRON super representatives and candidates: who is producing blocks, how many they produced, how many they missed, votes and websites - read from our own node. When to use: governance or staking questions about TRON, or checking the health of block production |
tron_list_proposals | Tron governance proposals: id, proposer, state, approvals, expiry and the parameters they would change. When to use: governance or staking questions, or checking whether a chain-parameter change is pending |
| ⑥ Monero (XMR) — node, fee, transaction and payment proof |
xmr_get_recent_blocks | The most recent Monero blocks with the observed block interval. When to use: checking that XMR is producing blocks normally and at roughly the 120s target |
xmr_get_block | One Monero block header, by height or by block hash. When to use: confirming which block a transaction landed in, or inspecting reward, difficulty and weight of a block |
xmr_get_node_status | Monero node state: height vs target, sync flag, difficulty, txpool size, database size, monerod version and peer counts. When to use: whether the XMR node is synced and healthy, or how big its chain and txpool are |
xmr_get_fee_rates | Monero fee estimate per kB, split into ascending priority tiers, read from our own monerod. When to use: pricing an XMR transaction, or deciding whether to pay the baseline fee to land in the next block |
xmr_get_mempool_state | Monero mempool: pending transaction count, total bytes and fees, age of the oldest pending tx, double-spend/failing counts. When to use: is the network quiet or piling up, and roughly how long a new transaction waits |
xmr_get_transaction | Look up one Monero transaction by txid: is it mined, in which block, how many confirmations, its size, output count and ring size. When to use: did this XMR transfer get into a block, and how deep is it now |
xmr_get_network_stats | Monero network-wide state: network hashrate, difficulty, emission and fees over the last 720 blocks, protocol version and the next hard fork. When to use: macro questions about the Monero network - how much hashrate secures it, what is being issued, and which protocol version is active |
xmr_verify_payment | Verify one Monero payment cryptographically, using proof material only the recipient can provide. Give it a txid plus either the transaction key (from your own wallet: get_tx_key ) or a transaction proof signature (get_tx_proof), and it returns whether that transaction really pays the given address, for how much, and how many confirmations. When to use: a merchant or agent needs to confirm an XMR payment arrived before releasing value, without trusting a block explorer - and for Monero there is no other way, because amounts and both counterparties are hidden by the protocol |
xmr_get_output_distribution | Monero output distribution: how many spendable outputs fall into each ring-size bucket, read from our own monerod. This is the anonymity-set side of Monero that free explorers rarely expose. When to use: reasoning about Monero privacy - how large the spendable-output set is at a given height |
xmr_merchant_report | Historical incoming-payment ledger for one Monero address, computed with a view key. Returns per-day counts and totals, the largest common amounts, confirmations, unlocked flags and a completion flag for a 1-30 day window. When to use: a merchant or treasury needs to reconcile what actually arrived over a period, not just one txid - the thing a block explorer cannot do for Monero because amounts are hidden |
xmr_wallet_balance | Balance for one Monero address using a view key: total, unlocked and pending XMR, with the scanned window and a completion flag. When to use: an agent or merchant wants to know how much an address holds right now, or whether incoming funds have unlocked, without running a wallet |
xmr_mining_profitability | Mining profitability calculator using live chain difficulty and the Monero tail-emission reward: gross XMR per day/month, power cost, net USD profit, break-even XMR price, break-even electricity price and hardware ROI days. When to use: decide whether a given hashrate is worth running at a power price, or to explain why XMR mining economics changed |
| ⑦ Zcash (ZEC) — shielded pools & settlement |
zec_get_recent_blocks | The most recent Zcash blocks. When to use: checking whether ZEC is producing blocks normally and at what interval |
zec_get_pool_status | Zcash chain state plus the distribution of all six value pools, in one call. When to use: how much ZEC sits in each shielded pool, the shielded share of supply, and whether the ZEC node is caught up |
zec_get_transaction | Zcash transaction check by txid from our own Zebra node: confirmations, block height and time, whether it is in the active chain, size, and how much of it is transparent versus shielded. When to use: did this ZEC payment land, how deep is it, and does it involve shielded inputs/outputs |
zec_get_treestate | Zcash shielded commitment-tree state: the Sapling, Orchard and Ironwood anchor roots at a given block. When to use: shielded-pool depth - how the shielded sets advance over time, or the anchor a wallet or prover needs to recognise |
zec_get_network_stats | Zcash network and node state: mempool size and bytes, node version, difficulty, network hashrate, chain progress and disk, block subsidy, and the funding streams (including Zcash Community Grants). When to use: macro questions about Zcash - how much hashrate secures it, whether our node is caught up, what the block subsidy and funding allocations currently are |
| ⑧ CyberLibrary — metered book corpus |