encodeTransaction turns an intent into bytes ready to sign and broadcastTransaction puts an already-signed one on the wire, with the gap between them explicitly handed to other tooling — which makes this safe to give an agent, and incomplete on its own for actually moving funds. Unit handling is what else deserves attention here, because it is where an agent otherwise goes wrong: getAccountState returns wei, satoshis and µATOM, and names listFeatures and getTokenDetails as the calls that turn those into a number a person can read.
A read-and-encode client for the Adamik API, with 12 tools covering chain discovery and per-chain feature flags, account state and history, token metadata, validator lists, transaction encoding for transfer, transferToken, stake, unstake, claimRewards, withdraw, registerStake, convertAsset and deployAccount intents, and broadcast of a transaction that has already been signed.
- Chain capability checked rather than assumed: getSupportedChains lists the chain IDs the API answers for, and listFeatures returns per chain which of read, write, token and validators it supports, along with the native currency's ticker, decimals and name.
- Balances that refuse to be shown raw: getAccountState returns amounts in smallest units — wei, satoshis, µATOM — and its own description makes listFeatures a prerequisite for native decimals and getTokenDetails the source of the decimals field for a non-native ERC-20, TRC-20 or SPL token, spelling out human_readable = raw_amount / 10^token_decimals.
- Staking as a first-class intent instead of a contract call you assemble: getChainValidators returns the validators worth delegating to, and encodeTransaction accepts stake, unstake, claimRewards, withdraw and registerStake alongside the plain transfer and transferToken.
- Cross-asset movement through the same encoder: encodeTransaction accepts convertAsset for swapping or bridging between assets, potentially across chains, and deployAccount for the chains that need an account created before it can be used.
- An address derived rather than guessed: deriveAddress takes a chainId and a pubkey and returns the address that chain would produce from it.
- History and receipts on the same footing as balances: getAccountHistory returns an account's transactions and getTransactionDetails resolves a single transactionId on a given chain.
- The API contract itself, on demand: getApiSpecification returns the OpenAPI specification covering 80+ networks, fetched by section with a refresh flag, including chain families such as EVM, Cosmos, Bitcoin, Solana and Starknet and the exact request and response schemas per transaction type.
An Adamik API key in ADAMIK_API_KEY. Signing is deliberately not part of this server: broadcastTransaction takes a transaction that has already been signed, and its own description points at separate key-management and signing tooling for the step in between. readMeFirst is written as the call to make before any other.
One command plus a key — npx @adamik/mcp-server, then supply credentials