MCP server for Web3 wallet interactions on EVM-compatible chains using Wagmi
The server provides 30 tools with explicit schemas and descriptions for all tools. However, there are significant gaps in parameter documentation, inconsistent schema completeness, and missing output schema documentation. Many tools accept optional parameters without clear guidance on when to use them. The majority of tool descriptions are adequate (100-250 chars) but lack context about prerequisites, when to use vs. similar tools, or what the output structure looks like. Parameter descriptions exist but are often minimal (10-40 chars). No tool annotations (readOnlyHint/destructiveHint/idempotentHint) are present despite the risk taxonomy being explicitly defined. Tools like `sign_typed_data` have zero visible parameters in the schema, it should accept message/domain/types as inputs. Output schemas are completely undocumented across all tools, forcing LLMs to guess at response structure.
Add a custom EVM-compatible blockchain network
Create a new encrypted key store
Cancel an open order on Hyperliquid
Get Hyperliquid account information including balance and positions
Get mid prices for all trading pairs
Get all open orders
Get current positions
sign_typed_data has zero visible input parameters despite being a signing operation. Schema shows empty properties object. Tool is non-functional or schema is incomplete.
No tool annotations present (readOnlyHint, destructiveHint, idempotentHint) despite the server explicitly tracking risk levels (READ_ONLY, WRITE, DESTRUCTIVE). This metadata should be in the tool schema to guide LLM behavior.
Output schemas completely absent. No tool documents what it returns (fields, types, structure). LLMs cannot plan downstream calls or extract result data without seeing the response structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Get trade fill history for a user
Import a Hyperliquid wallet using private key
Place a basic limit or market order on Hyperliquid
Transfer USDC on Hyperliquid
Import private key into encrypted store
List all available contracts from Wagmi config
List encrypted keys
Load contract ABIs from a Wagmi-generated file
Lock encrypted key store
Read from a smart contract using Wagmi-generated ABIs
Remove a previously added custom chain
Remove encrypted key
Resolve an ENS name to an Ethereum address (mainnet only)
Sign a message with the connected wallet
Sign EIP-712 typed data
Simulate a contract function call without gas costs or state changes
Simulate a contract transaction before executing to check if it will succeed
Run comprehensive tests on all functions in a contract
Generate and run multiple test scenarios for a contract function
Unlock encrypted key store
Update an existing custom chain's configuration
Update key label
Write to a smart contract using Wagmi-generated ABIs
Many optional parameters lack clear guidance on when to use them or what happens if omitted. Examples: `hl_get_account_info.address` (uses imported wallet if not provided), `hl_place_order.limitPx` (creates market order if omitted), but this behavior is only hinted in descriptions, not explicitly documented.
No documented error handling or recovery guidance. Tools like remove_encrypted_key and remove_custom_chain are destructive but provide no guidance on what happens on failure, what errors to expect, or how to recover.
Parameter descriptions are inconsistently detailed. Some tools have rich descriptions (hl_place_order), others are minimal (hl_get_account_info.address = '1 line'). Inconsistency across 30 tools means LLMs get varying quality guidance.
No pagination guidance documented for list tools (list_contracts, list_encrypted_keys, hl_get_open_orders, hl_get_positions). No limit, offset, or cursor parameters visible. Large result sets will blow context window.
nativeCurrency parameter in add_custom_chain and update_custom_chain is described as 'Native currency configuration' (object type) but no sub-properties or examples given. LLM cannot determine what fields this object should contain.
Function arguments parameter in write_contract, read_contract, and simulate_contract_call accept 'array' type with no schema for array element types. LLM cannot know what types of values to pass.