Adamik MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| readMeFirstA | Get information about how this tool is supposed to be used. Use this tool first before any other tool from this MCP server |
| getSupportedChainsB | Get a list of supported chain IDs |
| listFeaturesB | Get chain details including supported features (read, write, token, validators) and native currency information (ticker, decimals, chain name) |
| getTokenDetailsA | Fetches information about a non-native token (ERC-20, TRC-20, SPL, etc.) - not the chain's native currency. CRITICAL: This provides the 'decimals' field needed to convert raw token amounts from getAccountState() to human-readable values. Always call this for each token when displaying balances: human_readable = raw_amount ÷ 10^token_decimals |
| deriveAddressC | Derive a blockchain address for a given chain from a public key |
| getAccountStateA | Get the state of an account (balances and staking positions). CRITICAL: Balance amounts are returned in SMALLEST UNITS (wei for ETH, satoshis for BTC, µATOM for ATOM, etc.). NEVER show raw amounts to users! Always convert first! MANDATORY CONVERSION STEPS - ALWAYS CALL THESE ENDPOINTS: 1. For NATIVE currency: MUST call listFeatures(chainId) first to get the exact decimal places - NEVER assume! 2. For TOKENS: MUST call getTokenDetails(chainId, tokenId) for each token to get its exact decimals - NEVER assume! 3. Convert ALL amounts: human_readable = raw_amount ÷ 10^decimals (using the decimals from the API calls above) 4. Present in human-readable format to users COMMON ERRORS TO AVOID: • ATOM: Raw '4191769000' with 6 decimals = 4.191769 ATOM (NOT 4,191.769 ATOM!) • ETH: Raw '5354656887913579' with 18 decimals = 0.005354656887913579 ETH (NOT 5.35 ETH!) • Always divide by 10^decimals, check your decimal point placement! |
| getAccountHistoryC | Get the transaction history for an account |
| getChainValidatorsA | Gets the list of known validators for a given chain. This is only useful when asking the user to select a validator to delegate to |
| getTransactionDetailsC | Gets info about a transaction |
| encodeTransactionA | Turns a transaction intent in Adamik JSON format into an encoded transaction for the given chain (ready to sign). Supports all transaction types: transfer, transferToken, stake, unstake, claimRewards, withdraw, registerStake, convertAsset, and deployAccount. For convertAsset transactions: allows swapping/bridging between different assets, potentially across chains. IMPORTANT: If you receive an error with contact information (like https://adamik.io/contact), you MUST include that exact contact link in your response to the user and do NOT suggest alternative solutions. For staking transaction on babylon chain, stakeId is mandatory and amount is optional. Otherwise, amount is mandatory and stakeId is to be omitted. |
| broadcastTransactionC | Broadcast a signed transaction. You will probably need another MCP server dedicated in key management and signing before using this. |
| getApiSpecificationA | Get the comprehensive OpenAPI specification for the Adamik API covering 80+ blockchain networks. This provides authoritative reference for: • Exact request/response schemas for all transaction types (transfer, stake, unstake, claimRewards, convertAsset, etc.) • Complete chain family details (EVM, Cosmos, Bitcoin, Solana, Starknet, etc.) with supported features • Precise parameter formats (amounts in smallest units, address formats, token IDs, validator addresses) • Transaction encoding formats (RLP, PSBT, BOC, BCS, etc.) and signature requirements • Account state schemas (native/token balances, staking positions, rewards) • Error handling patterns and validation rules • Pagination support for large datasets Use this when you need exact API contract details for blockchain operations. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have distinct purposes, but there is some overlap between getAccountHistory and getTransactionDetails, which could cause confusion about which to use for transaction-related queries. Additionally, getApiSpecification is a broad reference tool that might overlap in utility with other tools like listFeatures or encodeTransaction for schema details, though its comprehensive nature helps differentiate it.
All tool names follow a consistent verb_noun pattern (e.g., broadcastTransaction, deriveAddress, encodeTransaction), using camelCase uniformly throughout. This predictability makes it easy for agents to understand and navigate the tool set without confusion from mixed naming conventions.
With 12 tools, the count is well-suited for the server's purpose of blockchain operations, covering key actions like transaction handling, account management, and chain information. Each tool serves a specific function, and there is no bloat or missing critical tools, making the scope appropriate and manageable.
The tool set provides comprehensive coverage for blockchain interactions, including transaction encoding/broadcasting, account state/history retrieval, chain and token details, and API specifications. It supports all major transaction types and includes critical utilities like readMeFirst for guidance, leaving no obvious gaps for agents to perform typical blockchain operations.