Loading ToolBench
MCP server that allows any LLM to perform operations on over 60 blockchain networks. Provides read operations for account balances, transaction history, chain details, and write operations for transaction encoding and broadcasting.
The Adamik MCP server defines 12 tools with varying quality. Strengths: all tools have descriptions (some detailed), input schemas are present with type definitions, and the server addresses a specific domain (blockchain operations). Weaknesses: descriptions are inconsistent in quality and length; parameters lack consistent detail and format guidance; output schemas are not documented; error handling lacks recovery guidance; tool composition has overlaps (e.g., getAccountState + getAccountHistory, encodeTransaction + broadcastTransaction could benefit from clearer sequencing); security concerns around secrets in environment variables are mitigated by server-side injection but documentation is minimal. The 'readMeFirst' tool is a workaround for missing tool documentation rather than properly structured schemas. Average description length is ~150 chars, which is acceptable, but many parameters lack meaningful constraints or format guidance.
Broadcast a signed transaction to a blockchain network
Derive blockchain addresses from a public key for a specific chain
Encode a blockchain transaction into its serialized format before signing. This operation prepares a transaction for signing and broadcasting.
Get the transaction history for an account on a specific blockchain
Get the current state of an account on a specific blockchain, including balances (native currency, tokens) and staking information
Get the complete API specification including all request/response schemas, validation rules, and format requirements for all Adamik API endpoints
Output schemas not documented. The source code shows no return type documentation for any tool. Tools like getAccountState, getChainValidators, and getAccountHistory accept pagination parameters but lack documented return structures (is it {items: [], total: number} or {data: [], nextPage: string}?). This forces LLMs to infer output structure from API responses, increasing hallucination risk.
Parameter descriptions lack format guidance and constraints. Parameters like 'chainId' (used in 10 tools) have generic descriptions ('The blockchain chain identifier') but no enum of valid values, regex patterns, or reference to where valid chains are discovered. LLMs cannot validate inputs independently and will hallucinate chain IDs. The chains.ts file lists 18 chains but this is not exposed to the schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get a list of validators on a blockchain network that users can stake with
Get a list of all supported blockchain networks and their details including supported features for each chain
Get detailed information about a specific token on a blockchain, including its name, ticker, decimals, and contract address
Get details about a specific transaction on a blockchain
Get details about supported features for a specific blockchain chain. This includes information about what read and write operations are available.
Get information about how this tool is supposed to be used. Use this tool first before any other tool from this MCP server
Pagination parameters undocumented. getAccountHistory and getChainValidators accept a 'nextPage' parameter for pagination but the description does not explain: What value should be passed for the first page? Is nextPage opaque or can it be constructed? How many items per page? The tool does not return page_size or total_count, making iteration impossible without trial-and-error.
No error recovery guidance. The makeApiRequest() function handles a specific Premium feature error (501 with 'convertAsset') but the error message is verbose and does not guide the LLM toward recovery. Other API errors (4xx, 5xx) will return raw JSON or unstructured responses, leaving the agent with no context for retry logic or alternative actions.
No idempotency or confirmation for irreversible operations. broadcastTransaction will submit a signed transaction to a blockchain with no dry-run, confirmation, or idempotency markers. If an LLM retries due to a network blip, the transaction could be broadcast twice. encodeTransaction should support a dry_run flag to validate schemas before committing to signing.
Tool composition and dependency not explicit. The flow (deriveAddress → getAccountState → encodeTransaction → broadcastTransaction) is documented in readMeFirst but not in the tool schemas. An LLM has no way to know that encodeTransaction requires both chainId and accountId (derived earlier) without reading the readme. Tool descriptions should explicitly state dependencies and whether a tool is idempotent.
readMeFirst anti-pattern. Rather than embedding tool documentation in the schema, the server punts to a 'readMeFirst' tool. This violates the principle that each tool should be self-documenting and discoverable via schema alone. LLMs may not call readMeFirst before attempting operations, causing confusion.
Missing parameter type information in schema. The 'transactions' parameter in encodeTransaction is declared as type 'array' with no itemType, description of array structure, or nested schema. What fields does each transaction object require? What are valid field names and types? LLMs must guess or call getApiSpecification, adding round trips.
No permission/scope declaration. The server has no indication of what permissions encodeTransaction, broadcastTransaction, and deriveAddress require. Should an agent be able to broadcast transactions without explicit user consent? No scope or permission gate is visible, raising security concerns.